Skip to content

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

Closed
laurensvalk wants to merge 1 commit into
micropython:masterfrom
pybricks:user-type-example
Closed

laurensvalk wants to merge 1 commit into
micropython:masterfrom
pybricks:user-type-example

Conversation

@laurensvalk

@laurensvalk laurensvalk commented Nov 21, 2022 •

Copy link
Copy Markdown
Contributor

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 <[email protected]>
@dpgeorge

Copy link
Copy Markdown
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

damz commented Nov 23, 2022

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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

damz commented Nov 23, 2022

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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
Copy Markdown
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