| 01:42 | <jmdyck> | Bakkot: What's the next step after #1914? |
| 02:11 | <devsnek> | shu: what is the equiv of #node-dev for v8 |
| 02:11 | <devsnek> | v8-dev mailing list? |
| 02:28 | <shu> | devsnek: yeah |
| 02:33 | <devsnek> | would be nice if V8 had some sync chat setup 😢 |
| 02:38 | <Bakkot> | jmdyck: next step is to make abstract operations which do not need to return completions actually not return completions, and note which type each abstract operation returns |
| 02:39 | <Bakkot> | and then make sure that consumers of abstract operations treat their return values as completions or not as completions, as appropriate |
| 02:39 | <Bakkot> | also to add more type annotations to the arguments for abstract operations; currently there's some but there could be more - possibly just all of them |
| 02:40 | <Bakkot> | but those two things are sort of orthogonal; the motivation for 1914 was so that I could have a consistent place to note the return types, not so much the argument types (that is just a bonus) |
| 02:41 | <jmdyck> | But if you have two PRs, they're going to collide a lot, unless one goes first and gets merged before starting the second, no? |
| 02:42 | <Bakkot> | yup, that's a true thing |
| 02:44 | <jmdyck> | So the return value one goes first? |
| 02:46 | <Bakkot> | The return value one is a higher priority for me, so if I'm doing the work, yes, that's the one I'm planning on doing first. If you (or anyone else) felt inclined to do either of them I'd happily review in whatever order and rebase my work on top of that. |
| 02:46 | <jmdyck> | ok, thx |
| 02:49 | <Bakkot> | I expect it to be a minimum of a week before I have time to start doing this myself, incidentally, though I might end up bored some weekend and knock it out |
| 03:42 | <jmdyck> | Bakkot: I notice that 1914 didn't normalize the preambles of BigInt::* ops |
| 03:42 | <jmdyck> | why's that? |
| 03:43 | <Bakkot> | the namespaced ones are kind of weird in general |
| 03:44 | <Bakkot> | (it also didn't do the Number ones) |
| 03:50 | <Bakkot> | Looking through this again, I guess the wording I ended up with would work fine for these; maybe it is worth adding them too. |
| 03:51 | <Bakkot> | it ends up being significantly less informative since they almost all take and return the same types, but whatever. |
| 03:54 | <jmdyck> | You could argue that https://tc39.es/ecma262/#table-numeric-type-ops (and the preceding paragraph) obviate the preambles. |
| 03:55 | <jmdyck> | (mostly) |
| 03:57 | <Bakkot> | Yeah, though in that case we should remove e.g. the "The abstract operation BigInt::signedRightShift with arguments x and y of type BigInt performs the following steps:" bits |
| 03:58 | <jmdyck> | You'd be in favor of such removals? |
| 03:59 | <Bakkot> | well, either that or putting them all in after all |
| 03:59 | <jmdyck> | ok |
| 03:59 | <Bakkot> | I am leaning towards putting them all in given how #1914 ended up - I originally removed the totally redundant ones but we ended up putting those back, and adding new totally redundant ones where they were previously missing |
| 03:59 | <Bakkot> | might as well go all the way, I guess. |
| 04:01 | <ljharb> | sgtm |
| 17:32 | <chicoxyzzy> | devsnek: what are the differences between https://github.com/devsnek/esvu and jsvu? |
| 17:36 | <devsnek> | chicoxyzzy: jsvu does native binaries and esvu does anything with a consistent download location |
| 17:37 | <rkirsling> | JSC is still behaving okay via esvu, right? |
| 17:37 | <chicoxyzzy> | devsnek: thanks for the explanation! |
| 17:37 | <rkirsling> | i.e. test262 infra is doing something weird on top of it? |
| 17:37 | <devsnek> | I haven't explicitly checked but it's the same binary either way |
| 17:38 | <rkirsling> | yeah |
| 17:59 | <jridgewell> | https://www.irccloud.com/pastebin/vY8trIjf/eshost-assign-to-call |
| 17:59 | <jridgewell> | Weird |
| 18:00 | <devsnek> | the spec says its a syntax error |
| 18:00 | <devsnek> | web browsers don't for compat reasons |
| 18:39 | <devsnek> | wow graaljs is actually really fast |
| 18:53 | <Bakkot> | yeah it's rad |
| 18:53 | <Bakkot> | I talk to them at the llvm dev meeting whenever I go and remember to do that |
| 18:54 | <Bakkot> | I suspect it has a lot of cases where it would have terrible performance for real web code, just on the basis that all engines which have not been optimized for a large corpus of web code have this problem |