Bug in `extraction.py`
Closed this issue · 6 comments
When I use wllvm==1.0.16 and Python 3 and I use the extract-bc tool I get
Traceback (most recent call last):
File "/home/dan/dev/whole-program-llvm/venv/bin/extract-bc", line 7, in <module>
from wllvm.extractor import main
File "/home/dan/dev/whole-program-llvm/venv/lib/python3.5/site-packages/wllvm/extractor.py", line 27, in <module>
from .extraction import extraction
File "/home/dan/dev/whole-program-llvm/venv/lib/python3.5/site-packages/wllvm/extraction.py", line 90
print c
If I look at the current sources for this repo I can see the old style Python 2 print statement there. This leads me to ask the following.
-
Why didn't TravisCI catch this? It looks like you're testing Python 3 and using
extract-bcin your tests but the tests passed. -
This bug isn't in https://github.com/travitch/whole-program-llvm despite that being at version
1.0.16. Is it intentional to be out of sync?
Could the bug be fixed and a new version be pushed out?
It can certainly be fixed. As I said previously I push the pip from from SRI's fork,
which is also where I do all my development (most recently fighting with pylint,, until
we both got too tired to disagree.) I'll fix it in a minute. Not sure about the travis thing.
@ianamason I just took a look at your .travis.yml. My suspicion is the build is not using the version of python it is supposed to be. IIRC TravisCI sticks it's python install in /opt/ somewhere. So if you install Ubuntu's pip it's going to use the system python rather than the python that TravisCI has been set up to use.
Wanna fix it? I had an ugly session with travis and another project a few days ago
because sudo's python and the user's python were different.
@ianamason Yeah if you look at https://docs.travis-ci.com/user/languages/python/ you'll see that TravisCI sets up a Python virtualenv and the docs say not to use the system pip.
I'll have a quick go at fixing it now.
Thanks I got a deliverable due today, and thanksgiving tomorrow.