| 00:09 | <jschoi> | Many SMP code points (surrogate pairs) are already valid in identifiers and strings. Are you talking about lone surrogate code points? |
| 00:15 | <Bakkot> | jschoi `\uLEAD\uTRAIL` is never legal in an identifier |
| 00:15 | <Bakkot> | the grammar allows it but an early error rule forbids it (specifically https://tc39.es/ecma262/#sec-identifier-names-static-semantics-early-errors ) |
| 00:22 | <jschoi> | Isn’t \uLEAD illegal because LEAD isn’t a hexadecimal code? |
| 00:22 | <jschoi> | Though I need to reread the spec. |
| 00:24 | <Bakkot> | sorry, that's a shorthand |
| 00:24 | <Bakkot> | I mean to say that, for example, `\ud835\udc9c` is never legal in an identifier |
| 00:25 | <Bakkot> | even though directly using the code point represented by that pair of surrogates, 𝒜, is |
| 00:31 | <michaelficarra> | and we should change that because it's ridiculous |
| 00:35 | <rkirsling> | I mean somebody could propose it, and then if it gets blocked as predicted we'd have it on the record :P |
| 00:37 | <michaelficarra> | there's no reason to allow only BMP characters to be escaped in identifiers, who is going to argue for that? |
| 00:38 | <Bakkot> | you can use `\u{}` to put any code point in an identifier |
| 00:38 | <Bakkot> | well, any ID_part |
| 00:38 | <Bakkot> | so this would just be adding another way to do it |
| 00:38 | <Bakkot> | and this way involves surrogate pairs |
| 00:39 | <Bakkot> | which many people want to not put in new places |
| 00:41 | <devsnek> | i'd be against surrogate pairs in more places |
| 00:41 | <devsnek> | our language doesn't have to be utf16 |
| 00:42 | <devsnek> | :( |
| 00:42 | <michaelficarra> | so with this mental model \uXXXX is just shorthand for BMP \u{...} |
| 00:42 | <Bakkot> | I wish our language was utf16, but it's not even that |
| 00:42 | <michaelficarra> | devsnek: you're in luck, it's not |
| 00:42 | <devsnek> | utf16ish |
| 00:42 | <devsnek> | i always do the {} when i do that |
| 00:43 | <michaelficarra> | you use escape sequences in your identifiers? |
| 00:44 | <devsnek> | in strings sometimes |
| 00:44 | <devsnek> | never in identifiers |
| 00:44 | <michaelficarra> | we're just talking about identifiers |
| 00:45 | <devsnek> | if i did them in identifiers i'd use {} too |
| 00:46 | <jschoi> | If \u{} is already legal, then \u with surrogate pairs should be legal; I think the Unicode Standard is clear about that always being the case, regardless of the particular UTF encoding… |
| 00:46 | <michaelficarra> | jschoi: can you point me to any relevant documentation? |
| 00:46 | <jschoi> | Yeah, I need to check again. |
| 00:46 | <jschoi> | I’ll let you know if I do. |
| 00:46 | <michaelficarra> | cool |
| 00:46 | <jschoi> | That is, I think the Standard says surrogate pairs must always be equivalent to their respective SMP points. |
| 00:47 | <jschoi> | But I’ll try to find a citation later. |
| 00:48 | <michaelficarra> | it may not directly apply to our use of escape sequences, but it will at least be a relevant recommendation |
| 00:49 | <devsnek> | surrogate pairs aren't legal in this context |
| 00:49 | <devsnek> | they aren't decoded incorrectly |
| 00:50 | <michaelficarra> | they're not treated equivalently to the code point itself or the escape sequence for the code point either |
| 00:50 | <devsnek> | i guess |
| 00:50 | <michaelficarra> | if Unicode has a recommendation that they're not to be treated differently, I think it'd be relevant |
| 00:50 | <rkirsling> | don't get me wrong, I support the consistency |
| 00:51 | <devsnek> | i don't think any humans at unicode would want there to be pairs in more places at least |
| 00:51 | <rkirsling> | it's just that (Unicode-hat) sffc and mathiasbynens expressed opposition to having surrogate pairs valid in more contexts |
| 00:51 | <rkirsling> | (whether that's an objection or not) |
| 01:01 | <devsnek> | what happens if you remove an item from an array while doing forEach |
| 01:02 | <devsnek> | i think you end up skipping the next element |
| 01:02 | <devsnek> | yeah that seems right |
| 01:02 | <Bakkot> | truth comes out of her well to shame you |
| 01:02 | <jridgewell> | Do you mean via `splice`? |
| 01:03 | <jridgewell> | Bakkot: uhhhh... |
| 01:03 | <devsnek> | splice yes |
| 01:03 | <Bakkot> | nsfw-ish https://en.wikipedia.org/wiki/Truth_Coming_Out_of_Her_Well |
| 01:04 | <devsnek> | i need to do "for each item of cells if cell is x then remove cell" |
| 01:04 | <devsnek> | maybe filter |
| 01:04 | <devsnek> | filter wouldn't be too crazy but |
| 01:04 | <Bakkot> | that sounds like what filter is for |
| 01:04 | <devsnek> | hmm |
| 01:04 | <devsnek> | actually no i can't do it in a callback sigh |
| 01:05 | <devsnek> | https://gc.gy/53494539.png |
| 01:07 | <Bakkot> | what's wrong with a filter? |
| 01:07 | <Bakkot> | is Q a macro? |
| 01:07 | <devsnek> | yeah |
| 01:07 | <Bakkot> | I guess it must be |
| 01:07 | <Bakkot> | makes sense |
| 01:07 | <devsnek> | it expands to a return |
| 01:07 | <devsnek> | if the value is abrupt |
| 01:08 | <devsnek> | yay for macros |
| 01:18 | <devsnek> | mhofman: would marking the values of weakmaps fix the problem here? |
| 01:18 | <devsnek> | i feel like that should work but it seems too easy |
| 01:19 | <devsnek> | (assuming that the key and the value aren't the same object) |
| 01:19 | <mhofman> | then you'd miss a lot of cases where the keys are only accessible through the values |
| 01:21 | <mhofman> | aka obj1 references obj2, which references obj1, and both are mapping each other in the WeakMap |
| 01:21 | <mhofman> | cycles are fun :) |
| 01:22 | <devsnek> | that would leak though, not be collected too soon |
| 01:22 | <mhofman> | correct |
| 01:24 | <devsnek> | i'm having a hard time thinking of an optimal solution |
| 01:26 | <mhofman> | WeakMap are hard. I think the approach taken by polyfills is acceptable, even though they also leak, it's less critical |
| 01:26 | <devsnek> | i can't associate them directly in the way the polyfills do |
| 01:26 | <devsnek> | i don't think... |
| 01:27 | <devsnek> | i still need to have the spec's mapping where the weakmap holds the values |
| 01:29 | <devsnek> | i could just go full ephemeron i guess |
| 01:34 | <mhofman> | I'm way not familiar with all this, but couldn't you have each ObjectValue keep a Map of WeakMap instances where it's a key to the value it's associated with in those WeakMap? |
| 01:34 | <devsnek> | oh i just pinged you on the issue with a possible fix lol |
| 01:34 | <devsnek> | after marking just go through the weakmaps again and check their keys and values |
| 01:34 | <mhofman> | that's basically going ephemeron ;) |
| 01:35 | <devsnek> | yep |
| 01:37 | <mhofman> | from what I remember there is some recursion needed when you deal with ephemerons. I believe you may find more WeakMap keys that need be marked |
| 01:38 | <devsnek> | hmmmmm |
| 01:41 | <mhofman> | I believe the way it could be done is to add the entries of weakmaps to a Map, and everytime you mark a key, you remove the entry and mark the value |
| 01:42 | <mhofman> | s/Map/queue/ |
| 01:45 | <devsnek> | yeah that makes sense |
| 02:02 | <jschoi> | michaelficarra: I was mistaken. The Unicode Standard has no normative requirement that surrogate pairs be always interpreted as their respective SMP points regardless of UTF encoding—nor does it seem to normatively prohibit them in non-UTF-16 encodings. It merely says in Definitions 74 and 75 that surrogate pairs are designed for use in UTF-16. |
| 02:04 | <michaelficarra> | aww that's too bad jschoi |
| 02:04 | <michaelficarra> | I probably won't bring forward a proposal to change identifier then, if it's going to get pushback |
| 03:17 | <devsnek> | ljharb: very exciting that es2017 was finally released :P |
| 03:18 | <ljharb> | lol |
| 03:18 | <ljharb> | there's no way to make a release silently ¯\_(ツ)_/¯ |
| 04:05 | <jmdyck> | hm looks like 1892 needs some fixes. |
| 04:05 | <jmdyck> | sorry, 1869. |
| 04:05 | <ljharb> | jmdyck: tldr? |
| 04:06 | <ljharb> | i'm cutting the spec as we speak, so time's a factor :-) |
| 04:06 | <jmdyck> | I'll see what I can do. |
| 04:06 | <ljharb> | thanks |
| 04:09 | <Bakkot> | oh, I missed the [U] flags on the LHSes in the early error rules |
| 04:09 | <Bakkot> | I never remember to look for the flags there |
| 04:10 | <Bakkot> | the RHSes too I guess |
| 04:10 | <Bakkot> | bah |
| 04:10 | <Bakkot> | that's what I get for writing spec when tired |
| 04:11 | <jmdyck> | and not just early error rules |
| 04:11 | <ljharb> | k well hopefully the PR gets up and gets a review or two tonight, and i'll cut a spec in the morning |
| 04:13 | <Bakkot> | the other SDOs too, yeah |
| 04:15 | <Bakkot> | someday we will have a linter which will stop me from shooting myself in the foot |
| 04:15 | <Bakkot> | someday |
| 04:15 | <Bakkot> | jmdyck is it just the stray flags? |
| 04:15 | <Bakkot> | I can make a PR for that right now if you're busy |
| 04:15 | <jmdyck> | that's all i've found so far, but i'm not finished. |
| 04:15 | <jmdyck> | (flags = gram parameters) |
| 04:17 | <Bakkot> | indeed |
| 04:25 | <devsnek> | oh that's very soon |
| 04:25 | <devsnek> | shu: littledan: would be nice to get this figured out https://github.com/tc39/ecma262/commit/c59502090e2c250cd7e457b5506b92db6b21d153#diff-3540caefa502006d8a33cb1385720803R7599 |
| 04:29 | <jmdyck> | ok, finished analysis, starting pr |
| 04:36 | <jmdyck> | https://github.com/tc39/ecma262/pull/1929 |
| 04:40 | <Bakkot> | jmdyck thanks! |
| 04:40 | <jmdyck> | yw |
| 05:31 | <devsnek> | can someone archive the import.meta repo |
| 11:24 | <littledan> | devsnek: I believe the PR that was merged preserves the invariants that were there before. If you want to add additional invariants, that seems like a good topic for a separate PR. |
| 13:19 | <devsnek> | littledan: job records had realm and scriptormodule which was used when creating the context in RunJobs |
| 13:31 | <littledan> | devsnek: OK, do you think there were any invariants attached to those record fields that we've removed? |
| 13:31 | <littledan> | I think the record fields were removed because they were unused, so I don't really understand the issue |
| 13:32 | <devsnek> | littledan: they were used to set the correct realm and scriptormodule |
| 13:33 | <devsnek> | in EnqueueJob it would grab them from the current execution context |
| 13:34 | <devsnek> | and operations in the spec fail if those slots aren't correctly set |
| 13:34 | <littledan> | yes, they were recorded there. Are you taking the descriptions in table 25 as normative? |
| 13:34 | <littledan> | I thought it ended up being more up to the embedder to use them |
| 13:35 | <devsnek> | I'm not aware of anything that made RunJobs non normative |
| 13:36 | <devsnek> | wasn't the whole problem that RunJobs was normative but no one implemented the RunJobs loop |
| 13:37 | <littledan> | right, RunJobs was "dead spec" in HTML, unfortunately |
| 13:38 | <littledan> | so, the version of the patch that I produced preserved the job records, based on my understanding of TC39 consensus. The editor group decided that it would be OK to remove the job record. I'd follow up with them here. |
| 13:38 | <devsnek> | but regardless of how people treated that section it correctly described how to set up the context and now we don't have that |
| 13:38 | <devsnek> | I'll open an issue or something I guess |
| 13:42 | <littledan> | yes, so I proposed that we preserve that setup |
| 13:43 | <littledan> | an issue sounds like a good place to follow up |
| 15:13 | <shu> | i'm not understanding what makes that normative |
| 15:13 | <devsnek> | shu: what |
| 15:14 | <shu> | devsnek: the contextorrealm stuff for job records |
| 15:14 | <devsnek> | it was normative because it was in the spec and it wasn't normative optional |
| 15:14 | <devsnek> | actually even normative optional stuff is normative |
| 15:15 | <devsnek> | if you wanted to queue a promise job the spec defined how to queue and run them using RunJobs |
| 15:35 | <shu> | it wasn't normative in practice? |
| 15:36 | <shu> | not only was it not used by upstream specs, it was willfully violated by html, as dan said |
| 15:36 | <devsnek> | the loop wasn't but how to run an individual job definitely was |
| 15:37 | <devsnek> | my point is just that we went from the spec correctly saying how to run a job to the spec not correctly saying how to run a job |
| 16:09 | <shu> | what are we saying incorrectly now? |
| 16:10 | <shu> | i mean the realms that were used for promises were in fact not correct before, for html |
| 16:11 | <devsnek> | shu: all engines implemented context setup correctly as RunJobs specified |
| 16:11 | <devsnek> | and still do |
| 16:12 | <shu> | RunJobs wasn't used? |
| 16:12 | <shu> | i'm confused |
| 16:12 | <shu> | what does it mean to implement dead code correctly |
| 16:12 | <devsnek> | the logic within run jobs |
| 16:13 | <devsnek> | the active realm when a promise job is queued |
| 16:13 | <shu> | that's up to the host |
| 16:13 | <devsnek> | needs to be the active realm when the job is run |
| 16:13 | <devsnek> | and all the implementations do that correctly |
| 16:13 | <devsnek> | as far as i know |
| 16:13 | <devsnek> | but we don't specify it |
| 16:14 | <shu> | i'd be happy to look at a PR |
| 16:15 | <shu> | hard for me to understand what exactly is incorrect in deleted dead code |
| 16:17 | <devsnek> | the deleted dead code was correct |
| 16:17 | <devsnek> | aside from the loop |
| 16:17 | <devsnek> | i can make a pr i suppose |
| 16:18 | <shu> | correctness of dead code is just not a well-formed thing, i really don't understand what that means |
| 16:19 | <devsnek> | implementations that weren't browsers |
| 16:19 | <devsnek> | and didn't ignore runjobs |
| 16:19 | <devsnek> | at least didn't ignore it as much as html did |
| 16:19 | <devsnek> | would get a correct implementation of ecmascript by using the steps within the run jobs loop |
| 16:20 | <devsnek> | they will not get a correct implementation of ecmascript by using the description currently in the spec |
| 16:20 | <shu> | the current description requires the implementation to implement HostEnqueuePromiseJob |
| 16:21 | <devsnek> | yes |
| 16:21 | <shu> | and implementations withouts specs are more than welcome to keep the historical invariants in there |
| 16:21 | <devsnek> | i mean the spec literally doesn't function |
| 16:21 | <devsnek> | if the realm isn't set |
| 16:22 | <devsnek> | you will fail an assertion in CreateBuiltinFunction |
| 16:23 | <shu> | if the host hook doesn't set the execution context with script that it's trying to run? |
| 16:23 | <devsnek> | the host hook doesn't have an execution context |
| 16:24 | <shu> | in 8.4, there is a list of invariants describing what host AOs for scheduling jobs must adhere to |
| 16:24 | <shu> | the first bullet point is "Push an execution context onto the execution context stack." |
| 16:24 | <shu> | perhaps you're asking for that list of invariants to be tighter? |
| 16:24 | <devsnek> | yes that's what i keep saying |
| 16:25 | <devsnek> | we need to specify the realm (and maybe scriptormodule) that that execution context uses |
| 16:27 | <shu> | the realm is a per-kind-of-job thing i imagine |
| 16:28 | <devsnek> | perhaps |
| 16:28 | <shu> | for HostEnqueuePromiseJob itself, since we pull out the right realm on our side |
| 16:28 | <devsnek> | i'm not sure what that means |
| 16:28 | <shu> | sorry, i didn't finish the sentence |
| 16:29 | <devsnek> | https://www.irccloud.com/pastebin/BN8eZ53s/maybe_fixed.html |
| 16:29 | <devsnek> | i'm saying we need to do something more like this |
| 16:32 | <devsnek> | and then we just have to specify what _realm_ is for HostEnqueuePromiseJob |
| 16:32 | <shu> | the logic in html is more complicated than that afaiu |
| 16:33 | <devsnek> | the host is kind of a moot point here |
| 16:33 | <devsnek> | the context needs to fulfill invariants of ecmascript itself |
| 16:36 | <devsnek> | in html `set script execution context to a new JavaScript execution context, with its Function field set to null, its Realm field set to active script's settings object's Realm, and its ScriptOrModule set to active script's record.` |
| 16:37 | <shu> | only if the active script is not null |
| 16:37 | <shu> | usually it's the active script's context |
| 16:37 | <devsnek> | in ecmascript that's "the realm of the current execution context" |
| 16:38 | <devsnek> | it never reuses the same context |
| 16:38 | <devsnek> | actually in html it looks like it might run a job with no execution context at all |
| 16:38 | <shu> | it may never make an execution context |
| 16:39 | <devsnek> | that breaks even more stuff lol |
| 16:40 | <devsnek> | and doesn't fulfill ecmascript either ("the implementation must: 1. Push an execution context onto the execution context stack.") |
| 16:43 | <shu> | yeah i don't even know when the active script is null and this host hook would be called |
| 16:44 | <devsnek> | so basically i think we need to give all jobs a ScriptOrModule and a Realm, and set the execution context fields correctly |
| 16:44 | <shu> | tightening up sounds good, could you make a PR? i'd still need to think about it more carefully i have time |
| 16:44 | <devsnek> | where the ScriptOrModule and Realm come from is up to the thing that is queuing at least |
| 16:45 | <shu> | there're two timings for the hooks: enqueue time, and job-running time |
| 16:45 | <devsnek> | i can try to put something together |
| 16:46 | <shu> | execution context creation might not be observable, but since it depends on the active script, which is an observable thing, seems like we need to separate during what time does context creation happen |
| 17:00 | <devsnek> | shu: https://github.com/tc39/ecma262/pull/1934 |
| 17:03 | <shu> | devsnek: thanks, i'll try to get to reviewing it next week. i'm not fully grokking the html part yet |
| 17:03 | <devsnek> | 👍🏻 |
| 17:05 | <shu> | devsnek: something is off there in that we don't always create a new execution context |
| 17:05 | <devsnek> | probably just needs to be "assert that there is an active script" instead of branching |
| 17:05 | <shu> | no, there can definitely be no active script |
| 17:05 | <shu> | that i confirmed |
| 17:05 | <shu> | there is an example below in the spec, with a button onclick |
| 17:06 | <devsnek> | oh ok |
| 17:06 | <shu> | editorially, Job Records were cleaned up for ease of layering |
| 17:06 | <devsnek> | yeah i just thought it would be the easiest way to store the three items together |
| 17:06 | <devsnek> | i'm open to other things |
| 17:06 | <shu> | the invariants might need to be tightened up but i need to think through whether we should say anything more than ensure that stuff can run instead of a particular realm |
| 17:07 | <devsnek> | well i think they need to be tighter than "any random realm" because we are creating observable js objects using that realm |
| 17:07 | <devsnek> | like the promise resolve functions and stuff |
| 20:34 | <jmdyck> | wah, github has internal server error. |
| 20:35 | <ljharb> | https://www.githubstatus.com/ |
| 20:37 | <jmdyck> | guess my upload will have to wait |
| 20:48 | <Bakkot> | because github is down? |
| 20:48 | <Bakkot> | it's off-and-on for me |
