| 00:31 | <rkirsling> | <continuing> yeah I guess I just assumed that indirect eval could never be returned to being direct eval but apparently that's false |
| 00:33 | <shu> | yeah, it's not a taint tracking model, it's much more brilliant where we just pick on one particular identifier :P |
| 00:34 | <devsnek> | you can rename `eval` to `evil` and then you don't have to use (0, eval) |
| 00:38 | <rkirsling> | shu: lol |
| 00:41 | <devsnek> | am i the only one bothered by `promiseResolve` being after `promiseCapability` in that recent patch |
| 00:42 | <rkirsling> | devsnek: but isn't that `evil` somewhat less evil than `eval` then |
| 00:42 | <devsnek> | a non-zero amount of evil is still evil |
| 00:58 | <rkirsling> | bakkot_: devsnek: do you either of you have an opinion about what you expected eval?.() to be? |
| 00:59 | <bakkot_> | not especially |
| 00:59 | <devsnek> | i can't construct any meaningful rule about direct/indirect evals |
| 01:34 | <shu> | wait till you hear about ablative eval |
| 01:35 | <bakkot_> | eval, but every time you use it one random name in scope is removed |
| 01:37 | <shu> | that is the suffering passive |
| 01:38 | <rkirsling> | et tu eval |
| 02:16 | <rkirsling> | ugh I think I'll still create an issue before the PR just so the PR doesn't come off like an attack |
| 03:10 | <ljharb> | rkirsling: up to you, but i doubt that would be a problem |
| 03:10 | <rkirsling> | ljharb: played it safe -- https://github.com/tc39/ecma262/issues/2062 https://github.com/tc39/ecma262/issues/2063 |
| 13:10 | <devsnek> | ljharb: https://www.python.org/dev/peps/pep-0622/ |
| 15:41 | <jorendorff> | littledan: thanks for your comment in https://github.com/tc39/proposal-promise-any/issues/38 ... i didn't say anything, but i agree |
| 15:42 | <bradleymeck> | jridgewell: are there any major blocking points on private declarations recently |
| 15:42 | <jridgewell> | Just waiting for private fields to ship before bringing it up again |
| 15:43 | <jorendorff> | littledan: it bothered me a little bit that Mark didn't reply to https://github.com/tc39/proposal-promise-any/issues/38#issuecomment-634822974 |
| 15:44 | <jorendorff> | I'd love to understand what invariant is being proposed |
| 15:45 | <bradleymeck> | jridgewell: was the `outer` contextual keyword just to remove the [] / simplify the grammar? |
| 15:46 | <jorendorff> | or ... invoked, or whatever |
| 15:47 | <bradleymeck> | jorendorff: all those internal slots are not reflected to JS as first class APIs |
| 15:47 | <jridgewell> | `outer` seems the simplest solution, and avoids me having to explain reification |
| 15:48 | <devsnek> | what is `outer` |
| 15:48 | <jridgewell> | `class Foo { [#bar] = 1 }` seems too much like I've reified the key and can use it as a value |
| 15:48 | <bradleymeck> | jorendorff: the concern is around an internal slot not being able to be intercepted via a hook like other meta-object-protocol hooks |
| 15:48 | <devsnek> | oh for shared private fields |
| 15:48 | <devsnek> | can we not just reify them as values |
| 15:48 | <bradleymeck> | jridgewell: idc either way XD, it can be reified even if it isn't in the same value space! |
| 15:48 | <jorendorff> | bradleymeck: I don't understand the "as first class APIs" part of the distinction |
| 15:48 | <bradleymeck> | lets not add value spaces |
| 15:49 | <jridgewell> | https://github.com/tc39/proposal-private-declarations |
| 15:49 | <devsnek> | why do we need first class syntax for this aaaa |
| 15:49 | <bradleymeck> | jorendorff: fn.environment isn't a thing, basically even if the internal slot stores state it isn't able to be reached by user JS |
| 15:49 | <jorendorff> | bradleymeck: [[Prototype]] has a getter (`.__proto__`) |
| 15:50 | <bradleymeck> | yes, and that has a Proxy MOP hook |
| 15:51 | <jorendorff> | bradleymeck: [[ViewedArrayBuffer]] also has a getter https://tc39.es/ecma262/#sec-get-%typedarray%.prototype.buffer |
| 15:51 | <bradleymeck> | devsnek: to get me to stop using super override? |
| 15:51 | <devsnek> | bradleymeck: i mean why are we not just making them values |
| 15:51 | <bradleymeck> | jorendorff: yes, and a review of stuff was being done by caridy about all those cases as they break membranes. |
| 15:51 | <devsnek> | making a private version of every possible use of properties seems like a poor design path |
| 15:52 | <bradleymeck> | devsnek: because lack of prototype lookup would be hella confusing |
| 15:52 | <jridgewell> | Making a private field value is difficult to get through |
| 15:52 | <devsnek> | it doesn't have to lack prototype lookup |
| 15:52 | <bradleymeck> | devsnek: i'd state it must |
| 15:52 | <devsnek> | why lol |
| 15:52 | <bradleymeck> | match fields |
| 15:52 | <devsnek> | ? |
| 15:52 | <bradleymeck> | also matches weakmaps |
| 15:53 | <devsnek> | we aren't making weakmaps we're making access control |
| 15:53 | <bradleymeck> | basically private lookups in JS haven't historically been delegated |
| 15:53 | <bradleymeck> | internal slots, private fields, weak map, all of them do not delegate |
| 15:54 | <bradleymeck> | so, it should be something else if it seeks to delegate |
| 15:54 | <devsnek> | first class access control doesn't exist in js yet |
| 15:54 | <jorendorff> | i'm a little confused as to whether we're having one conversation or two |
| 15:54 | <bradleymeck> | what isn't first class? |
| 15:54 | <bradleymeck> | jorendorff: I am having 2 |
| 15:55 | <jorendorff> | great |
| 15:55 | <jridgewell> | I think there are 2 |
| 15:55 | <devsnek> | there was a discussion about private field syntax |
| 15:55 | <devsnek> | and i'm ranting about private symbols |
| 15:55 | <jorendorff> | bradleymeck: so another example is that Map and Set are nothing *but* methods that provide access to data stored in private slots |
| 15:56 | <bradleymeck> | jorendorff: per your topic ECMA402 was at the SES meeting (2?) times ago and wanted to plug a similar hole |
| 15:57 | <bradleymeck> | jorendorff: yes, but the concern isn't about the values themselves it is the ability to intercept things |
| 15:57 | <jorendorff> | bradleymeck: ok, intercept how? |
| 15:57 | <bradleymeck> | you can to some extent replace builtin methods to "patch" out the issue, but there is push back even within the Realms call (not just SES) |
| 15:58 | <bradleymeck> | jorendorff: replace methods with userland wrappers |
| 15:58 | <jorendorff> | bradleymeck: it should be possible to express this clearly, as an adversarial game perhaps |
| 15:58 | <jorendorff> | bradleymeck: but if there is a known technique for this (replace features on the builtin prototype) then it would work just as well for new things as for existing things |
| 15:58 | <bradleymeck> | various membranes have to do this where they freeze Map.prototype, but have to replace all the methods in order to intercept the values in/out |
| 15:58 | <bradleymeck> | jorendorff: it isn't actually applied to all kinds of membranes |
| 15:59 | <bradleymeck> | a lot of things like salesforce have much more minimal membranes and would wrap the Map as it crosses rather than each .get/.set |
| 16:00 | <devsnek> | i need to join an ses call at some point to ask about boxes for records |
| 16:00 | <bradleymeck> | its really the realms call |
| 16:00 | <bradleymeck> | like 50% of people there aren't using SES |
| 16:00 | <devsnek> | whoever it is that takes issue with boxes |
| 16:00 | <bradleymeck> | the concerns are just that you cannot intercept these internal slot lookups with a Proxy |
| 16:00 | <bradleymeck> | devsnek: thats the call you want to join |
| 16:01 | <devsnek> | which |
| 16:01 | <bradleymeck> | you can even add it to the agenda https://docs.google.com/document/d/1FZ95-NZIQE9fw3A8Sgcz2BKep6MlC_Kng0dlf1ehabQ/edit#heading=h.f8mfwudm59mq |
| 16:02 | <bradleymeck> | devsnek: its on the tc39 calendar "SES Strategy - Weekly" (had that name for years) |
| 16:02 | <devsnek> | > We had an engaging conversation with the champions of Records and Tuples, and the related proposals for deep paths and boxes. |
| 16:02 | <bradleymeck> | https://calendar.google.com/calendar/embed?src=mozilla.com_l7b50itpaa9bnrvr61nebqrne8%40group.calendar.google.com&ctz=America%2FChicago |
| 16:02 | <devsnek> | i guess there's no notes policy for these |
| 16:02 | <bradleymeck> | devsnek: they are recorded to youtube |
| 16:02 | <bradleymeck> | https://www.youtube.com/channel/UCpY91oQLh_Lp0mitdZ5bYWg/videos |
| 16:05 | <devsnek> | oh nice |
| 16:06 | <jorendorff> | bradleymeck: it's a known flaw of proxies that they can't intercept internal slot lookups. but normally the result of that is that access fails (e.g. RequireInternalSlot is attempted on a proxy; it'll always fail and throw) |
| 16:06 | <jorendorff> | bradleymeck: are we talking about some scenario in which access can't be blocked? |
| 16:06 | <devsnek> | my private symbols setup allowed you to pass symbols you wanted to intercept to the proxy constructor |
| 16:07 | <jridgewell> | https://www.youtube.com/watch?v=QzASLxg2VIk |
| 16:07 | <devsnek> | maybe something similar could be done with private fields |
| 16:07 | <bradleymeck> | jorendorff: having a 2nd context that has a builtin and running it on the value as a receiver |
| 16:07 | <devsnek> | though they'd need to be reified in some way for that |
| 16:07 | <bradleymeck> | jorendorff: join the call this week as this topic is the only agenda item? |
| 16:08 | <bradleymeck> | i'm just explaining the concern to my understanding |
| 16:08 | <jorendorff> | I'd so much rather have this written down somewhere |
| 16:09 | <jorendorff> | but maybe we can work toward that |
| 16:09 | <bradleymeck> | jorendorff: it will be recorded at least |
| 16:09 | <jorendorff> | bradleymeck: I don't see the Realms meeting on the TC39 calendar |
| 16:09 | <jorendorff> | I see an SES Strategy meeting |
| 16:11 | <bradleymeck> | jorendorff: yes thats the call. it has had that name for years / has historically been the focus but SES as a proposal has started splitting up into other things like Realms/Compartments these days |
| 16:11 | <jorendorff> | ugh, i can't make it this week, it's the one day i have an appointment i can't move :-P |
| 16:12 | <devsnek> | it would be cool if compartments had a hook for math.random |
| 16:12 | <devsnek> | either seeding it or just controlling it outright |
| 16:12 | <bradleymeck> | devsnek: just replace the global XD |
| 16:12 | <devsnek> | i guess |
| 16:13 | <bradleymeck> | Realms/Compartments are seeing pretty big pushback due to how much they do already so they got stripped down once |
| 16:13 | <devsnek> | couldn't it get access to the original by creating a new realm |
| 16:13 | <littledan> | jorendorff: We're planning on discussing this topic in the SES call tomorrow |
| 16:14 | <bradleymeck> | devsnek: yes, you have to wrap the Realm constructor :-/ |
| 16:14 | <littledan> | the SES Strategy meeting |
| 16:14 | <jorendorff> | littledan: I can't make that meeting, unfortunately, but maybe someone from Moz can be there |
| 16:14 | <devsnek> | bradleymeck: also, seeding might be preferable for perf reasons |
| 16:14 | <bradleymeck> | we had a bunch of talks about how to not force people to wrap the realm constructor |
| 16:14 | <devsnek> | well its not that big a deal except for |
| 16:14 | <devsnek> | Date.now |
| 16:14 | <devsnek> | Math.random |
| 16:14 | <devsnek> | Symbol.for |
| 16:15 | <devsnek> | is there anything else |
| 16:15 | <bradleymeck> | there are a variety of things you have to wrap, but if you don't wrap then you have to make a composition model and some people didn't like that |
| 16:15 | <devsnek> | could have a hook for CreateRealm |
| 16:16 | <devsnek> | hm i guess we sort of already do with InitializeHostDefinedRealm |
| 16:16 | <bradleymeck> | could, but then it needs to nest |
| 16:16 | <devsnek> | yeah i mean realms created inside would automatically delegate to the parent for that |
| 16:16 | <bradleymeck> | a lot of the complaints are about nesting e.g. not having the same Web Settings object faces pushback from some Web standards |
| 16:17 | <jorendorff> | bradleymeck: I still don't understand this: "having a 2nd context that has a builtin and running it on the value as a receiver" |
| 16:17 | <bradleymeck> | yea, the delegation is part of the complaints, because the deeper you go the more costly it is to create another realm |
| 16:17 | <jorendorff> | bradleymeck: because applying any (non-generic) builtin to a proxy will just fail |
| 16:17 | <bradleymeck> | jorendorff: in web terms, make a same origin iframe and use the intrinsic getter function and call it on the value from the original frame |
| 16:18 | <bradleymeck> | membranes that just do deep freezing won't prevent that |
| 16:18 | <jorendorff> | bradleymeck: if there is no Proxy around the value, then I don't understand the complaint that this can't be intercepted. Of course if you don't have a proxy there, you won't be intercepting anything |
| 16:18 | <jorendorff> | if there is a Proxy around the value, the getter just won't work |
| 16:18 | <devsnek> | proposal: `import { #promiseState, #promiseResult } from 'std:private-fields/promise'; new Proxy(promise, handler, { intercept: [#promiseState, #promiseResult] })` |
| 16:18 | <bradleymeck> | jorendorff: agreed on both, but there are people not using Proxies around all values |
| 16:19 | <bradleymeck> | they only put proxies on the boundary |
| 16:21 | <jorendorff> | bradleymeck: well ... I guess I don't understand why such users would complain about private slots |
| 16:21 | <jorendorff> | if there's no proxy there... what is the expectation to be able to intercept something? |
| 16:32 | <jorendorff> | ...Anyway, regardless of such details, a concrete statement of the desired rule would help |
| 17:19 | <annevk> | If someone could refactor InitializeHostDefinedRealm to not be weird that'd be great |
| 17:30 | <ljharb> | devsnek: thanks, i'll add it |
| 17:33 | <shu> | annevk: what's the weirdness? |
| 17:41 | <annevk> | shu: the way you have to allocate global and global this are rather awkward |
| 17:47 | <devsnek> | here's my idea: CreateRealm(global, thisValue) |
| 17:47 | <devsnek> | performs all the intrinsic allocation and setting of globals and stuff |
| 17:47 | <devsnek> | if a host needs to add additional properties after that it can just do that, no need to specifically make a step for it |
| 17:56 | <shu> | devsnek: i think those need to be abstract closures that do the actual creation |
| 17:57 | <shu> | since you presumably want to allocate the new stuff inside the create Realm, not outside of it |
| 17:57 | <shu> | the created* |
| 17:57 | <devsnek> | i'm not entirely sure what you mean |
| 17:57 | <shu> | annevk: how does that sound? passing in closures? |
| 17:59 | <devsnek> | do you mean a closure for performing arbitrary host setup of the realm? |
| 17:59 | <devsnek> | i'm not sure why that needs to be part of the spec |
| 17:59 | <shu> | devsnek: when hosts want to create a global object for a new Realm, it seems most natural to create the global object in the scope of the created Realm instead of somewhere else |
| 18:00 | <devsnek> | OH i see what you mean |
| 18:00 | <devsnek> | yeah that makes sense |
| 18:02 | <annevk> | shu: yeah, something like that would be good |
| 18:02 | <shu> | annevk: i'm still working on a relatively large PR that separates out the notion of a "host" as an implementation that layers with ecma262 via some set of enumerated host APIs instead of any arbitrary implementation-defined/dependent points |
| 18:03 | <shu> | annevk: i'll put this on the queue after that |
| 18:03 | <annevk> | \o/ |
| 18:26 | <devsnek> | jsc people, why are all the releases missing https://webkitgtk.org/jsc-built-products/x86_64/release/ |
| 18:26 | <devsnek> | rkirsling: ^ |
| 18:29 | <rkirsling> | webkitgtk is its own project so you'd have to ask an Igalian that works on it |
| 18:36 | <rkirsling> | the JSCOnly builders don't have an archive upload step (https://build.webkit.org/waterfall?category=misc) but GTK build archives are located at the usual archive.webkit.org (e.g. https://build.webkit.org/builders/GTK%20Linux%2064-bit%20Release%20%28Build%29/builds/35021/steps/transfer-to-s3/logs/stdio) |
| 18:36 | <rkirsling> | so at a glance, I don't think anything for webkitgtk.org would happen automatically |
| 18:39 | <devsnek> | https://gc.gy/60728945.png |
| 18:44 | <rkirsling> | I don't know what that's coming from |
| 18:48 | <devsnek> | rkirsling: archives.webkit.org uploads a zip with README.md containing that |
| 18:49 | <devsnek> | luckily i found a way to get around that |
| 18:49 | <devsnek> | https://github.com/devsnek/esvu/commit/988ed899cd126f5faab8f63634c7459f7d2c182d |
| 18:49 | <rkirsling> | oh I see |
| 18:52 | <devsnek> | these archives are huge |
