Skip to content

examples/usercmodule: Add example of custom type. #10038

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

Closed
wants to merge 1 commit into from

Conversation

laurensvalk
Copy link
Contributor

@laurensvalk laurensvalk commented Nov 21, 2022

This shows how ports can add their own custom types (classes).

Since this is part of the unix coverage build, we can use it for future tests too. This could then support #9997.

EDIT: Relax constraint on timer test since that isn't really the point of this test. On the qemu port, sleep_ms(100) would sometimes take more than 105 ms.

This shows how ports can add their own custom types/classes.

It is part of the unix coverage build, so we can use it for tests too.

Signed-off-by: Laurens Valk <laurens@pybricks.com>
@dpgeorge
Copy link
Member

Thanks, this is a nice addition to have as an example of a C class.

Rebased and merged in a67989a, with a minor change to change uint32_t to mp_uint_t for the start_time member type.

@dpgeorge dpgeorge closed this Nov 23, 2022
@laurensvalk laurensvalk deleted the user-type-example branch November 23, 2022 08:38
@damz
Copy link
Contributor

damz commented Nov 23, 2022

This introduced random test failures in CI, like this one. Could we implement this in a way that is not timing-dependent?

@laurensvalk
Copy link
Contributor Author

This was already noted above, but apparently sleep_ms in the qemu tests can be off by even more than 10 ms. Is that a separate bug?

I’m happy to update this test to make sure the time isn’t too critical, though.

@damz
Copy link
Contributor

damz commented Nov 23, 2022

If I'm reading the result log properly, it failed here:

print(t.time() <= 1)

If I had to guess, it is because it blocked on the print() before that.

@dpgeorge
Copy link
Member

I was also wondering if that t.time() <= 1 would end up being a problem. Probably OK to just change that to t.time() <= 10.

Note that we do have quite a few tests (mostly uasyncio) that rely on timing, and they are quite robust now (after some effort, eg c012318).

@laurensvalk
Copy link
Contributor Author

Thanks Damien and Damien. Fix proposed in #10072.

tannewt pushed a commit to tannewt/circuitpython that referenced this pull request Feb 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests Relates to tests/ directory in source
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants