| 20:30 | <shu> | another npm noob question: when i ran npm install in ecma262, it basically rewrote package-lock.json from version 1 to version 2 |
| 20:30 | <shu> | i'm guessing i shouldn't actually commit that? am i supposed to run it with some flags? am i using the wrong version of npm? |
| 20:37 | <shu> | ljharb: ^ |
| 20:47 | <bakkot> | shu: yeah, that means you are npm 7 rather than npm 6 |
| 20:47 | <bakkot> | it doesn't much matter though |
| 20:47 | <ljharb> | that's fine, npm 8 is out now too |
| 21:33 | <shu> | thanks |
| 22:00 | <Michael Ficarra> | eww, check out https://tc39.es/ecma262/multipage/abstract-operations.html#sec-stringtobigint |
| 22:00 | <Michael Ficarra> | why did we ever think it was acceptable to specify things that way? |
| 22:02 | <jmdyck> | expediency, probably. |
| 22:02 | <Michael Ficarra> | also, it returns a BigInt or NaN, which is very weird |
| 22:03 | <Michael Ficarra> | jmdyck: it seems like they wanted to save space or something |
| 22:03 | <ljharb> | expediency and also bigint was a massive spec, so it probably didn't get a thorough enough review. that seems to be a pattern in large proposals - it's easy to miss issues |
| 22:03 | <Michael Ficarra> | agree ljharb, the bigger the review, the more weird stuff slips in |
| 22:04 | <Michael Ficarra> | in big reviews, it's easier to spot little local issues than big oddities |
| 22:06 | <bakkot> | it wouldn't even be that hard to factor out a "string to MV" AO and then use it in both places |
| 22:07 | <bakkot> | we already have such an AO but not over this grammar, I guess |
| 22:08 | <Michael Ficarra> | bakkot: PRs welcome |
| 22:09 | <jmdyck> | In my notes, I've got some steps. I'd have to check them over. |
| 22:12 | <shu> | okay, a first draft of can-call-user-code at https://ci.tc39.es/preview/tc39/ecma262/sha/a5ba1ae3a48e8cffb1e6051bc97dceace591af20/ |
| 22:12 | <jmdyck> | I'll probably have time this weekend. |
| 22:12 | <shu> | press 'u' to toggle the 'UC' annotation on AO links |
| 22:12 | <shu> | play around, it's probably way too conservative and we need a bunch of manual supprsesions |
| 22:13 | <shu> | somewhat expectedly and unfortunately, everything can call user code |
| 22:15 | <ljharb> | the "u" stuff is verryyyyyy slow to respond |
| 22:15 | <ljharb> | how are you changing the visibility? |
| 22:15 | <ljharb> | the way i'd assume is fastest is a single css class applied or removed to html or body, and have that class change something that doesn't case a reflow |
| 22:16 | <ljharb> | so, i don't see an annotation on https://ci.tc39.es/preview/tc39/ecma262/sha/a5ba1ae3a48e8cffb1e6051bc97dceace591af20/#sec-isregexp even tho it contains a step that has one - is that expected? |
| 22:16 | <ljharb> | it'd also be super useful to show the AO-level annotation in the TOC on the left pane, as well |
| 22:17 | <shu> | it is a terrible hack |
| 22:17 | <shu> | look at the "e-user-code" class |
| 22:18 | <shu> | it has a ::before that has the 'UC' |
| 22:18 | <shu> | however, since i can't directly toggle ::before visibility, i have a big of JS that injects a <style> tag with .e-user-code::before { display: block !important } when you press u |
| 22:18 | <shu> | we definitely should not ship with this |
| 22:18 | <ljharb> | why can't you? |
| 22:18 | <shu> | how... do you? |
| 22:19 | <shu> | i can't select for it |
| 22:19 | <ljharb> | if you have two ::before blocks they don't control the same content? |
| 22:19 | <ljharb> | i haven't messed with native css in awhile |
| 22:19 | <shu> | yes, and that's what i do |
| 22:19 | <shu> | with that style injection hack |
| 22:20 | <shu> | but that's probably why it's so slow |
| 22:21 | <ljharb> | gotcha |
| 22:21 | <ljharb> | i wonder if it'd be faster tho to have the styles be always there |
| 22:22 | <ljharb> | like |
| 22:22 | <shu> | oh maybe, patches welcome? |
| 22:23 | <ljharb> | opacity as opposed to display, so that the document doesn't have to reflow, because the UC content will always be there |
| 22:23 | <shu> | anyway i don't think we should do any optimization work here until we hash out how we actually want to render these |
| 22:23 | <ljharb> | fair enough |
| 22:23 | <shu> | just needed something to debug and see the false positives |
| 22:23 | <ljharb> | right |
| 22:23 | <shu> | most of the false positives i've seen so far are of the integer coercion flavor |
| 22:23 | <shu> | where we know something we're coercing is a number we constructed internally or something |
| 22:28 | <ljharb> | another is https://ci.tc39.es/preview/tc39/ecma262/sha/a5ba1ae3a48e8cffb1e6051bc97dceace591af20/#sec-createregexpstringiterator which is kind of the same case |
| 22:28 | <ljharb> | iow, technically if you called that AO with a user-provided regex, the annotations are correct; but it's only ever called with a spec-fiction-regex, so they're not |
| 22:28 | <ljharb> | there's probably a similar case with async iteration |
| 22:28 | <Michael Ficarra> | I was expecting a badge more like |
| 22:29 | <shu> | ljharb: awesome, please note them down in a comment :) |
| 22:30 | <shu> | Michael Ficarra: that would reflow, right? would be slower for sure |
| 22:30 | <shu> | visually wfm |
| 22:30 | <Michael Ficarra> | oops, simplified should be small-caps |
| 22:30 | <Michael Ficarra> | it would reflow, but I'm not all that against reflow |
| 22:30 | <shu> | yeah, we can discuss rendering at the next call or after the next plenary |
| 22:31 | <shu> | i have very little opinion here other than that it be nice and clear |
| 22:31 | <shu> | i think my only bar is "no low contrast crap" |
| 22:34 | <Michael Ficarra> | yeah, well using a class on <html> as ljharb suggests should be faster than the current hack of inserting a new stylesheet |
| 22:34 | <Michael Ficarra> | I would start there |
| 22:36 | <shu> | i wonder if we can farm out the task of finding false positives out to committee delegates... 😈 |
| 22:41 | <Michael Ficarra> | just merge it, and with enough time ... |
| 22:42 | <ljharb> | lol |
| 23:27 | <bakkot> | shu: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ruby |
| 23:36 | <Michael Ficarra> | bakkot: we talked about that at the editor call |