Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collection of helper constants and functions for testing RABs #4030

Merged
merged 11 commits into from
Apr 30, 2024

Conversation

ioannad
Copy link
Contributor

@ioannad ioannad commented Mar 26, 2024

These are the parts of the code in resizable array buffer staging tests that are heavily repeated. In order to somewhat compact the migration of RAB staging tests (see PR #3888).

@ioannad ioannad requested a review from a team as a code owner March 26, 2024 18:30
harness/resizableArrayBufferUtils.js Outdated Show resolved Hide resolved
harness/resizableArrayBufferUtils.js Outdated Show resolved Hide resolved
harness/resizableArrayBufferUtils.js Outdated Show resolved Hide resolved
resized = true;
}
}
assert.compareArray(values.flat(), expected.flat());
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what about envs that don't support .flat?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I addressed all the comments except this, as I am not sure what's the best way to proceed. One idea would be to define a new comparison function that doesn't need to use .flat here. Do you think there is a simpler way to take care of this?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i guess that makes me wonder why they need to be flattened at all. what's the diff if you just compare them directly?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

compareArray doesn't do deep comparison, it does SameValue elementwise

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahhh gotcha. so what we need here is zip(values, expected).forEach((v, e) => assert.compareArray(v, e)) or something :-/

probably best to do just a normal for loop then, here?

harness/resizableArrayBufferUtils.js Outdated Show resolved Hide resolved
harness/resizableArrayBufferUtils.js Outdated Show resolved Hide resolved
harness/resizableArrayBufferUtils.js Outdated Show resolved Hide resolved
harness/resizableArrayBufferUtils.js Outdated Show resolved Hide resolved
let resized = false;
var arrayValues = false;

for (const value of ta) {
Copy link
Contributor Author

@ioannad ioannad Apr 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ljharb I switched this back to a for..of loop because some of the tas are actually iterators. IIUC for..of was made exactly for this sort of usage, where it could be an array or an iterator being looped over. WDYT?

@ioannad
Copy link
Contributor Author

ioannad commented Apr 18, 2024

@ptomato @ljharb I think this is now ready for another round of reviews. I think everything is addressed except the name of the argument ta to TestIterationAndResize. Indeed "test array" seems to be the intended meaning as you said Philip, but it could also be a leftover from initial tests where the typed array - named also ta in the test files - was used instead of the derived arrays and iterators that are used there now.

Copy link
Contributor

@ptomato ptomato left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is ready to move ahead.

The comment about for-of gave me a different idea to solve the ta naming; how about calling it iterable?

@ioannad
Copy link
Contributor Author

ioannad commented Apr 30, 2024

@ljharb just a friendly ping since my previous comment is now marked outdated:

WDYT about leaving the for-of loop in TestIterationAndResize? If you are ok with keeping the for-of loop after all, then I think all the other review comments have been addressed and this is ready to get merged.

ioannad and others added 11 commits April 30, 2024 09:26
…ray buffers.

These are the parts of the code in RAB staging tests that are heavily repeated.
In order to somewhat compact the migration of RAB staging tests (see PR tc39#3888).
…and adjusted central assertion.

- After some errors from `TestIterationAndResize` when trying to fix the comparison between `values` and
  `expected` without using .flat(), reverted this particular usage of for-of so that it easily works with
  iterators.
- Also adjusted the central assertion to work for both cases of whether `values` is an array of number arrays
  or not.
@ljharb
Copy link
Member

ljharb commented Apr 30, 2024

I certainly won't block on it, it's just nice if tests don't rely on syntax that isn't necessary to run the test :-)

@ptomato
Copy link
Contributor

ptomato commented Apr 30, 2024

OK, let's move forward with this. If there's an opportunity to get rid of the for-of by not using iterables elsewhere, I'd be happy to merge it in the future, but the RAB tests have been waiting for long enough 😄

@ptomato ptomato merged commit c95cc68 into tc39:main Apr 30, 2024
8 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants