| 00:59 | <Aki> | is 8x8 down? |
| 01:00 | <Bradford Smith> | it's working for about 16 of us :) |
| 01:02 | <ryzokuken> | (I did it yesterday) |
| 01:02 | <ryzokuken> | had initially done just two days since we'd expected this one to run for just two days |
| 01:02 | <devsnek> | its working for me |
| 01:13 | <ljharb> | sffc: fwiw 262 has "extended mathematical values", in case you want to define "intl math values" as "extended with NaN and -0" https://tc39.es/ecma262/#sec-mathematical-operations |
| 01:17 | <littledan> | +1 for Stage 3 |
| 01:17 | <ryzokuken> | I cannot unmute, sorry 😅 |
| 01:24 | <Aki> | can i take a quick moment to appreciate sffc 's boundless positivity when presenting to the committee |
| 01:52 | <leobalter> | Aki bterlson I'll let you know asap when Caridy is back. |
| 01:53 | <Bradford Smith> | +1 for pattern matching from me - I would have come this last time, but was on vacation |
| 01:54 | <ljharb> | Michael Ficarra bakkot : 2360 or 1554 or 545 first? (since 545 is big and there may be conflicts) |
| 01:54 | <Michael Ficarra> | ljharb: they should be able to go in in any order |
| 01:55 | <ljharb> | ok cool, i'll do it oldest to newest then |
| 01:55 | <Michael Ficarra> | to be safe, land 545 I guess |
| 01:56 | <Michael Ficarra> | ah, 1554 adds a new AO though ljharb |
| 01:56 | <Michael Ficarra> | we may want to wait for bakkot to rebase that one on 545 first |
| 01:56 | <Michael Ficarra> | I'll remove the label |
| 01:56 | <ljharb> | alternatively, i could land 545 last |
| 01:57 | <Michael Ficarra> | ljharb: we should probably take this to #tc39-editors:matrix.org |
| 01:57 | <ljharb> | sure, i can't speak in there tho |
| 01:57 | <Michael Ficarra> | oh, that's not good |
| 01:58 | <Michael Ficarra> | is there an easy way to permit every delegate? |
| 01:58 | <ljharb> | ^ Aki or bterlson? |
| 01:58 | <bterlson> | I don't think so, without a bot of some kind :/ |
| 01:58 | <ryzokuken> | I think it's time we built a bot |
| 01:59 | <Aki> | i've been elbow deep in the API docs for the past few days |
| 01:59 | <Aki> | so |
| 01:59 | <Aki> | uhh |
| 01:59 | <Aki> | on it |
| 01:59 | <ryzokuken> | 😲 awesome! |
| 02:00 | <waldemar> | I'm interested in the pattern matching incubator |
| 02:01 | <Aki> | i'm not actually building a bot, for the record. i'm writing a tiny CLI for the chairs to handle admin tasks, including matrix permissions |
| 02:02 | <Aki> | @mich |
| 02:02 | <Aki> | ugh |
| 02:02 | <Aki> | Michael Ficarra, bakkot i think you two are admins on the editors channel |
| 02:02 | <devsnek> | you should make it a discord bot |
| 02:02 | <ryzokuken> | what is a bot, maybe we're the bots... |
| 02:03 | <HE Shi-Jun> | Could we have matrix rooms for the proposals which many may be interest in? I just found pattern match proposal have a room :) |
| 02:04 | <devsnek> | as long as your homeserver can handle it, you can make as many channels as you want |
| 02:04 | <ryzokuken> | Could we have matrix rooms for the proposals which many may be interest in? I just found pattern match proposal have a room :) |
| 02:04 | <devsnek> | can someone post here when we resume |
| 02:04 | <Michael Ficarra> | Aki: I think so too, but I can't figure out how to add someone or change their permissions |
| 02:04 | <ryzokuken> | question is, are those official TC39 rooms to be added in this space? |
| 02:04 | <ryzokuken> | devsnek: we are almost here |
| 02:05 | <ryzokuken> | we're resuming |
| 02:05 | <devsnek> | we are? |
| 02:05 | <ryzokuken> | yeah |
| 02:05 | <ryzokuken> | with the temporal discussion |
| 02:05 | <devsnek> | oh |
| 02:06 | <HE Shi-Jun> | temporal has one too |
| 02:11 | <ljharb> | Michael Ficarra: ftr no, it still says i can't post |
| 02:14 | <HE Shi-Jun> | I think in the developer perspective, "namespace" means if you destructure the property/functions from the namespace, they still keep the same functionality |
| 02:16 | <ljharb> | probably also, that you could copy all the things from the original namespace to a new object, and it'd be indistinguishable except by identity? |
| 02:17 | <HE Shi-Jun> | ryzokuken: Can I ask what's the room name for Temporal proposal? I can't find it by public room search. |
| 02:17 | <ljharb> | i can't find it either |
| 02:20 | <HE Shi-Jun> | probably also, that you could copy all the things from the original namespace to a new object, and it'd be indistinguishable except by identity? this argument) in their functions. |
| 02:29 | <littledan> | Fwiw WebIDL namespaces can have pure accessors |
| 02:31 | <HE Shi-Jun> | what is "pure accessors" ? |
| 02:40 | <littledan> | In the sense of, they act like data properties basically |
| 02:43 | <HE Shi-Jun> | In the sense of, they act like data properties basically |
| 02:43 | <bakkot> | we are now discussing strictly internal words? |
| 02:43 | <HE Shi-Jun> | Note, old libraries like YUI2 use namespaces like "YAHOO.util.*" which do not capitalized... I think they are affected by java language convention. |
| 02:43 | <bakkot> | I would like to stop discussing that |
| 02:44 | <littledan> | These are both established terms. I don't think we have standing to rename them |
| 02:49 | <ljharb> | bterlson: advance queue? |
| 02:50 | <bterlson> | done |
| 02:50 | <bakkot> | so on the previous topic, we kind of went from discussing capitalization to discussing whether we should call "module namespace" something else, without getting formal consensus on the previous topic |
| 02:50 | <bakkot> | unless that happened and I missed it |
| 02:51 | <ljharb> | iirc consensus was presumed but never officially asked for |
| 02:52 | <shu> | i did ask for consensus for capitalization |
| 02:52 | <shu> | didn't i? |
| 02:52 | <bterlson> | my understanding was the main point was the narrow issue of .Now? |
| 02:52 | <bakkot> | point of order: more note takers |
| 02:52 | <shu> | yes, sorry, i asked for consensus for capitalization of .Now |
| 02:52 | <shu> | and that we will write down what a namespace object is in how-we-work, but i did not ask for consensus that we capitalize all future namespace objects |
| 02:53 | <bakkot> | the thing I wrote in the notes is Namespace objects will be capitalized, including when nested. This means |
| 02:53 | <bakkot> | is that not accurate? |
| 02:53 | <bakkot> | because I would really like it to be accurate |
| 02:53 | <bakkot> | so we can be done |
| 02:53 | <shu> | i'd like that to be true; if ljharb confirms he doesn't object to it let's go with that |
| 02:53 | <shu> | because i asked for a narrower thing, pedantically speaking? |
| 02:53 | <devsnek> | if membranes are equiv to direct access, why does chrome not block them as the same security issue |
| 02:54 | <littledan> | Once you have leaked the wrong-realm array constructor, it's game over for preventing the library user from monkey patching things |
| 02:54 | <ljharb> | that is true, that's a problem with the slide example |
| 02:55 | <shu> | but that's the point, the argument is a footgun argument |
| 02:55 | <ljharb> | altho delete otherRealmGlobalThis.Array.prototype.constructor would fix that |
| 02:55 | <shu> | it's easy to write code that is wrong in the way the slide example is wrong |
| 02:55 | <ljharb> | it's easy to write loops as infinite ones. that doesn't mean we ban loops. |
| 02:56 | <HE Shi-Jun> | The example may be not the best, but I think I understand the point :) |
| 02:56 | <devsnek> | does anyone know? should i ask mark? |
| 02:56 | <shu> | ljharb: it's a question of line-drawing |
| 02:56 | <HE Shi-Jun> | No membrane is not equiv to direct access... |
| 02:56 | <ljharb> | sure. which is arbitrary, and decides whose use cases get to happen and whose don't |
| 02:56 | <iain> | The average success rate at writing a terminating loop seems to be a lot higher than the average success rate at not leaking given direct object access |
| 02:56 | <HE Shi-Jun> | membrane should not leak another realm |
| 02:56 | <shu> | i don't think it's a strong argument to say "another bad thing Y is possible, and we don't ban Y, therefore we shouldn't ban any bad thing" |
| 02:58 | <ljharb> | sure. but i don't think it's super strong either to say "X can be messed up, so rather than make X harder to mess up, let's make it impossible to do at all" |
| 02:58 | <HE Shi-Jun> | Personally I don't think leaking another realm is the end of the world, but if we can avoid it in most cases I would be happy :) |
| 02:59 | <shu> | i agree, in the abstract. in this case this was informed by actual enthusiasm to use Realms as sandboxes that would've resulted in security issues, which pushed this over the line to "let's make it impossible instead" |
| 02:59 | <shu> | please note i use "security" there in a way i don't personally endorse as a browser vendor :) |
| 02:59 | <littledan> | There's a lot more to defend against than just deleting the constructor property. You can find the Array constructor again through eval. Less obscurely, you could easily patch methods on the prototype, and it's easy to accidentally use them. It becomes a big problem to block everything |
| 02:59 | <shu> | +1 |
| 03:01 | <ljharb> | littledan if you're handed an other-realm array that has no constructor, and you don't have access to the other realm, how could you find it through eval? |
| 03:01 | <ljharb> | the prototype tho is fair, that'd defeat the purpose |
| 03:01 | <ljharb> | to fix caridy's example, i'd do return [...slice.call(sequence, index)]; or similar |
| 03:01 | <HE Shi-Jun> | Agree with shu , it seems very easy to write wrong code which will leak the sandbox. So if consider secure sandbox is the important use case, I have to support ban the direct object access. |
| 03:01 | <littledan> | +1 to Caridy's point |
| 03:02 | <littledan> | I think it is important that we make better mechanisms for resilient code. Shared-object Realms just don't seem like that solution. |
| 03:03 | <littledan> | (maybe there are other important use cases of them though) |
| 03:03 | <Josh Blaney> | wow, was not expected to get rick rolled |
| 03:03 | <HE Shi-Jun> | Oh, good music ... |
| 03:03 | <Josh Blaney> | but I approve |
| 03:08 | <devsnek> | can we have an api to zero-copy refer to arraybuffer data over the callable boundary |
| 03:08 | <devsnek> | does that already exist |
| 03:09 | <ptomato> | I'm reading the scrollback and now am not sure if there is any residual doubt about whether we got consensus on the capitalization of namespace objects. can anyone confirm? |
| 03:10 | <devsnek> | if there was it should be in the notes |
| 03:11 | <ptomato> | I believe there was some discussion above about whether the notes correctly reflected what shu asked for? I'd like to sleep well tonight knowing the matter is put to rest |
| 03:12 | <shu> | ljharb: are you okay recording the namespace discussion conclusion as what bakkot has written, which is Namespace objects will be capitalized, including when nested. This means Temporal.now is renamed to Temporal.Now |
| 03:14 | <ljharb> | sorry for the delay; i've had kids out of bed in and out of my office for the last half hour |
| 03:14 | <ljharb> | i'm very unhappy with the renaming and think it's a bad decision, but i had my chance to object and didn't, so i guess go for it |
| 03:15 | <shu> | thanks, unhappiness noted |
| 04:07 | <bakkot> | oh man are hosts going to add postmessage |
| 04:07 | <bakkot> | probably, right? |
| 04:07 | <bakkot> | so you can structured clone your objects across the boundary |
| 04:07 | <shu> | indeed, that was the original suggestion, a structured-clone boundary |
| 04:07 | <bakkot> | but here you could just do it manually |
| 04:07 | <shu> | a callable boundary is not mutually exclusive with a structured clone boundary afaict |
| 04:07 | <bakkot> | by messaging yourself |
| 04:08 | <leobalter> | bakkot: most of a structured close boundary represents a membrane |
| 04:08 | <shu> | really? |
| 04:08 | <shu> | a structured clone boundary explicitly doesn't preserve identity |
| 04:08 | <shu> | you get new clones |
| 04:09 | <leobalter> | I don't have bandwidth to discuss here and listen to the meeting |
| 04:10 | <leobalter> | I'm afraid my answers here will be short, but I'd love to talk more with time allowing |
| 04:11 | <devsnek> | would anyone block a "transfer arraybuffer across realm boundary" proposal |
| 04:12 | <shu> | transfer meaning detach on one side? |
| 04:12 | <ryzokuken> | devsnek: can you explain transfer better? |
| 04:12 | <devsnek> | detach would be fine for my use case |
| 04:12 | <shu> | seems like it'd be subsumed by structured clone, which i'd like to think more about |
| 04:12 | <devsnek> | i'd be cool with a full structured clone |
| 04:12 | <shu> | no principled concerns from my POV for that |
| 04:13 | <devsnek> | what kind of timeline are you thinking about structured clone in |
| 04:13 | <shu> | no idea |
| 04:13 | <devsnek> | 😔 |
| 04:15 | <devsnek> | in a js environment with MessageChannel is there a way to get a port across the boundary |
| 04:15 | <HE Shi-Jun> | transfering arraybuffer across realms! I really want it! |
| 04:16 | <bakkot> | ljharb: I would like to talk to you about your caching use case more, maybe. I thought I wanted realms to solve that but it turns out I didn't and I suspect you also might not. |
| 04:16 | <ljharb> | bakkot: i have to listen, so if you can type it one-sidedly i'll read as i have time |
| 04:16 | <bakkot> | yup |
| 04:17 | <leobalter> | HE Shi-Jun: I hear you! There are people in the SES group who wants it too. |
| 04:19 | <ryzokuken> | do we want to go back to the queue for discussing this? |
| 04:19 | <bakkot> | basically: in terms of how many objects you create, a new realm is significantly more heavy than just capturing every reachable thing. and you can just capture every reachable thing instead: basically just take a snapshot of the current realm, with a fairly small loop. and that's much lighter weight, and not even very much more code. |
| 04:19 | <HE Shi-Jun> | Transferable seems web api, not in ES spec. Hope we could include it in JS directly. |
| 04:19 | <devsnek> | i can confirm that greedily taking all the primordials is expensive, it is one of the reasons nodejs moved to using v8 snapshots |
| 04:20 | <bakkot> | so optimizing for specifically that use case does not seem like something which needs language-level support |
| 04:20 | <leobalter> | ryzokuken: please check the queue because Greg is not used to the TC39 meetings yet |
| 04:21 | <shu> | i don't have this cache-originals problem space paged in very well, how does Realms solve this again? |
| 04:21 | <shu> | like even if you cache the Realm don't you still need to run before anything can run in the user Realm? |
| 04:21 | <bakkot> | yes, the assumption is that you are running first |
| 04:22 | <ryzokuken> | leobalter: sure. Did Greg remove his question? If not, could you please ask them to add it again? I saw their clarifying question for a second |
| 04:22 | <ljharb> | like even if you cache the Realm don't you still need to run before anything can run in the user Realm? |
| 04:22 | <shu> | okay, and don't you still have to enumerate all reachable things from the Realm? |
| 04:22 | <devsnek> | ljharb wants to cache originals lazily |
| 04:22 | <bakkot> | the question is, do you take a snapshot by making a new realm, or by walking the current one and saving stuff off of it |
| 04:22 | <shu> | you can't just cache the Realm |
| 04:22 | <bakkot> | assuming you are run-first |
| 04:22 | <bakkot> | uhhhh why not? |
| 04:22 | <bakkot> | no one else should be able to reach it |
| 04:22 | <ljharb> | why can't i just cache the realm, if nobody else can get to my realm, and i avoid leaking access to its primordials? |
| 04:22 | <shu> | oh, you make an entirely new realm for the sole purpose of getting primordials off it |
| 04:22 | <bakkot> | yup |
| 04:22 | <shu> | not that you try to reuse a user realm that's already used for something else |
| 04:22 | <shu> | got it, thanks |
| 04:23 | <bakkot> | yup |
| 04:23 | <shu> | my response to that is that that is a Bad Idea for performance |
| 04:23 | <shu> | which people have said |
| 04:24 | <bakkot> | yeah, and it seems like the thing ljharb doesn't like about the current approach is also performance, so this would not solve this, though maybe I am not understanding |
| 04:24 | <ljharb> | it's not really perf, it's that it's actually hard to grab everything dynamically |
| 04:24 | <ryzokuken> | Realm.prototype? |
| 04:24 | <ljharb> | especially since not all the instrinsics are globals |
| 04:25 | <bakkot> | eh, there's only a small number of things which aren't reachable as paths off the global, so you just write those down and capture everything else with a loop |
| 04:25 | <devsnek> | getoriginals proposal lives again |
| 04:26 | <ljharb> | that specific proposal had the "get originals" function as nonconfigurable tho, which is a nonstarter. |
| 04:26 | <HE Shi-Jun> | I am not sure I understand what ljharb want... but I guess it's a usecase of making polyfill? |
| 04:26 | <ljharb> | not just polyfills. all my npm modules are written robustly, so that later builtin modification doesn't break them. |
| 04:27 | <littledan> | I don't see why this would be part of the Realm constructor. Presumably you would want to be able to access this from the main global object |
| 04:27 | <ljharb> | ^ agreed |
| 04:27 | <bakkot> | I feel like jordan + SES + me + salesforce + one or two other polyfill libs are the only people who would use this, though |
| 04:27 | <bakkot> | so I am not convinced it makes sense for the language to help us out |
| 04:27 | <bakkot> | we can just do it ourselves |
| 04:27 | <ljharb> | that's 10-20% of npm traffic right there tho |
| 04:28 | <HE Shi-Jun> | Ok, it's like to reuse spec behavior (abstract operation or something like that) |
| 04:29 | <bakkot> | there is a sharp upper bound on how many people can do this, because each person doing it assumes they are first-run |
| 04:29 | <bakkot> | and we can't all be correct |
| 04:29 | <HE Shi-Jun> | I believe it's a valid use case, which is very important for polyfills or other cases which u want to keep align as close as spec. |
| 04:29 | <shu> | the implementation complexity for getoriginals seems high |
| 04:30 | <shu> | though i don't know the exact semantics proposed |
| 04:30 | <shu> | so, agree with bakkot's point on nicheness |
| 04:30 | <devsnek> | v8 already like half implements it |
| 04:30 | <devsnek> | for its own internal usage of primoridals |
| 04:30 | <littledan> | I guess the semantics proposed are a bunch of Gets? |
| 04:30 | <littledan> | It seems OK? |
| 04:30 | <bakkot> | pretty much, yup |
| 04:31 | <bakkot> | well, getOwnPropertyDescriptor, really |
| 04:31 | <shu> | if i modify Object.prototype |
| 04:31 | <shu> | and i getOriginal('%Object.prototype%'), what do i get? |
| 04:31 | <HE Shi-Jun> | But I still not get how current realm proposal not satisfy this use case ... |
| 04:31 | <devsnek> | the original |
| 04:31 | <shu> | like i added a property to Object.prototype |
| 04:31 | <littledan> | The post-modification value |
| 04:31 | <shu> | but the object is still the original object |
| 04:31 | <shu> | oh ok |
| 04:31 | <shu> | then i have no concerns |
| 04:31 | <littledan> | The post-modification property of the original intrinsic |
| 04:32 | <ljharb> | no |
| 04:33 | <ljharb> | or wait |
| 04:33 | <devsnek> | ljharb does your use case match nodejs's primoridal api |
| 04:33 | <ljharb> | yes |
| 04:33 | <devsnek> | then it matches what littledan said |
| 04:33 | <ryzokuken> | yeah exactly |
| 04:33 | <ljharb> | if you replace, say, Array.prototype.slice A with Array.prototype.slice B, without replacing GetIntrinsic, and you try to get that intrinsic, you'd get A |
| 04:33 | <shu> | i don't understand that sentence |
| 04:34 | <ljharb> | iow if you want to deny access to A, you'd have to wrap/replace GetIntrinsic to do so |
| 04:34 | <shu> | "that intrinsic" is which intrinsic? |
| 04:34 | <bakkot> | I don't think I really care what it gives you for X after someone has patched X, as long as it's a coherent, because if I'm first-run I can patch getOriginals myself to pretend that I hadn't patched X |
| 04:34 | <devsnek> | shu ljharb is saying like, getIntrinsic('%Array.prototype.slice%') |
| 04:34 | <devsnek> | that sort of api |
| 04:34 | <shu> | thanks, that unconfuses me |
| 04:34 | <bakkot> | but the most convenient thing is if it just looks it up on the current objects |
| 04:34 | <littledan> | OK, so it would be like a separate point that you would have to monkeypatch? |
| 04:34 | <ljharb> | yes |
| 04:34 | <littledan> | So a little more "secure" than the current approach? |
| 04:35 | <littledan> | Could you explain the rationale? |
| 04:35 | <bakkot> | it's not more secure, it's just more convenient |
| 04:35 | <littledan> | This actually was an issue with getOriginals, that such an API might have real memory cost. |
| 04:36 | <shu> | if it's just gets on the original objects, then that's fine |
| 04:36 | <shu> | if it's like "get me the original objects with its original shape at the start of Realm genesis", that is not fine |
| 04:36 | <ljharb> | it can't be just that, or it doesn't meet the goal |
| 04:36 | <devsnek> | i don't think it would have the memory cost until you actually try to use a specific intrinsic |
| 04:36 | <ljharb> | if nobody's touched the GetIntrinsic function, then that is what it would have to be, or it wouldn't be solving the problem |
| 04:36 | <shu> | let me just put it on the queue because i don't understand what you're proposing anymore |
| 04:37 | <devsnek> | i think most of the major engines have a concept of rehydrating these apis from RO space as needed? |
| 04:37 | <shu> | not sure |
| 04:38 | <shu> | i don't think so actually, RO space things are RO |
| 04:38 | <devsnek> | v8 definitely does this, at least for intrinsic functions |
| 04:38 | <littledan> | Yeah the thing is that not all built-in methods are in that table |
| 04:39 | <devsnek> | would probably need more investigation but i don't think memory is a blocker off the bat |
| 04:40 | <iain> | I will also have to double-check in SM |
| 04:40 | <ljharb> | Yeah the thing is that not all built-in methods are in that table %a.b.c% syntax. |
| 04:40 | <devsnek> | i don't know about sm, but iirc jsc does this too |
| 04:40 | <ljharb> | every single original thing, with no exceptions, is accessible in the spec via intrinsics % % syntax. |
| 04:41 | <devsnek> | i think shu's concern is that they are not all accessed that way currently, and he's unsure of the implications of allowing that |
| 04:42 | <devsnek> | like in v8 there is a table on contexts with some of these, for example promise.prototype.then, but it's ad hoc for what actually gets used |
| 04:42 | <littledan> | I think we will have to check with implementers out of band before we can guarantee that there won't be implementation issues. |
| 04:42 | <shu> | yes |
| 04:43 | <shu> | i think in the abstract it seems doable |
| 04:43 | <shu> | specific hurdles may arise and i can't promise anything |
| 04:43 | <devsnek> | firing from the hip is a key part of constructive language design |
| 04:43 | <ljharb> | i'm obviously not asking for nor could i possibly expect guarantees. |
| 04:44 | <ljharb> | i just want to minimize the chances that i invest lots of effort and get stonewall-blocked later |
| 04:46 | <bakkot> | fwiw I don't hate it |
| 04:46 | <bakkot> | not super useful to me, because I also need to modify things |
| 04:46 | <bakkot> | and I'll need to patch it |
| 04:46 | <bakkot> | but it's not that hard to do |
| 04:48 | <ryzokuken> | "Adventures in monkey-patching the anti-monkey-patching API" 😛 |
| 04:49 | <devsnek> | what happens if you do |
| 04:49 | <devsnek> | getOriginals('%getOriginals%') |
| 04:49 | <ryzokuken> | I was just about to say that |
| 04:49 | <ryzokuken> | if you monkey-patch getOriginals, would getOriginals return the original getOriginals? |
| 04:50 | <devsnek> | technically it would return whatever you patched it to return |
| 04:50 | <ljharb> | your monkey-patched one would decide that :-p |
| 04:50 | <devsnek> | but in twitter speak |
| 04:50 | <devsnek> | this is a good meme |
| 04:51 | <bakkot> | being able to not use eval is good |
| 04:51 | <leobalter> | shu: I really don't have a better name that would not cause conflict, but my last alternative to rename Realm (if really necessary) would be CallableBoundary |
| 04:51 | <bakkot> | ryzokuken: this is surprisingly well-trod ground, it turns out |
| 04:51 | <bakkot> | at least in my little niche |
| 04:52 | <bakkot> | lot of people patching Function.prototype.toString to mask their functions and also making it mask their new Function.prototype.toString while they're at it, e.g. |
| 04:52 | <devsnek> | bakkot i'm honestly not sure what you do but everything i hear about the things you build sounds very cool |
| 04:52 | <ryzokuken> | and scary |
| 04:52 | <bakkot> | it's very... adversarial |
| 04:53 | <bakkot> | the actual thing I do is anti-automation |
| 04:53 | <ryzokuken> | every developer for themselves |
| 04:53 | <bakkot> | so like shoebots, I am the other side of that game |
| 04:53 | <bakkot> | if you are familiar with that niche |
| 04:53 | <devsnek> | you fight the gpu scalpers? |
| 04:53 | <bakkot> | can't speak to any particular retailer, but that is in the category of thing we do, yes |
| 04:53 | <shu> | leobalter: i'm fine with that, sure, i don't want to spend committee time bikeshedding now. i'd like for the vendors to agree to hold off shipping until we've actually bikeshed the name, which i want us to do async |
| 04:53 | <devsnek> | godspeed sir |
| 04:53 | <bakkot> | the way I usually put it is, we solve the same problem as captchas without needing a captcha |
| 04:54 | <bakkot> | I don't think marketing likes me to describe it that way though |
| 04:54 | <littledan> | shu: I really don't have a better name that would not cause conflict, but my last alternative to rename Realm (if really necessary) would be CallableBoundary |
| 04:54 | <devsnek> | that just makes me think about google's creepy user behavior tracking non-captcha |
| 04:54 | <ryzokuken> | bakkot: let's move this to TDZ? 😀 |
| 04:54 | <shu> | i know, but we never did actually debate the name, did we? |
| 04:54 | <bakkot> | bakkot: let's move this to TDZ? 😀 |
| 04:54 | <ryzokuken> | no worries, I'm equally interested hehe |
| 04:54 | <littledan> | i know, but we never did actually debate the name, did we? |
| 04:55 | <leobalter> | the fact we are adding anything to hold on implementation gives me a very high amount of anxiety. My strong preference is to keep it as is, but I can't say no otherwise. |
| 04:55 | <littledan> | I don't really like the name "CallableBoundary" but I don't have a better idea |
| 04:55 | <shu> | well, we don't really like this |
| 04:55 | <shu> | this == "Realm" as the user-exposed thing |
| 04:55 | <shu> | it's not a blocking concern, but i don't think we've actually bikeshed this |
| 04:55 | <littledan> | Oh, I see. I thought you had made peace with ut |
| 04:56 | <shu> | leobalter: i'm not putting a hold on implementations |
| 04:56 | <littledan> | Can we timebox the renaming debate to one more meeting? |
| 04:56 | <shu> | of course |
| 04:56 | <shu> | i'm only asking that other vendors don't ship until we've bikeshed the name, and if for whatever reason that never happens, we'll roll with Realm |
| 04:56 | <devsnek> | we could just spend all of tomorrow discussing it |
| 04:57 | <shu> | no, i'd rather we do this async as i originally said |
| 04:59 | <devsnek> | i feel like we've gone through like 15 different topics without noting consensus at the end of them |
| 04:59 | <bakkot> | we did get consensus for realms, explicitly |
| 04:59 | <bakkot> | it's in the notes even |
| 04:59 | <ryzokuken> | we did get consensus for realms, explicitly |
| 05:00 | <devsnek> | cool |
| 05:00 | <ryzokuken> | oh oops |
| 05:00 | <ryzokuken> | I misunderstood |
| 05:00 | <devsnek> | no tests though :( |
| 05:00 | <bakkot> | that's next stage |
| 05:01 | <devsnek> | yeah i know, but i still get my hopes up |
| 05:01 | <ljharb> | i like a rename; it's really not "realms" anymore |
| 05:04 | <iain> | I commit SM to not shipping (before we've had a chance to bikeshed the name) |
| 05:07 | <HE Shi-Jun> | About name, what about "Isolate" ? :) |
| 05:08 | <ryzokuken> | HE Shi-Jun: that's deceptive because this is different than a V8 Isolate |
| 05:09 | <ryzokuken> | my understanding is that this lies somewhere between a Context and Isolate in terms of V8... |
| 05:10 | <ljharb> | also i read "isolate" like a verb but a v8 isolate is a noun |
| 05:11 | <legendecas> | my understanding is that this lies somewhere between a |
| 05:11 | <devsnek> | this is a context in v8 |
| 05:11 | <devsnek> | an isolate is an agent |
| 05:11 | <devsnek> | context in the public api sense at least |
| 05:12 | <shu> | is "this looks interesting" a reason...? |
| 05:12 | <ryzokuken> | I like Compartments |
| 05:12 | <ryzokuken> | I like Zones too tbf |
| 05:13 | <leobalter> | I've been informed of objections for both Compartments and Zones already |
| 05:13 | <leobalter> | same for Context |
| 05:13 | <leobalter> | there is a much stronger objection for Context |
| 05:14 | <iain> | SM already has Realms, Zones, Compartments, and Contexts internally (this is not a blocker for any of those) |
| 05:14 | <legendecas> | what's wrong with "realm" exactly? I didn't find an issue about it, did I miss anything |
| 05:14 | <devsnek> | the meaning is not immediately clear |
| 05:15 | <ljharb> | "context" is an extremely overloaded term :-) |
| 05:16 | <leobalter> | RealmBoundary, it's ugly but heh |
| 05:17 | <shu> | legendecas: "Realm" already means a thing as a spec term in HTML that won't match up to user Realms |
| 05:18 | <shu> | so we can end up in a situation where we have to say "spec Realm" vs "user Realm" or something, which doesn't seem great |
| 05:19 | <leobalter> | shu: to confirm, you said you don't like CallableBoundary, right? |
| 05:20 | <shu> | i didn't say that, i said i'm fine with the name, probably something like "perfectly neutral" |
| 05:20 | <shu> | it's a weird name, but no weirder than Realm |
| 05:20 | <leobalter> | oh I see |
| 05:20 | <leobalter> | no weirder than Realm, but it distinguishes from the html Realms you mentioned |
| 05:20 | <shu> | yeah |
| 05:21 | <leobalter> | from this perspective Atomics could mean many things, specially to those who don't use shared buffers |
| 05:21 | <leobalter> | (I like Atomics, and this is not a criticism to it) |
| 05:21 | <devsnek> | GlobalFactory |
| 05:22 | <leobalter> | devsnek: that assumes a subset of usage |
| 05:22 | <devsnek> | does it? |
| 05:23 | <legendecas> | IIUC it can run codes, but not only construct a global |
| 05:23 | <devsnek> | running code uses the globals |
| 05:23 | <devsnek> | but i see your point :( |
| 05:24 | <ljharb> | x factories make x's |
| 05:27 | <ljharb> | can we maybe cut short debate about the efficacy of ecma's technology |
| 05:27 | <ryzokuken> | yeah |
| 05:27 | <bakkot> | do we need this in the notes? because I am getting tired of transcribing this |
| 05:27 | <Aki> | no\ |
| 05:27 | <bakkot> | k I will kill it |
| 05:27 | <Aki> | in fact absolutely not |
| 05:27 | <Aki> | it's not time yet |
| 05:27 | <ljharb> | we probably shouldn't have it in the notes anyways if ecma wants it not public |
| 05:28 | <Aki> | if we have time after this to have littledan talk about realms stuff, could you fire it back up? |
| 05:28 | <bakkot> | yup |
| 05:28 | <Aki> | ty |
| 05:28 | <leobalter> | shu: I wonder if we should use the W3C-TAG review to get feedback on the name? |
| 05:29 | <bakkot> | we have it transcribed so far; if you don't want that published, delete it |
| 05:29 | <leobalter> | At least three people actively reviewed Realms there and they might come with some interesting ideas that is also web friendly |
| 05:32 | <shu> | leobalter: ehh, i don't think this is a good use of TAG's time |
| 05:32 | <shu> | they're overloaded as it is |
| 05:33 | <leobalter> | no problem, just verifying the next steps. |
| 05:33 | <devsnek> | i also did not hear this from what ujjwal said, thank you aki |
| 05:33 | <danielrosenwasser> | Yes, I think Aki's answer was helpful and direct |
| 05:33 | <ryzokuken> | 😅 Thanks Aki! |
| 05:34 | <leobalter> | shu: I'll roll some internal work with my team so I hopefully bring you a few suggestions |
| 05:34 | <shu> | awesome, thanks |
| 05:34 | <leobalter> | Celebration tweet: https://twitter.com/leobalter/status/1415544635934396418 |
| 05:35 | <devsnek> | don't celebrate yet, it could end up with a name you hate :^) |
| 05:35 | <leobalter> | I really don't mind on the name |
| 05:37 | <leobalter> | You can call it DemiIsolatedRealmCommunicationChannel and if I have the feature working I'm happy |
| 05:38 | <shu> | i don't think the extra resources angle affects tc39, does it? it might affect other tcs |
| 05:38 | <shu> | we have our own copies of everything |
| 05:38 | <ljharb> | potentially tho it might mean we no longer need to invent our own solutions to every problem |
| 05:38 | <Aki> | FALSE |
| 05:39 | <devsnek> | lol |
| 05:39 | <ljharb> | lol |
| 05:39 | <shu> | ljharb: very skeptical of that, yeah |
| 05:39 | <Aki> | IT AFFECTS US. it affects the chairs. it affects me. |
| 05:39 | <ljharb> | lol i put the hedge word in there |
| 05:39 | <Aki> | extra resources is a big sell for me |
| 05:39 | <ljharb> | oh wait, which part is false? |
| 05:39 | <shu> | Aki: elaborate? |
| 05:39 | <shu> | what more resources would you like to get from LF for chairs? |
| 05:39 | <Aki> | our disfunctional email address, to start |
| 05:40 | <Aki> | we've been trying to get IT to fix that for like three years |
| 05:40 | <shu> | i... okay |
| 05:40 | <ljharb> | LF/openjs's devops is pretty good ime |
| 05:40 | <shu> | there is a mile-wide chasm to me between "working email aliases" and "let's change by-laws"? |
| 05:40 | <Aki> | i want a matrix homeserver. i want a paid discourse host |
| 05:40 | <Aki> | my point is there's a ton of infra stuff |
| 05:40 | <Aki> | that does really matter |
| 05:41 | <shu> | okay |
| 05:41 | <Bradford Smith> | was there a decision to stop taking note that I missed, or should I raise a point of order? |
| 05:41 | <devsnek> | shu it does sound like there is not GA consensus on the scary bylaw stuff |
| 05:41 | <Aki> | including spending our dues in a more efficient way taking advantage of the LF's existing infra |
| 05:41 | <ljharb> | was there a decision to stop taking note that I missed, or should I raise a point of order? |
| 05:50 | <Michael Ficarra> | Istvan is aware we've abandoned the typesetting thing because of all the strings attached to the funding, right? |
| 05:50 | <Michael Ficarra> | I certainly wouldn't hold that up as an example of a successful funding request process |
| 05:50 | <ljharb> | Aki: your queue item is exactly what popped into my head, glad you're saying it |
| 05:51 | <littledan> | We didn't abandon it, it's just that I didn't argue it out yet |
| 05:51 | <littledan> | I am kinda the bottleneck |
| 05:51 | <littledan> | The queue isn't working for me |
| 05:51 | <Aki> | refresh? |
| 05:51 | <littledan> | I have more requests to forward up |
| 05:54 | <littledan> | +1000 to what Aki is saying; this is sort of my barrier |
| 05:54 | <ljharb> | +1 also, they should be aggressively figuring out how to spend money to help us; we shouldn't have to always ask |
| 05:55 | <ryzokuken> | littledan: I understand what you mean by "I'm the bottleneck" but I think it's highly unfair. |
| 05:55 | <littledan> | I asked some people in committee to write more formal documents to describe funding requests, that didn't end up happening, and I didn't write them either |
| 05:55 | <ryzokuken> | why does it fall upon you (or anyone from us) to navigate a labyrinth in order to get the most basic stuff done? |
| 05:55 | <littledan> | Well, I volunteered |
| 05:56 | <ryzokuken> | if you didn't, someone else would have to |
| 05:56 | <ryzokuken> | things like these should work by default, is what I mean |
| 05:56 | <littledan> | I agree with Aki, we need a push model with actual people whose job it is to help us |
| 05:56 | <ryzokuken> | I guess that's close to what Aki's point was too, that there's just a lot of work to make things work |
| 05:57 | <littledan> | We are collectively paying lots of money, it should partly go to solving our problems |
| 05:57 | <ryzokuken> | We are collectively paying lots of money, it should partly go to solving our problems |
| 05:57 | <shu> | on that note i wanna get to waldemar's queue item |
| 05:57 | <Aki> | 🤔 |
| 05:57 | <shu> | are dues changing? |
| 05:57 | <littledan> | We are collectively paying lots of money, it should partly go to solving our problems |
| 05:57 | <littledan> | are dues changing? |
| 05:58 | <shu> | yes, and waldemar is going to ask |
| 05:58 | <shu> | so let's advance the queue |
| 05:58 | <ryzokuken> | shu: for Google, yes. IIUC the plan is to reduce them somewhat for organizations that are members of both LF and ECMA |
| 05:58 | <Aki> | littledan: can we skip you |
| 06:00 | <Aki> | i have to run y'all, but one final thought: the plan was for the negotiations to be done (-ish, done for another round of discussion) by July 21, so please don't read "i don't know" as duplicitousness (edit typo) |
| 06:01 | <iain> | ryzokuken: Do you have any information about changes to dues for organizations that are not members of LF? |
| 06:01 | <Aki> | iain: "no change" last i heard |
| 06:01 | <ryzokuken> | iain: I would need to recheck but yeah "no change" |
| 06:02 | <littledan> | A change in dues structure has long been under discussion in Ecma, so I am not surprised that it is part of an Ecma modernization package |
| 06:02 | <ryzokuken> | but this would incentivize all of us non-LF members to work with them (because the cost of joining now comes down). |
| 06:04 | <littledan> | My understanding was that cross-participation comes with extra fees, so this isn't an Ecma-is-bankrupt scenario |
| 06:05 | <ljharb> | so do we have a meeting tomorrow still? |
| 06:05 | <Michael Ficarra> | oh I didn't realise this was the final topic of the meeting |
| 06:05 | <ljharb> | draft schedule's empty |
| 06:05 | <devsnek> | ironically jory's post on the reflector 18 days ago is pretty clear in comparison to the information we obtained during this meeting https://github.com/tc39/Reflector/issues/386#issue-930822046 |
| 06:07 | <HE Shi-Jun> | Could we have a document with more details about the changes (include fees)? Some Chinese members are both Ecma and LF members but no delegate on the call, they would like to read the document. |
| 06:07 | <ryzokuken> | HE Shi-Jun: that's the deal |
| 06:07 | <ryzokuken> | we'd post the documents on the reflector |
| 06:07 | <Aki> | HE Shi-Jun: once they're available, i'll make sure they're shared |
| 06:07 | <ryzokuken> | so you can review them and discuss them with other delegates |
| 06:07 | <ljharb> | the implication to me tho is that fees won't go up for anyone; they just might go down for members of both? |
| 06:08 | <HE Shi-Jun> | Thank you! |
| 06:14 | <littledan> | the implication to me tho is that fees won't go up for anyone; they just might go down for members of both? |
| 20:19 | <ryzokuken> | could someone with edit access to the TC39 calendar remove delete the Friday session? |
| 23:22 | <shu> | i couldn't, even though i have access to the calendar. probably that item isn't editable by others |
| 23:22 | <shu> | ljharb: ^ |
| 23:28 | <ljharb> | 👀 |
| 23:29 | <ljharb> | done |