Hello, Andreas,
things are getting weared ^2
Am Sonntag, 22. November 2009 20:00:08 schrieb pycuda-request(a)tiker.net:
> standard on SuSE is
> /usr/lib64/python2.5/site-packages/
>
> but the egg-laying machine seems to put stuff to
> /usr/local/lib64/python2.5/site-packages
> instead
> (maybe I could have reconfigured this, anyway)
Weird. Curious about the reasoning behind this.
> However, gl_interop.py did not run until I did
> export PYTHONPATH=/usr/local/lib64/python2.5/site-packages/
> (was PYTHONPATH="" before)
>
> maybe this is since there is still the old python-opengl-2.0.1.09-224.1
> /usr/lib64/python2.5/site-packages/OpenGL/GL/ARB/
> ...with-no-vertex-buffer-in-there in the way which is caught before.
>
> But to figure it out I'm definitely lacking sufficient python experience.
There is an easy trick to find out what file path actually gets imported:
>>> import pytools
>>> pytools.__file__
'/home/andreas/research/software/pytools/pytools/__init__.py'
tried it on two different consoles - one with empty $PYTHONPATH and one set as
above.
=== case 1 ==============================================
:~> echo $PYTHONPATH
:~> python
Python 2.5.2 (r252:60911, Jun 7 2008, 00:38:48)
[GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]] on linux2
Type "help", "copyright", "credits" or "license"
for more information.
>> import pytools
>> pytools.__file__
'/usr/local/lib64/python2.5/site-packages/pytools-9-py2.5.egg/pytools/__init__.pyc'
>> <ctrl>D
:~/ cd test/cuda/pycuda/pycuda/examples
:~/test/cuda/pycuda/pycuda/examples> python gl_interop.py
Traceback (most recent call last):
File "gl_interop.py", line 8, in <module>
from OpenGL.GL.ARB.vertex_buffer_object import *
ImportError: No module named vertex_buffer_object
=== case 2 ==============================================
:~/test/cuda/pycuda/pycuda> echo $PYTHONPATH
/usr/local/lib64/python2.5/site-packages/
:~/test/cuda/pycuda/pycuda> python
Python 2.5.2 (r252:60911, Jun 7 2008, 00:38:48)
[GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]] on linux2
Type "help", "copyright", "credits" or "license"
for more information.
>> import pytools
>> pytools.__file__
'/usr/local/lib64/python2.5/site-packages/pytools-9-py2.5.egg/pytools/__init__.pyc'
>> <ctrl>D
...
runnign gl_interop.py works...
=================================================
so, although the $PYTHONPATH environment variable solved my python-opengl
problem, there seems to be another place where the path info is kept / set.
Either in some global way? but then gl_interop.py should run in case 1, too
And I would consider it as bad implementation, having side effects of
environment variables between different consoles.
Think python itself ist quite mature, isn't it?
maybe >>> import pytools already changes the path.
Isn't there any python builtin way to show the module search path?
and how are all the SuSE-configured modules in
/usr/lib64/python2.5/site-packages/
found?
but something seems already screwed on my python:
looking for an answer for above question pops up an empty tk window and throws
an error ($PYTHONPATH=/usr/local/lib64/python2.5/site-packages/)
===== case 2 ======================
help> modules environment
Here is a list of matching modules. Enter any module name to get more help.
No handlers could be found for logger "OpenGL.Tk"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.5/site.py", line 346, in __call__
return pydoc.help(*args, **kwds)
File "/usr/lib64/python2.5/pydoc.py", line 1644, in __call__
self.interact()
File "/usr/lib64/python2.5/pydoc.py", line 1662, in interact
self.help(request)
File "/usr/lib64/python2.5/pydoc.py", line 1680, in help
self.listmodules(split(request)[1])
File "/usr/lib64/python2.5/pydoc.py", line 1785, in listmodules
apropos(key)
File "/usr/lib64/python2.5/pydoc.py", line 1883, in apropos
ModuleScanner().run(callback, key)
File "/usr/lib64/python2.5/pydoc.py", line 1848, in run
for importer, modname, ispkg in pkgutil.walk_packages():
File "/usr/lib64/python2.5/pkgutil.py", line 125, in walk_packages
for item in walk_packages(path, name+'.', onerror):
File "/usr/lib64/python2.5/pkgutil.py", line 110, in walk_packages
__import__(name)
File "/usr/local/lib64/python2.5/site-packages/OpenGL/Tk/__init__.py", line
114, in <module>
_default_root.tk.call('package', 'require', 'Togl')
_tkinter.TclError: can't find package Togl
>>
======= case 1 ====================
help> modules environment
Here is a list of matching modules. Enter any module name to get more help.
Speicherzugriffsfehler
:~/test/cuda/pycuda/pycuda/examples> echo $PYTHONPATH
:~/test/cuda/pycuda/pycuda/examples>
=======case 3=====================
help> module environment
no Python documentation found for 'module environment'
.....
:~/test/cuda/pycuda/pycuda/examples> echo $PYTHONPATH
/usr/lib64/python2.5/site-packages/,/usr/local/lib64/python2.5/site-packages/
==============================================
Obviously, only by manually restoring the supposed correct (depends?) search
sequence (core system first) in $PYTHONPATH restores a working python help
system.
So something's going on below the hood.
Would blame one of the packages I've installed in the course of testing
pycuda.
looking for potential suspects:
:~> ls -1 /usr/local/lib64/python2.5/site-packages/
easy-install.pth
matplotlib
matplotlib-0.99.1.1-py2.5.egg-info
mpl_toolkits
OpenGL
pycuda
pycuda-0.93.1rc2-py2.5.egg-info
pylab.py
pylab.pyc
PyOpenGL-3.0.1b1-py2.5.egg-info
pytools-9-py2.5.egg
setuptools-0.6c9-py2.5.egg
setuptools.pth
wx-2.8-gtk2-unicode
wxaddons
wxaddons-2.8.8.1-py2.5.egg-info
wx.pth
wxPython_common-2.8.8.1-py2.5.egg-info
wxversion.py
wxversion.pyc
===================================================
without real knowledge, I would start to blame the OpenGL and wx-stuff first.
Hope I have no crucial app on my box that relys on python.
hang on .... qgis ... loading python .... looks ok. :-)
So keep playing until I screw my daily work...
yours
Wolfgang