| 00:01 | <sirisian> | I only have 3 of them in my codebase. Very niche. |
| 00:02 | <whosy> | Speaking of niche.. I haven't come across a use-case for that specifically, but I have on occasion wished there was something like a It's weird that my need for this has occurred more than a few times in the past year. (Easy to get around, but still) |
| 00:04 | <bakkot> | Also seems pretty niche? and since the only way for that to work would be to put it on Object.prototype I think we would not want that |
| 00:04 | <bakkot> | both because new things on Object.prototype are scary in several ways, and because it wouldn't work everywhere and it would be very annoying for x[Symbol.self] to just not work when x happens to have a null prototype |
| 05:13 | <littledan> | @bakkot My previous assumption was that we in TC39 would be uncomfortable adding wait because we don’t have a concept of an event loop. Also we would need host integration for stuff like banning it in worklets. But I guess at this point we have other features that get at each of those things (eg Atomics.waitAsync) |
| 05:15 | <littledan> | But at the same time I don’t see a huge disadvantage to using the scheduler namespace (that’s all it amounts to; it’s not like the scheduler object has state) given that we are trying to share APIs across web and non-web environments, WinterCG-style |
| 05:15 | <littledan> | Are there particular design mistakes we might make with scheduler? |
| 05:18 | <bakkot> | I have not thought about scheduler at all and trust the people working on it to do it reasonably well |
| 05:19 | <bakkot> | but "I want to wait for a period of time" is a much more primitive operation than the rest of that API so it seems a shame to require people to think about the much more complex thing in order to get access to the simple thing |
| 05:33 | <littledan> | So I am curious how you feel about the situation with getting random bytes with crypto, which seems like an analogous situation. In both cases, there is just a funny lowercase namespace, no state in the object, and it is possible to implement just that method on the object without the rest of the API if you are subsetting the web platform. |
| 06:03 | <bakkot> | it may be the security person in me but crypto feels like a very reasonable place to be reaching for a large quantity of random bytes |
| 06:04 | <bakkot> | my problem with scheduler is not that it's a namespace per se, just that the namespace is kind of a powertool which is likely to be confusing to people who don't need it, whereas crypto it's pretty obvious what it does and what it's for |
| 12:39 | <littledan> | I'm not aware of any big arguments for why it must be in scheduler, maybe it just feels right to people working on it. In any case, if we want this in TC39, someone should bring a proposal to committee; I'm not sure how much active work there is on scheduler.wait, if any (not that it needs much work). |
| 13:21 | <Michael Ficarra> | does anyone know why Math.sqrt is implementation-approximated in JS? |
| 13:22 | <Michael Ficarra> | Dan Gohman (@sunfishcode) says that wasm has it fully-defined and implementations are actually compatible because they defer to a single hardware instruction on all of their supported architectures |
| 13:22 | <Michael Ficarra> | so why would we allow approximation? |
| 13:22 | <littledan> | that's just what we do for all of those functions, like sin/cos too. My understanding was that it's always been that way, or something. |
| 13:23 | <littledan> | A proposal to make these things more fully-defined sounds like a great idea to me, if implementations are up for it (historically V8 wanted to take shortcuts, not sure how they feel right now) |
| 13:26 | <Michael Ficarra> | well V8 is already doing fully determined sqrt in wasm |
| 13:26 | <littledan> | right I'm optimistic |
| 13:27 | <Michael Ficarra> | I haven't looked recently at whether implementations disagree on some results of sqrt, but I believe they used to |
| 13:27 | <littledan> | I think historical goals around not regressing Octane by making things more accurate have fallen away |
| 13:27 | <Michael Ficarra> | also maybe the hardware support just wasn't there 10 years ago |
| 15:51 | <Michael Ficarra> | I opened a needs-consensus PR: https://github.com/tc39/ecma262/pull/3345 |
| 15:53 | <Michael Ficarra> | it'd be great if someone did the investigation to confirm that modern implementations do indeed already agree on all sqrt input/output pairs |
| 16:03 | <bakkot> | you'd need to ensure this was the case on all the hardware they each support also |
| 17:02 | <leftmostcat (UTC-7)> | It looks like the process for adding a time constraint to the agenda is just to commit directly and push it; is that the case, or should I PR it? |
| 17:03 | <Chris de Almeida> | please always PR |
| 17:03 | <Chris de Almeida> | even if you immediately merge it without review/approval |
| 17:05 | <leftmostcat (UTC-7)> | Alright, thanks. I just saw a couple that looked to have been added without PRs, hence the question. |
| 17:17 | <Chris de Almeida> | yes, people do that, and it's acceptable, but not ideal 🙂 |
| 18:09 | <shu> | what's the difference? |
| 18:21 | <Michael Ficarra> | @shu whether people watching the repo get pinged about it or not |
| 18:33 | <Michael Ficarra> | Dan Gohman brings up another good point: should we put some kind of lower bound on what we mean by "implementation-approximated"? Should a Math.cos that only returns 1 or -1 be considered compliant? |
| 19:09 | <ljharb> | we definitely should, and we’ve talked about that in plenary multiple times - generally speaking everyone seemed positive on it, but nobody was confident about having the expertise required to do so correctly |
| 19:13 | <bakkot> | I frankly don't think it's worth spending time on |
| 19:13 | <bakkot> | it's not like we offer a certification |
| 19:21 | <shu> | oh man what a great idea |
| 19:21 | <shu> | i want one of those holographic gold stickers |
| 19:22 | <Chris de Almeida> |
|
| 19:27 | <Michael Ficarra> | apparently there was real web compat issues in the past when Chrome made significant compromises to their trig functions in the name of speed |
| 19:27 | <Michael Ficarra> | so there's probably something that should be said about accuracy |
| 19:29 | <ljharb> | i agree (and remember those compat issues viscerally) |
| 19:29 | <Michael Ficarra> | @ljharb you got any links to issues? |
| 19:29 | <Michael Ficarra> | we should collect them in an ecma262 issue |
| 19:30 | <ljharb> | https://github.com/compat-table/compat-table/issues/392#issuecomment-70381406 i think? |
| 19:30 | <ljharb> | https://github.com/es-shims/es6-shim/commit/90c803f68390dd13fd5297b1e2d54d44f8dac94b is where i patched it in es6-shim |
| 19:37 | <Michael Ficarra> | started an issue: https://github.com/tc39/ecma262/issues/3347 |
| 23:00 | <littledan> | apparently there was real web compat issues in the past when Chrome made significant compromises to their trig functions in the name of speed |
| 23:06 | <Michael Ficarra> | littledan: what we'd be going for is guidance for how to build a web-compatible JavaScript engine. I think we can list certain constraints on many of the trigonometric functions such as symmetry, monotonicity, and bounds. We would only describe constraints that hold across engines today and that a reasonable person may expect to hold. |