2024-04-01 [10:49:47.0262] dpu: I think I'd suggest for a newbie to use a different resource than ECMA-262 to learn to write correct code! there are lots of resources out there that are written with newbie-level and intermediate-level JS programmers in mind, such as MDN (here's their page on the Map constructor: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map/Map) [10:55:06.0980] dpu: that said, it can be a really interesting exercise to go through the spec and find exactly where/why something is happening. in the case of that specific question, you would need to look at the ECMAScript grammar, because that code_of_Map2.png is not a syntactically valid program. in that context, the `{` token means the parser has to parse an [ObjectLiteral](https://tc39.es/ecma262/#prod-ObjectLiteral), and the following `'` token is not valid in any of the branches for ObjectLiteral. [10:56:44.0833] on the other hand, if the program is syntactically valid but you have questions about the behaviour of the Map constructor, then you would need to consult the algorithm steps that define its behaviour: https://tc39.es/ecma262/#sec-map-iterable [10:57:07.0898] you can probably find more resources for beginners in #tc39-beginners:matrix.org [11:05:43.0949] Thank you so much for the detailed answer, ptomato. The keyword 'ObjextLiteral' and 'Map ( [ iterable ] )' had make me clear. Have a good day :) [11:06:43.0266] glad to help! [12:21:45.0540] https://github.com/tc39/test262/issues/3953 seems like it continues to confuse contributors. any objections to just commenting out the ChakraCore CI job? [12:24:44.0609] FWIW I'm skeptical that we get much value from any of those CI jobs running on individual engines, except for ESMeta; contributors tend to interpret them as "does XYZ engine pass all the tests in this PR" rather than what they actually signify, "does XYZ engine execute these tests without crashing" (or, increasingly, "is XYZ engine able to be installed using ESVU" 😛) [12:25:51.0609] besides, both questions seem to be covered sufficiently by test262.fyi [12:35:23.0035] ☝️ https://github.com/tc39/test262/pull/4040 2024-04-03 [11:34:18.0110] next maintainers meeting is next week, during the plenary. should we postpone it again, or just skip this one? [13:17:11.0792] We always skip meetings during plenary week 2024-04-05 [12:51:58.0216] I forgot to put on the agenda last time that we should discuss what to cover in the plenary update [12:52:04.0535] how's this for bullet points? [12:52:48.0219] - Since January, a certain amount of Igalia's test262 development has been subsidized by [Sovereign Tech Fund](https://www.sovereigntechfund.de/) - You may have noticed that many more tests landed in Q1 2024 than in Q4 2023 - Worked with proposal authors to review tests and ensure coverage for **RegExp modifiers** and **Set methods** Wrote tests for a [needs-consensus PR](https://github.com/tc39/ecma262/pull/2600) that had long been blocked on test coverage - We'd like to encourage proposals to help write testing plans. Providing good documentation for this is high on our list. Let us know what you think about this! [12:52:56.0236] * - Since January, a certain amount of Igalia's test262 development has been subsidized by [Sovereign Tech Fund](https://www.sovereigntechfund.de/) - You may have noticed that many more tests landed in Q1 2024 than in Q4 2023 - Worked with proposal authors to review tests and ensure coverage for **RegExp modifiers** and **Set methods** - Wrote tests for a [needs-consensus PR](https://github.com/tc39/ecma262/pull/2600) that had long been blocked on test coverage - We'd like to encourage proposals to help write testing plans. Providing good documentation for this is high on our list. Let us know what you think about this! [12:53:19.0462] (yes, as far as I can tell, the embargo on announcing the subsidy is finally lifted) [12:55:02.0596] awesome [13:07:04.0301] my friends [13:07:14.0779] how's the resizable buffer review going [13:29:11.0483] you may have seen https://github.com/tc39/test262/pull/4030 ? [13:29:45.0426] and https://github.com/tc39/test262/pull/3888#issuecomment-2025620598 [13:30:54.0257] ioanna is leading the effort to get it into reviewable chunks [13:30:54.0688] i did, yes [16:11:04.0434] hey folks -- who will be handing the 262 report at plenary and how much time do you need? [16:14:03.0125] I guess by default it's me unless any of the rest of y'all feel like delivering it! FWIW I'll just be showing and reading out the above bullet points [16:14:33.0866] so, max 10 minutes if there's any discussion? [16:16:11.0406] SGTM 2024-04-06 [06:22:29.0530] > <@shuyuguo:matrix.org> how's the resizable buffer review going Sorry for the delay Shu, I have [one more review comment](https://github.com/tc39/test262/pull/4030/files#r1554585677) to address, on which I'm a bit stuck and then I'll go ahead and split your PR by method [as I mentioned last week](https://github.com/tc39/test262/pull/3888#issuecomment-2025620598). 2024-04-07 [16:20:30.0670] thank you for the update 2024-04-11 [15:02:45.0173] a quick bug fix if anyone's around: https://github.com/tc39/test262/pull/4053 2024-04-24 [14:31:06.0293] 👋 [14:32:01.0542] So I’ve been working on the decorator tests, and I’m having a bit of difficulty understanding best practices for the `desc` property [14:33:55.0810] Specifically, my two main issues are 1. Narrowing down which parts of the spec to include. A single test often involves a number of operations or different parts of the operations, and like, it seems odd to try to cut out each piece [14:35:12.0496] 2. It also feels difficult to maintain or future proof? The decorators spec refactors a decent chunk of class definition/init code for instance, and it would be really difficult to keep the descs up to date with changes as they happen in the spec [14:35:32.0477] There were a number of large refactors while I was working on it [14:35:52.0998] So it seems like drift could become a real problem? [14:36:21.0752] I get why it makes sense to quote the lines that matter, especially for big blocks [14:37:02.0072] But also just wondering if, like, it makes more sense to include a high level description and a reference to the section(s) being tested? [15:32:03.0260] pzuraq: you mean the `info` property, where people usually put direct quotes from the spec? lately, we haven't been placing too much importance on it, for exactly the reasons you mentioned 2024-04-25 [18:10:38.0439] Ok cool, good to know 2024-04-30 [12:31:59.0103] Hi :) I'm interested in getting started on upstreaming some of our tests (specifically these: https://searchfox.org/mozilla-central/source/js/src/tests/non262, that already run under the same test harness as other test262 tests...) Are there any guidelines on using the `implementation-contributed` directory? Are there any expectations around rewriting the tests to be runnable in other harnesses, or can I move them over as is? [12:44:28.0140] I'm not sure about `implementation-contributed`. I have some questions about it myself, that I was hoping to get clarified at tomorrow's maintainer meeting 😄 [12:45:58.0188] if these 'non262' tests already run under the test262 harness and are not particularly spidermonkey-specific, maybe you'd like to add them to the main test corpus anyway? [12:48:47.0447] We have an import process that modifies the test262 tests to run under our own harness. The `non262` tests also happen to run under this Mozilla harness. Submitting them to the main test corpus would be a huge amount of work, I think. [12:49:05.0407] Would it make sense for me to drop into the meeting tomorrow to learn more about `implementation-contributed`? [12:54:13.0723] dminor: that would be awesome to bring in those tests! I'm very happy that you're thinking about this. [12:54:31.0037] you're welcome to if you'd like! if it'd be a time sink for you, I can also try to figure it out and get back to you [12:55:47.0929] Sure, I'll drop by, it would be good to get some context on how test262 is maintained. Thanks! [12:59:47.0711] dminor: what happened to what used to be called the jit tests? are those now non262? [13:04:11.0556] The jit tests are still around, we'd plan to keep those separate for now, since they're much more implementation focused. [13:04:56.0884] The `non262` tests are more general, but don't necessarily line up with test262 expectations of testing a single part of the specification at a time. [13:05:20.0800] Or at least that's how I understand what test262 is doing. [14:40:03.0664] fwiw i think implementation-contributed is basically an unmaintained dump, and the new place is the staging directory [14:40:24.0723] even better ofc is if you can PR them with all the right boilerplate directly into the right places, but staging is so you can defer that work [15:00:44.0773] I think the idea of staging is no longer that you are implicitly saying you will eventually do that other work, but the maintainers can clarify better than me. [15:14:52.0486] it's like "there's more value in getting everyone to run something without boilerplate today, than to not have anything until we've written the boilerplate". i don't think there's an implicit promise in commiting the staging, the promise is explicit in requiring the boilerplate and organization for Stage 4 [15:16:10.0373] (i'm assuming that stage 4 is a goal we all share. non-champion implementers who shipped a proposal should care about the spec reflecting reality asap) [15:20:24.0649] oh, agree [15:20:31.0331] i meant like, defer that work to test262 maintainers [15:26:18.0141] ah [15:51:38.0466] Hmm, so it sounds like we'd prefer `implementation-contributed` to go away or at least not grow larger. I'm not sure to what extent our `non262` tests are suitable for staging, the other option we've discussed is merging them into the jit tests. [15:52:01.0766] That might be a short term solution for cleaning up our testing situation, and longer term, we can start going through tests to review what would be suitable for test262. [16:10:31.0516] I can go into more detail tomorrow, but I'm actually interested in refurbishing `implementation-contributed` and automatically syncing tests from implementations there in a way that other implementations can run them directly