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

Create eyeball-im-util with FilteredVectorSubscriber API #19

Merged
merged 4 commits into from
May 31, 2023
Merged

Conversation

jplatte
Copy link
Owner

@jplatte jplatte commented May 30, 2023

No description provided.

It's not intuitive, but the stream output is correct.
It may be changed later.
@jplatte jplatte requested a review from Hywan May 30, 2023 12:27
Copy link
Collaborator

@bnjbvr bnjbvr left a comment

Choose a reason for hiding this comment

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

Looks interesting! I've found a few places where there could be invalid subtracts (unless I'm missing something), can you add tests for those please?

Also, I think there might be a way to make all this code more robust, by testing invariants. Say something like fn assert_invariants, that would be either debug only (or guarded behind a compile-time cargo feature, enabled in tests only), that would check the following at the end of each handle_ function call:

  • indices in filtered_indices are unique (don't appear twice or more)
  • indices in filtered_indices refer to values that are in the original array, and those values pass the filter check

What do you think? This might mean storing more of the original array too, but at least for testing purposes, something akin to that would be useful and increase the confidence in this new code IMO.

eyeball-im-util/src/vector.rs Show resolved Hide resolved
eyeball-im-util/src/vector.rs Show resolved Hide resolved
eyeball-im-util/src/vector.rs Show resolved Hide resolved
eyeball-im-util/src/vector.rs Show resolved Hide resolved
@jplatte
Copy link
Owner Author

jplatte commented May 30, 2023

I think testing invariants would be nice, but I don't think doing it as part of the regular non-cfg(test) is a good idea, since app debug builds by default also compile all dependencies in debug mode.

A good way to do invariant testing would be adding another test suite IMO (as unit tests that can access internal stat), using the proptest crate to ensure the internal state is kept consistent in ~all cases. There's also the option of trying Kani, but it's probably a bit harder to do and possibly an overkill.

I'd prefer not blocking this PR on extra testing though.. We don't intend to use it in places where it would be a huge issue for some bugs to be present, right? And if there are bugs, they'll likely be pretty obvious (i.e. lead to a panic).

Copy link
Collaborator

@Hywan Hywan left a comment

Choose a reason for hiding this comment

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

I probably like it too much, thank you!

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