2023-07-03 [08:08:13.0568] Ms2ger: if you merged anba's PR with automerge, it did something weird, so maybe we shouldn't use that [08:33:33.0633] ljharb: huh, interesting. First time that happened to me with automerge 2023-07-05 [14:10:29.0085] is there a column limit for the test262 tests? 2023-07-06 [09:39:20.0517] not afaik [09:39:28.0237] btw, since next week is plenary, i'm deleting our maintainers call from the calendar 2023-07-08 [04:53:23.0541] just to check, would a (big) PR updating old tests to use `assert.sameValue`/etc (instead of checking themself and throwing their own test262error) be welcome? [04:55:11.0321] * just to check, would a (big) PR updating many old tests to use `assert.sameValue`/etc (instead of checking themself and throwing their own test262error) be welcome? [07:41:30.0844] seems like an improvement, assuming semantics are the same [09:50:57.0873] yeah making sure, opened draft pr whilst checking results 2023-07-11 [04:26:10.0921] I gave an off-the-cuff update from test262 in the meeting this morning. hope that was OK - I believe the last meeting was skipped so I assumed no one else prepared one [04:26:38.0614] it was definitely OK from my POV 2023-07-13 [04:04:54.0957] I added a few items to the next meeting's agenda; in particular, our hosts at this TC39 plenary, a research group at University of Bergen, are interested in having students collaborate with us to write some test262 tests. I imagine we would welcome the help, if there were suitable projects for the students [04:06:02.0773] the other discussion item is that the cleanupSome proposal may be withdrawn in a future plenary, and it's one of the few stage 2 proposals that has already-merged tests, so it has some implications for us [04:38:08.0489] Though I'd contributed to test262 in the past, I found it very difficult to get started on the tests for `using` as I found the documentation was somewhat lacking in terms of how to set up the environment, and I had trouble running the tests on Windows and had to use WSL. [04:38:17.0712] Plus there is a lot of hunting around to figure out what files you need to add to `includes: []` for some assertions. The experience of working with test262 in an editor like VSCode wasn't great. [04:39:24.0628] do any of the other maintainers/contributors in this channel build/run the tests on Windows? [04:42:03.0814] The package.json uses syntax that isn't legal in either cmd.exe or Powershell (namely the use of `$()` to collect diffs. [04:42:14.0912] * The scripts in package.json use syntax that isn't legal in either cmd.exe or Powershell (namely the use of `$()` to collect diffs. [04:42:24.0334] * The scripts in package.json use syntax that isn't legal in either cmd.exe or Powershell (namely the use of `$()` to collect diffs). [04:42:24.0915] Do we have an issue about that? [04:43:53.0818] I also don't see a way to easily run lint locally [05:17:08.0577] i would have assumed windows users would prefer to run WSL, is it hard to set up? [05:19:05.0425] WSL was moderately annoying last time I used it [05:19:39.0286] but in any case, as an empirical question, very few windows developers use it as their primary development environment, in my experience [05:38:36.0310] > <@ljharb:matrix.org> i would have assumed windows users would prefer to run WSL, is it hard to set up? Yes and no. It's not hard to set up, but running `git` in WSL against a mounted windows disk is *very* slow. Running `git` in WSL against a path inside of the virtual disk for the WSL install is fast. The workaround is running `git.exe` from within WSL against any windows disk under `/mnt`. Worst case I would recommend adding a section to the README.md on using WSL, with a caution not to use an mounted Windows volume. I think it would be far easier to use platform-agnostic scripts in package.json for anything a developer might regularly use to write tests, especially since `esvu` and `test262-harness` both work in Windows, iirc. [05:38:59.0589] > <@ljharb:matrix.org> i would have assumed windows users would prefer to run WSL, is it hard to set up? * Yes and no. It's not hard to set up, but running `git` in WSL against a mounted windows volume is _very_ slow. Running `git` in WSL against a path inside of the virtual disk for the WSL install is fast. The workaround is running `git.exe` from within WSL against any windows disk under `/mnt`. Worst case I would recommend adding a section to the README.md on using WSL, with a caution not to use an mounted Windows volume. I think it would be far easier to use platform-agnostic scripts in package.json for anything a developer might regularly use to write tests, especially since `esvu` and `test262-harness` both work in Windows, iirc. [05:39:22.0303] * Yes and no. It's not hard to set up, but running `git` in WSL against a mounted windows volume is _very_ slow. Running `git` in WSL against a path inside of the virtual disk for the WSL install is fast. The workaround is running `git.exe` from within WSL against any windows volume under `/mnt`. Worst case I would recommend adding a section to the README.md on using WSL, with a caution not to use an mounted Windows volume. I think it would be far easier to use platform-agnostic scripts in package.json for anything a developer might regularly use to write tests, especially since `esvu` and `test262-harness` both work in Windows, iirc. [05:40:38.0540] I think that's a fair recommendation [05:41:30.0476] ... and somehow I just broke VS Code's remote filesystem support necessary for opening a remote connection in WSL, and may need to do a full reboot to work around the crash... :/ [06:15:51.0404] why use vscode when you can use vim from inside the WSL, and make the git checkout over there as well? [I actually do this] [06:16:32.0884] also you can use the host's vim inside WSL if you so prefer [06:16:38.0233] i recently switched to VSCode from 2 decades of emacs [06:16:48.0861] i realized i have been a FOOL for being in my emacs cave [06:16:52.0769] and VSCode is a good product actually [06:17:01.0734] well, it was emacs what did you expect /s [09:34:17.0881] rbuckton: I think one concrete step we can take already, is to open an issue for making the package.json scripts cross platform compatible 2023-07-24 [13:27:56.0358] https://github.com/tc39/test262/pull/3882 fixes some tests to use our convention for checking isConstructor [13:30:52.0467] also, i've got a DetachArrayBuffer AO implementation in es-abstract, which should work in lots of nodes and browsers, using structuredClone, or postMessage, or worker_threads.MessageChannel - but in test262 via test262-harness none of those seem to be available. is there something i need to do to provide those? (this might be due to me conditionally requiring `worker_threads` and the bundler not being able to statically determine that it needs to include it, but i'd still expect structuredClone to exist) 2023-07-25 [22:10:46.0894] alternatively, should any test that requires the host be able to detach array buffers have something like `includes: [detachArrayBuffer.js]`? [03:46:02.0941] You might have to ask Rick about the test262-harness env, but my understanding is that the environment is only required to provide the global names that are listed in INTERPRETING.md [03:47:16.0207] I think test262-harness loads the engines' JS shells, like d8 - I'm not sure those have structured clone available [07:31:42.0065] ok, given that, i need a way to filter out all tests that use detaching, i think 2023-07-26 [03:39:24.0945] fyi I have more updated forks of test262-harness/eshost/etc for test262.fyi so feel free to ping me for them [03:39:37.0711] * fyi I have more updated forks of test262-harness/eshost/etc for test262.fyi so feel free to ping me for them as I'm somewhat familiar 2023-07-28 [14:33:37.0182] FYI i have the resizable buffer PR up now: https://github.com/tc39/test262/pull/3888 [14:33:45.0634] would appreciate merge before next meeting for stage 4 [14:34:22.0068] i am not sure how reviewable it is though, +14,767 −4,317