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

pypy3 support tracking issue #147

Closed
2 tasks
nmigen-issue-migration opened this issue Jul 10, 2019 · 11 comments
Closed
2 tasks

pypy3 support tracking issue #147

nmigen-issue-migration opened this issue Jul 10, 2019 · 11 comments
Milestone

Comments

@nmigen-issue-migration
Copy link

Issue by programmerjake
Wednesday Jul 10, 2019 at 09:43 GMT
Originally opened as m-labs/nmigen#145


See m-labs/nmigen#141 (comment) for motivation

Todo list (edit as needed to keep up to date):

  • fix failing tests
  • enable requiring pypy3 to pass in .travis.yml
@nmigen-issue-migration
Copy link
Author

Comment by programmerjake
Thursday Jul 11, 2019 at 04:14 GMT


I ran all the unittests on pypy3 locally, none of them failed. This makes me think the issue is caching, interference between pypy3 and cpython, or the fact that I'm using pypy3.6-v7.1.0 instead of v7.1.1.

@nmigen-issue-migration
Copy link
Author

Comment by programmerjake
Thursday Jul 11, 2019 at 04:23 GMT


pypy3.6-v7.1.1 works as well

@nmigen-issue-migration
Copy link
Author

Comment by programmerjake
Thursday Jul 11, 2019 at 06:13 GMT


I got it to fail locally by running in a pypy3 virtualenv, maybe symbiyosys's scripts don't work with a virtualenv

@nmigen-issue-migration
Copy link
Author

Comment by programmerjake
Thursday Jul 11, 2019 at 06:26 GMT


travis-ci passed when not using a virtualenv: https://travis-ci.com/programmerjake/nmigen/builds/118721712

@nmigen-issue-migration
Copy link
Author

Comment by programmerjake
Thursday Jul 11, 2019 at 07:40 GMT


turns out travis-ci passing was a false positive, it didn't actually use pypy3

@nmigen-issue-migration
Copy link
Author

Comment by programmerjake
Thursday Jul 11, 2019 at 07:58 GMT


I think the reason the unittests pass locally is because I've been running them by calling pypy3 explicitly, so SymbiYosys still uses cpython, since python3 has not been symlinked to pypy3.

To fix this bug, I think we'll probably have to add a workaround to SymbiYosys. Even once pypy fixes the issue, not everyone will have the fixed version of pypy or want to build their own.

@nmigen-issue-migration
Copy link
Author

Comment by whitequark
Thursday Jul 11, 2019 at 09:38 GMT


Sure. Feel free to add a workaround and cc me on the PR.

@nmigen-issue-migration
Copy link
Author

Comment by programmerjake
Monday Jul 22, 2019 at 21:13 GMT


pypy commited fix for internal error: https://bitbucket.org/pypy/pypy/commits/487165124904
didn't test yet

@nmigen-issue-migration
Copy link
Author

Comment by whitequark
Tuesday Sep 10, 2019 at 04:42 GMT


@programmerjake Ping--could you revisit this please?

@nmigen-issue-migration
Copy link
Author

Comment by programmerjake
Wednesday Sep 11, 2019 at 00:07 GMT


last I had checked, it appeared as though symbiyosys would need extensive changes to work around that pypy bug since the bug appears to affect all built-in nonblocking read operations. either symbiyosys would need to be changed to use blocking reads (maybe via multithreading) or there would need to be a way to bypass pypy's broken read operation -- both of which sounds quite invasive.

I could be wrong, however.

I think the best way to proceed may be to just disable symbiyosys tests when the buggy versions of pypy are detected.

@nmigen-issue-migration
Copy link
Author

Comment by whitequark
Wednesday Sep 11, 2019 at 09:30 GMT


I think the best way to proceed may be to just disable symbiyosys tests when the buggy versions of pypy are detected.

Sounds fine to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants