Hello, Andreas,

things are getting weared ^2

Am Sonntag, 22. November 2009 20:00:08 schrieb [email protected]:
> > 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

_______________________________________________
PyCUDA mailing list
[email protected]
http://tiker.net/mailman/listinfo/pycuda_tiker.net

Reply via email to