Hi,
>> % locate python | grep '\/python$\|\/python...$' | grep bin | xargs -I >> % echo % -c "\"import numpy; print(numpy.__version__)\"" > > > I am not sure what these two commands were supposed to return; I assume a > list of numpy versions. Something in the syntax goes wrong there. I tried a > number of different variations of brackets and quotes, but nothing > conclusive came out. Sorry, I keep forgetting you use the C shell rather than bash. The syntax is annoyingly different between the two. Instead try: $ locate python | grep '\/python$\|\/python...$' | grep bin | xargs -I % echo % -c '"import numpy ; print ( numpy.__version__ )"' That should work better. I'm just glad you didn't decide to use the Korn shell! > Anyways. > Importing numpy and scipy into the python version (/usr/local/bin/python) is > indeed a problem. Here is certainly the reason why relax does not find > numpy. See below the ImportErrors. > > (If I use my standard python, I have numpy... > > [gre:~] paul% which python > python: aliased to > /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/python > [gre:~] paul% python > > Python 2.7.5 (default, Jun 27 2013, 19:56:45) > [GCC 4.2.1 Compatible Apple LLVM 4.2 (clang-425.0.28)] on darwin > Type "help", "copyright", "credits" or "license" for more information. This date is recent, but it cannot be the new official version you installed in the last day. That one should have a date just before the 15th of May, when it was released. Is this one self compiled? If so, we might be able to set up that one to work with relax, if all else fails. > [gre:~] paul% /usr/local/bin/python > > Python 2.7.5 (v2.7.5:ab05e7dd2788, May 13 2013, 13:18:45) Better :) >>>> import numpy;print(numpy.__version__) > > > Traceback (most recent call last): > > File "<stdin>", line 1, in <module> [snip] > ImportError: > dlopen(/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so, > 2): no suitable image found. Did find: > > > /Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/multiarray.so: > no matching architecture in universal wrapper This is quite a bizarre error. This is a clear architecture mismatch! I'm reinstalling as I go here, and on my system I've tried both: numpy-1.7.1-py2.7-python.org- macosx10.6.dmg (http://sourceforge.net/projects/numpy/files/NumPy/1.7.1/numpy-1.7.1-py2.7-python.org-macosx10.6.dmg/download) numpy-1.7.1-py2.7-python.org-macosx10.3.dmg (http://sourceforge.net/projects/numpy/files/NumPy/1.7.1/numpy-1.7.1-py2.7-python.org-macosx10.3.dmg/download) This is Mac OS X 10.6.8. It boots into 32-bit mode. But I have 64-bit Python running. Both test numpy versions import fine on my system. Maybe you need to try the other numpy version? And if that doesn't work, then it will have to be compiled to get the correct architecture! >>>> import wx; print(wx.__version__) > > > 2.9.4.0 This looks good! wxPython is the most difficult part to set up, normally. > Now I could either use a different version of python for relax (I guess you > would not recommend), or place numpy into the right path. I should rather > try the latter. For this Python version, numpy is horribly broken. Try the other numpy DMG version and, if that fails, we compile http://sourceforge.net/projects/numpy/files/NumPy/1.7.1/numpy-1.7.1.tar.gz/download with: $ cd numpy-1.7.1.tar.gz $ /usr/local/bin/python setup.py install The same with scipy. >> Hopefully one of these will work. Oh, also make sue that the Python >> version printed out matches the DMG file you recently downloaded >> exactly, just in case /usr/local/bin/python is a symbolic link to a >> different Python version :S Maybe also type: >> >> % ls -alh /usr/local/bin/python >> >> and make sure that the date on that symlink is less than a day old, >> and that it points to >> /Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7. > > This seems to be ok: > > [gre026248:~] paul% ls -alh /usr/local/bin/python > lrwxr-xr-x 1 root wheel 68B 8 Aug 22:52 /usr/local/bin/python -> > ../../../Library/Frameworks/Python.framework/Versions/2.7/bin/python That date looks good. The date that Python gives also looks good. > However, the fact that the owner is root may be a problem. > Unfortunately, a chown does not solve the issue: No, that should be the case. Changing to a user is a security problem. It is world executable, so the owner being root is reasonable. > [gre:/Users/paul] root# chown paul /usr/local/bin/python > > [gre:/Users/paul] root# ls -alh /usr/local/bin/python > > lrwxr-xr-x 1 root wheel 68B 8 Aug 22:52 /usr/local/bin/python -> > ../../../Library/Frameworks/Python.framework/Versions/2.7/bin/python Hehe, your Mac stopped you from doing that :P > I still hesitate to compile numpy from source. > I might do so, though, especially if nothing else works. Like I said above, try the other numpy DMG file, and if not, compile. Numpy is straight forward. Scipy is more difficult and may require: $ PATH=/usr/local/bin/:$PATH C_INCLUDE_PATH=/sw/include/suitesparse/ ~/bin/python2.7 setup.py install You'll have to find where suitesparse is installed on your system and then point to the correct directory. Regards, Edward _______________________________________________ relax (http://www.nmr-relax.com) This is the relax-devel mailing list [email protected] To unsubscribe from this list, get a password reminder, or change your subscription options, visit the list information page at https://mail.gna.org/listinfo/relax-devel
