chimera import from unmodified python 2.5
hello everyone,
first of all, i would like to say thank you for using vanilla python 2.5, i think this could be quite useful.
unfortunately, there is one problem that keeps me from using chimera from a session of my regular python 2.5 installation (on ubuntu 8.04). after setting paths properly, an attempt to import chimera (or the binary module _chimera) produces the following exception:
In [1]: import chimera --------------------------------------------------------------------------- <type 'exceptions.ImportError'> Traceback (most recent call last)
/home/andy/<ipython console> in <module>()
/home/andy/CHIMERA/share/chimera/__init__.py in <module>()
<type 'exceptions.ImportError'>: /opt/chimera/lib/libwrappy2.so: undefined symbol: PyUnicodeUCS2_AsUTF8String
In [2]: import _chimera --------------------------------------------------------------------------- <type 'exceptions.ImportError'> Traceback (most recent call last)
/home/andy/<ipython console> in <module>()
<type 'exceptions.ImportError'>: /opt/chimera/lib/libwrappy2.so: undefined symbol: PyUnicodeUCS2_AsUTF8String
it seems that the python 2.5 provided with chimera is compiled with different unicode settings than the one in ubuntu. the shared chimera objects are compiled against that version of python and therefore can't be used from my normal python. the only way i see around this at the moment is to recompile chimera, but i wanted to leave that as the very last option.
i would appreciate any suggestions, as a straightforward way to use chimera from my normal python would be really neat. i'll be glad to provide details if anyone is interested.
regards, ondrej marsalek
Yup, we compiled Python with the default options which uses UCS-2 instead of UCS-4. Since both Ubuntu and RedHat/Fedora use UCS-4, I'll change our Python to be the same. Tomorrow's daily build will use the UCS-4 API.
FYI, while chimera can work with a stock python, it is not completely compatible. We use a newer version of Tk than the stock python, so we had to modify the Tkinter module. We also made several other patches to the Python library, e.g., the help() function so it would work better with compiled modules. What this means is that if you are going to use the stock python with chimera, you have to have extra setup code to use the chimera GUI.
If you have Python code that you want to use with chimera, it's simplier to set the CHIMERAPATH environment to include the stock python's site-packages directory and your PYTHONPATH directories, or alter sys.path in your Python code. "chimera --nogui script.py" is a powerful way to run arbitrary Python code with the chimera modules.
And yes, please share how you are using chimera with the stock python. It should be as "simple" as (1) setting the CHIMERA environment variable, (2) adding CHIMERA/lib to LD_LIBRARY_PATH, (3) optionally setting up Tcl and Tk to be chimera's version, (4) adding CHIMERA/share to sys.path, (3) importing chimeraInit, and (5) calling chimeraInit.init with either nogui=True or eventloop=False.
Greg Couch UCSF Computer Graphics Lab
On Wed, 6 Aug 2008, Ondrej Marsalek wrote:
hello everyone,
first of all, i would like to say thank you for using vanilla python 2.5, i think this could be quite useful.
unfortunately, there is one problem that keeps me from using chimera from a session of my regular python 2.5 installation (on ubuntu 8.04). after setting paths properly, an attempt to import chimera (or the binary module _chimera) produces the following exception:
In [1]: import chimera
<type 'exceptions.ImportError'> Traceback (most recent call last)
/home/andy/<ipython console> in <module>()
/home/andy/CHIMERA/share/chimera/__init__.py in <module>()
<type 'exceptions.ImportError'>: /opt/chimera/lib/libwrappy2.so: undefined symbol: PyUnicodeUCS2_AsUTF8String
In [2]: import _chimera
<type 'exceptions.ImportError'> Traceback (most recent call last)
/home/andy/<ipython console> in <module>()
<type 'exceptions.ImportError'>: /opt/chimera/lib/libwrappy2.so: undefined symbol: PyUnicodeUCS2_AsUTF8String
it seems that the python 2.5 provided with chimera is compiled with different unicode settings than the one in ubuntu. the shared chimera objects are compiled against that version of python and therefore can't be used from my normal python. the only way i see around this at the moment is to recompile chimera, but i wanted to leave that as the very last option.
i would appreciate any suggestions, as a straightforward way to use chimera from my normal python would be really neat. i'll be glad to provide details if anyone is interested.
regards, ondrej marsalek _______________________________________________ Chimera-dev mailing list Chimera-dev@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-dev
On Wed, Aug 6, 2008 at 20:19, Greg Couch gregc@cgl.ucsf.edu wrote:
Yup, we compiled Python with the default options which uses UCS-2 instead of UCS-4. Since both Ubuntu and RedHat/Fedora use UCS-4, I'll change our Python to be the same. Tomorrow's daily build will use the UCS-4 API.
thanks, it works now. at least that part, anyway.
FYI, while chimera can work with a stock python, it is not completely compatible. We use a newer version of Tk than the stock python, so we had to modify the Tkinter module. We also made several other patches to the Python library, e.g., the help() function so it would work better with compiled modules. What this means is that if you are going to use the stock python with chimera, you have to have extra setup code to use the chimera GUI.
i was primarily interested in using a non-gui version. having also the ability to use the gui would be nice, but not important for me at the moment.
If you have Python code that you want to use with chimera, it's simplier to set the CHIMERAPATH environment to include the stock python's site-packages directory and your PYTHONPATH directories, or alter sys.path in your Python code. "chimera --nogui script.py" is a powerful way to run arbitrary Python code with the chimera modules.
i use the ipython shell for my normal python work and i found it complicated to get i to work in this way.
And yes, please share how you are using chimera with the stock python. It should be as "simple" as (1) setting the CHIMERA environment variable, (2) adding CHIMERA/lib to LD_LIBRARY_PATH, (3) optionally setting up Tcl and Tk to be chimera's version, (4) adding CHIMERA/share to sys.path, (3) importing chimeraInit, and (5) calling chimeraInit.init with either nogui=True or eventloop=False.
i have the following chimera.env file that i source in bash:
export CHIMERA=/opt/chimera export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CHIMERA/lib export PYTHONPATH=$PYTHONPATH:$CHIMERA/share:$CHIMERA/lib:$CHIMERA/lib/python2.5/site-packages
the nogui version works, but that is not exactly what i wanted, as that provides a midas prompt (if i understand it correctly). i would rather like to stay in my original python shell (ipython in this case). is there a way to do that?
the gui version fails, which is expected, as i did not take care of any tcl/tk changes. in case this is useful, the traceback is at the bottom. however, as i said, this is not my aim at the moment. i would be quite happy with getting my stock python into the same state as the built-in idle shell but without the gui. i hope it makes at least some sense.
regards, ondrej marsalek
In [2]: chimeraInit.init( [], eventloop=False ) Traceback (most recent call last): File "/usr/bin/ipython", line 27, in <module> IPython.Shell.start().mainloop() File "/var/lib/python-support/python2.5/IPython/Shell.py", line 77, in mainloop self.IP.mainloop(banner) File "/var/lib/python-support/python2.5/IPython/iplib.py", line 1537, in mainloop self.interact(banner) File "/var/lib/python-support/python2.5/IPython/iplib.py", line 1684, in interact more = self.push(line) File "/var/lib/python-support/python2.5/IPython/iplib.py", line 1986, in push more = self.runsource('\n'.join(self.buffer), self.filename) File "/var/lib/python-support/python2.5/IPython/iplib.py", line 1904, in runsource if self.runcode(code) == 0: File "/var/lib/python-support/python2.5/IPython/iplib.py", line 1941, in runcode exec code_obj in self.user_ns File "<ipython console>", line 1, in <module> File "CHIMERA/share/chimeraInit.py", line 338, in init tkgui.initializeGUI(exitonquit) File "CHIMERA/share/chimera/tkgui.py", line 2562, in initializeGUI File "CHIMERA/share/chimera/tkgui.py", line 2472, in createApp TclError: package "Tix" isn't loaded statically Error starting chimera: TclError: package "Tix" isn't loaded statically (see reply log for Python traceback info)
Eric Pettersen UCSF Computer Graphics Lab http://www.cgl.ucsf.edu
On Aug 9, 2008, at 1:51 PM, Ondrej Marsalek wrote:
And yes, please share how you are using chimera with the stock python. It should be as "simple" as (1) setting the CHIMERA environment variable, (2) adding CHIMERA/lib to LD_LIBRARY_PATH, (3) optionally setting up Tcl and Tk to be chimera's version, (4) adding CHIMERA/share to sys.path, (3) importing chimeraInit, and (5) calling chimeraInit.init with either nogui=True or eventloop=False.
i have the following chimera.env file that i source in bash:
export CHIMERA=/opt/chimera export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CHIMERA/lib export PYTHONPATH=$PYTHONPATH:$CHIMERA/share:$CHIMERA/lib:$CHIMERA/ lib/python2.5/site-packages
the nogui version works, but that is not exactly what i wanted, as that provides a midas prompt (if i understand it correctly). i would rather like to stay in my original python shell (ipython in this case). is there a way to do that?
Here's what works for me:
env CHIMERA=/usr/local/chimera.dev LD_LIBRARY_PATH=/usr/local/ chimera.dev/lib PYTHONPATH=/usr/local/chimera.dev/share:/usr/local/ chimera.dev/lib:/usr/local/chimera.dev/lib/python2.5/site-packages python2.5
You will have to adjust the above to your local installation, and may want to include the original values of LD_LIBRARY_PATH and PYTHONPATH if they are normally non-empty for you (i.e. in a similar fashion to your original export statements).
At the resulting python prompt:
from chimeraInit import init init([], nogui=True, script="py:/dev/null")
The "script=" keyword arg prevents Chimera from giving you it's own command prompt since you are tricking it into believing that you've provided a script to execute (/dev/null is always an empty file). Alternatively, you could have just typed "stop" at the prompt that Chimera gave you and gotten back to the python prompt.
--Eric
Stupid Mail.app signature-adding feature!
On Aug 13, 2008, at 2:17 PM, Eric Pettersen wrote:
Eric Pettersen UCSF Computer Graphics Lab http://www.cgl.ucsf.eduOn Aug 9, 2008, at 1:51 PM, Ondrej Marsalek wrote:
And yes, please share how you are using chimera with the stock python. It should be as "simple" as (1) setting the CHIMERA environment variable, (2) adding CHIMERA/lib to LD_LIBRARY_PATH, (3) optionally setting up Tcl and Tk to be chimera's version, (4) adding CHIMERA/share to sys.path, (3) importing chimeraInit, and (5) calling chimeraInit.init with either nogui=True or eventloop=False.
i have the following chimera.env file that i source in bash:
export CHIMERA=/opt/chimera export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$CHIMERA/lib export PYTHONPATH=$PYTHONPATH:$CHIMERA/share:$CHIMERA/lib:$CHIMERA/ lib/python2.5/site-packages
the nogui version works, but that is not exactly what i wanted, as that provides a midas prompt (if i understand it correctly). i would rather like to stay in my original python shell (ipython in this case). is there a way to do that?
Here's what works for me:
env CHIMERA=/usr/local/chimera.dev LD_LIBRARY_PATH=/usr/local/ chimera.dev/lib PYTHONPATH=/usr/local/chimera.dev/share:/usr/local/ chimera.dev/lib:/usr/local/chimera.dev/lib/python2.5/site-packages python2.5
You will have to adjust the above to your local installation, and may want to include the original values of LD_LIBRARY_PATH and PYTHONPATH if they are normally non-empty for you (i.e. in a similar fashion to your original export statements).
At the resulting python prompt:
from chimeraInit import init init([], nogui=True, script="py:/dev/null")
The "script=" keyword arg prevents Chimera from giving you it's own command prompt since you are tricking it into believing that you've provided a script to execute (/dev/null is always an empty file). Alternatively, you could have just typed "stop" at the prompt that Chimera gave you and gotten back to the python prompt.
--Eric
Chimera-dev mailing list Chimera-dev@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-dev
hello again,
On Wed, Aug 13, 2008 at 23:17, Eric Pettersen pett@cgl.ucsf.edu wrote:
Here's what works for me: env CHIMERA=/usr/local/chimera.dev LD_LIBRARY_PATH=/usr/local/chimera.dev/lib PYTHONPATH=/usr/local/chimera.dev/share:/usr/local/chimera.dev/lib:/usr/local/chimera.dev/lib/python2.5/site-packages python2.5 You will have to adjust the above to your local installation, and may want to include the original values of LD_LIBRARY_PATH and PYTHONPATH if they are normally non-empty for you (i.e. in a similar fashion to your original export statements). At the resulting python prompt: from chimeraInit import init init([], nogui=True, script="py:/dev/null") The "script=" keyword arg prevents Chimera from giving you it's own command prompt since you are tricking it into believing that you've provided a script to execute (/dev/null is always an empty file). Alternatively, you could have just typed "stop" at the prompt that Chimera gave you and gotten back to the python prompt.
thanks, that is what i wanted to achieve and it works on 32bit linux. on a 64bit system (amd64, that is), however, i end up with the traceback included below and without a working chimera. i think this is a bug. i don't know much in that specific area, but it seems that the dl module has been removed, see for example http://bugs.python.org/issue2470 is this really a bug or is there a problem with my setup? i run ubuntu 8.04 on both machines, python is version 2.5.2 on the 64bit one. i can provide more information if needed.
anyway, i have (at least in principle) a way to achieve the original goal and i believe the above mentioned problem will eventually get resolved.
thanks, ondrej marsalek
In [3]: init([], nogui=True, script="py:/dev/null") --------------------------------------------------------------------------- <type 'exceptions.ImportError'> Traceback (most recent call last)
/home/andy/<ipython console> in <module>()
/home/andy/CHIMERA/share/chimeraInit.py in init(argv, nogui, nomultisample, stereo, bgopacity, visual, screen, root, debug, geometry, title, eventloop, exitonquit, nostatus, preferencesFile, fullscreen, script, silent) 305 if sys.platform in ['linux2', 'irix646', 'irix6-n32']: 306 # make C++ shared libraries work when dlopen'd --> 307 import dl 308 sys.setdlopenflags(sys.getdlopenflags() | dl.RTLD_GLOBAL) 309
<type 'exceptions.ImportError'>: No module named dl
You should be able to copy chimera's dl module from CHIMERA/lib/python2.5/lib-dynload/dl.so to somewhere on your python path, or create a dummy dl module that has the value of RTLD_GLOBAL for your platform (should be the same on all Linux systems).
- Greg
On Fri, 15 Aug 2008, Ondrej Marsalek wrote:
hello again,
On Wed, Aug 13, 2008 at 23:17, Eric Pettersen pett@cgl.ucsf.edu wrote:
Here's what works for me: env CHIMERA=/usr/local/chimera.dev LD_LIBRARY_PATH=/usr/local/chimera.dev/lib PYTHONPATH=/usr/local/chimera.dev/share:/usr/local/chimera.dev/lib:/usr/local/chimera.dev/lib/python2.5/site-packages python2.5 You will have to adjust the above to your local installation, and may want to include the original values of LD_LIBRARY_PATH and PYTHONPATH if they are normally non-empty for you (i.e. in a similar fashion to your original export statements). At the resulting python prompt: from chimeraInit import init init([], nogui=True, script="py:/dev/null") The "script=" keyword arg prevents Chimera from giving you it's own command prompt since you are tricking it into believing that you've provided a script to execute (/dev/null is always an empty file). Alternatively, you could have just typed "stop" at the prompt that Chimera gave you and gotten back to the python prompt.
thanks, that is what i wanted to achieve and it works on 32bit linux. on a 64bit system (amd64, that is), however, i end up with the traceback included below and without a working chimera. i think this is a bug. i don't know much in that specific area, but it seems that the dl module has been removed, see for example http://bugs.python.org/issue2470 is this really a bug or is there a problem with my setup? i run ubuntu 8.04 on both machines, python is version 2.5.2 on the 64bit one. i can provide more information if needed.
anyway, i have (at least in principle) a way to achieve the original goal and i believe the above mentioned problem will eventually get resolved.
thanks, ondrej marsalek
In [3]: init([], nogui=True, script="py:/dev/null")
<type 'exceptions.ImportError'> Traceback (most recent call last)
/home/andy/<ipython console> in <module>()
/home/andy/CHIMERA/share/chimeraInit.py in init(argv, nogui, nomultisample, stereo, bgopacity, visual, screen, root, debug, geometry, title, eventloop, exitonquit, nostatus, preferencesFile, fullscreen, script, silent) 305 if sys.platform in ['linux2', 'irix646', 'irix6-n32']: 306 # make C++ shared libraries work when dlopen'd --> 307 import dl 308 sys.setdlopenflags(sys.getdlopenflags() | dl.RTLD_GLOBAL) 309
<type 'exceptions.ImportError'>: No module named dl _______________________________________________ Chimera-dev mailing list Chimera-dev@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-dev
participants (3)
-
Eric Pettersen -
Greg Couch -
Ondrej Marsalek