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.

pypy3.6-v7.1.1 works as well

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

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

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

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.

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

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

@programmerjake Ping--could you revisit this please?

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.

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.