Hi all, We've put out a new version (1.2180) which we believe fixes the problems that some people were having on XP platforms. We're hoping that those of you that were having problems will try out the new version at your earliest convenience and let us know how it works. Thanks! Eric Pettersen UCSF Computer Graphics Lab pett@cgl.ucsf.edu http://www.cgl.ucsf.edu
Suppose I want to build a python module into chimera that requires the python headers, (e.g. numarray (I know numeric is there but just play along)). How would one go about doing this? I see you provide the python2.4 binary now, which helps for pure python extension. Thanks for that! - Charlie On 10/19/05, Eric Pettersen <pett@cgl.ucsf.edu> wrote:
Hi all, We've put out a new version (1.2180) which we believe fixes the problems that some people were having on XP platforms. We're hoping that those of you that were having problems will try out the new version at your earliest convenience and let us know how it works. Thanks!
Eric Pettersen
UCSF Computer Graphics Lab
pett@cgl.ucsf.edu
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
The normal way would be for you to download the whatever extension you wanted to try out and to install it using chimera's python -- CHIMERA/bin/python setup.py install. The tough part is to use the same compiler that we're using so that the runtime's are compatible (especially true on Windows, you need to use Visual Studio .NET 2003, not as true on UNIX platforms). The alternative is use a prebuilt binary. This works really well with Windows, but you need to install the Windows python so the extension will install properly and then copy the files to the appropriate place in the Chimera hierarchy -- CHIMERA/bin/Lib/site-packages/ on Windows, CHIMERA/lib/python2.4/site-packages on UNIX (and a similar place on Mac OS X). Does that answer your question? Greg On Fri, 21 Oct 2005, Charlie Moad wrote:
Date: Fri, 21 Oct 2005 10:34:21 -0500 From: Charlie Moad <cwmoad@gmail.com> To: Eric Pettersen <pett@cgl.ucsf.edu> Cc: Chimera <chimera-users@cgl.ucsf.edu> Subject: Re: [Chimera-users] new version available
Suppose I want to build a python module into chimera that requires the python headers, (e.g. numarray (I know numeric is there but just play along)). How would one go about doing this? I see you provide the python2.4 binary now, which helps for pure python extension. Thanks for that!
- Charlie
On 10/19/05, Eric Pettersen <pett@cgl.ucsf.edu> wrote:
Hi all, We've put out a new version (1.2180) which we believe fixes the problems that some people were having on XP platforms. We're hoping that those of you that were having problems will try out the new version at your earliest convenience and let us know how it works. Thanks!
Eric Pettersen
UCSF Computer Graphics Lab
pett@cgl.ucsf.edu
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
Hi, chimera development team, Thank you for the excellent work! Chimera is the best visusalization software for biomolecular system I ever used. I have a trivial question. I see that a python package is wrapped into chimera release. However, nowadays, usually python is a default on almost each linux distribution. Is there any way that I can let chimera use my won python which I built and optimized for my platform, instead of the wrapped python? Another question, according to your experience. Which graphics cards can afford good performance for chimera, in another word, best compatiable with chimera under linux platform? Our group always use graphics card from ATI, but AFAIK, ATI cards just suck. Thanks again! Mingfeng Yang Eric Pettersen wrote:
Hi all, �� �We've put out a new version (1.2180) which we believe fixes the problems that some people were having on XP platforms.� We're hoping that those of you that were having problems will try out the new version at your earliest convenience and let us know how it works.� Thanks!
� � � � � � � � � � � � Eric Pettersen
� � � � � � � � � � � � UCSF Computer Graphics Lab
� � � � � � � � � � � � pett@cgl.ucsf.edu <mailto:pett@cgl.ucsf.edu>
� � � � � � � � � � � � http://www.cgl.ucsf.edu
------------------------------------------------------------------------
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
Yes and no. All this pertains to linux for me, and using prebuilt binaries can lead to issues depending on how python was built. Without the headers of the libraries I can't build a binary package with chimera's python. Would it be possible to include the headers in your distribution? - Charlie On 10/21/05, Greg Couch <gregc@cgl.ucsf.edu> wrote:
The normal way would be for you to download the whatever extension you wanted to try out and to install it using chimera's python -- CHIMERA/bin/python setup.py install. The tough part is to use the same compiler that we're using so that the runtime's are compatible (especially true on Windows, you need to use Visual Studio .NET 2003, not as true on UNIX platforms).
The alternative is use a prebuilt binary. This works really well with Windows, but you need to install the Windows python so the extension will install properly and then copy the files to the appropriate place in the Chimera hierarchy -- CHIMERA/bin/Lib/site-packages/ on Windows, CHIMERA/lib/python2.4/site-packages on UNIX (and a similar place on Mac OS X).
Does that answer your question?
Greg
On Fri, 21 Oct 2005, Charlie Moad wrote:
Date: Fri, 21 Oct 2005 10:34:21 -0500 From: Charlie Moad <cwmoad@gmail.com> To: Eric Pettersen <pett@cgl.ucsf.edu> Cc: Chimera <chimera-users@cgl.ucsf.edu> Subject: Re: [Chimera-users] new version available
Suppose I want to build a python module into chimera that requires the python headers, (e.g. numarray (I know numeric is there but just play along)). How would one go about doing this? I see you provide the python2.4 binary now, which helps for pure python extension. Thanks for that!
- Charlie
On 10/19/05, Eric Pettersen <pett@cgl.ucsf.edu> wrote:
Hi all, We've put out a new version (1.2180) which we believe fixes the problems that some people were having on XP platforms. We're hoping that those of you that were having problems will try out the new version at your earliest convenience and let us know how it works. Thanks!
Eric Pettersen
UCSF Computer Graphics Lab
pett@cgl.ucsf.edu
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
Also, here is a case scenario. I can build matplotlib (matplotlib.sf.net) with the following command: CPPFLAGS="-I/usr/include/python2.4" /usr/local/chimera/bin/python2.4 setup.py install I have python2.4.2 installed, so I just use those headers. This works. Now when I try to use matplotlib I get an unresolved symbol, "PyUnicodeUCS4_AsUnicode" from one of its shared libraries. This symbol is located in libpython2.4.so, which is not in the chimera bundle. I can work around this by launching chimera with: LD_PRELOAD="/usr/lib/python2.4/config/libpython2.4.so" chimera This is obviously a temporary work-around. I would hope windows won't be this complicated. Any suggestions on how to better address an issue like this? Thanks, Charlie On 10/21/05, Greg Couch <gregc@cgl.ucsf.edu> wrote:
The normal way would be for you to download the whatever extension you wanted to try out and to install it using chimera's python -- CHIMERA/bin/python setup.py install. The tough part is to use the same compiler that we're using so that the runtime's are compatible (especially true on Windows, you need to use Visual Studio .NET 2003, not as true on UNIX platforms).
The alternative is use a prebuilt binary. This works really well with Windows, but you need to install the Windows python so the extension will install properly and then copy the files to the appropriate place in the Chimera hierarchy -- CHIMERA/bin/Lib/site-packages/ on Windows, CHIMERA/lib/python2.4/site-packages on UNIX (and a similar place on Mac OS X).
Does that answer your question?
Greg
On Fri, 21 Oct 2005, Charlie Moad wrote:
Date: Fri, 21 Oct 2005 10:34:21 -0500 From: Charlie Moad <cwmoad@gmail.com> To: Eric Pettersen <pett@cgl.ucsf.edu> Cc: Chimera <chimera-users@cgl.ucsf.edu> Subject: Re: [Chimera-users] new version available
Suppose I want to build a python module into chimera that requires the python headers, (e.g. numarray (I know numeric is there but just play along)). How would one go about doing this? I see you provide the python2.4 binary now, which helps for pure python extension. Thanks for that!
- Charlie
On 10/19/05, Eric Pettersen <pett@cgl.ucsf.edu> wrote:
Hi all, We've put out a new version (1.2180) which we believe fixes the problems that some people were having on XP platforms. We're hoping that those of you that were having problems will try out the new version at your earliest convenience and let us know how it works. Thanks!
Eric Pettersen
UCSF Computer Graphics Lab
pett@cgl.ucsf.edu
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
Hi Mingfeng, Years ago we encouraged people to use the system Python installed on their computer when running Chimera. Now we discourage that and include Python with every Chimera distribution. Chimera uses about 20 compiled Python modules. We compile these modules against the version of Python we distribute. There were many problems when these modules were used with other Python distributions. Not only did minor version differences (2.4.1 versus 2.4.2) cause modules to break, but even having the exact same Python version compiled with a different compiler could cause things to break (eg. dynamic libraries might not have C++ code initialized). So we recommend only using the included Python when running Chimera. Tom
On Sat, 22 Oct 2005, Mingfeng Yang wrote:
I have a trivial question. I see that a python package is wrapped into chimera release. However, nowadays, usually python is a default on almost each linux distribution. Is there any way that I can let chimera use my won python which I built and optimized for my platform, instead of the wrapped python?
The current chimera, 1.2180, is distributed with a slightly modified version of Python 2.4.2. Most but not all of the .py files are the same (we have incorporated some bug fixes that chimera needs), and the python binary is different. If your system python is version 2.4-2.4.2, then it is safe to replace it with chimera's, but not the other way around. In general, it is a support nightmare for us to use the system versions of the packages we distribute. All of our stuff is tested together and we can find bugs fairly easily because we have the exact source code for everything that chimera is using. All of our stuff is compiled with the same compiler, which may be different than the system one, the configuration options are all compatible, and we incorporate bug fixes that affect chimera.
Another question, according to your experience. Which graphics cards can afford good performance for chimera, in another word, best compatiable with chimera under linux platform? Our group always use graphics card from ATI, but AFAIK, ATI cards just suck.
I assume you're asking about ATI's gaming graphics cards and not the workstation ones? The workstation graphics cards, ATI FireGL, NVidia Quadro, and 3dLabs Wildcat, are all good and have good OpenGL drivers (and if you want true stereo you have to buy a workstation graphics card, even Apple will now sell you a Quadro if you want stereo). It used be true that the OpenGL graphics drivers for ATI gaming cards (Radeons) were not as good as the NVidia ones, but I believe that there is no longer much difference in quality between the two (as far as chimera is concerned). Just make sure you're running the lastest graphics driver -- currently version 8.18.6 for ATI on Linux. If you have an older laptop with ATI graphics (pre- Mobility Radeon 9600), then you're out of luck, unless the laptop vendor provides newer drivers. With both ATI and NVidia, installing a new graphics driver may make chimera stop working. So be preprared to downgrade to an earlier version if necessary and please send us email telling which version of the driver caused the failure. Often, there will be yet another driver available from ATI/NVidia within in a week or two that fixes the problem. Greg Couch UCSF Computer Graphics Lab gregc@cgl.ucsf.edu
Hi Charlie, We distribute the Chimera headers and Python headers but it is a separate download. They can be obtained from the Chimera Programmer's Guide page. http://www.cgl.ucsf.edu/chimera/docs/ProgrammersGuide/index.html The current headers are for Chimera version 1.2180 (and are identical for 1.2181). You should be able to compile matplotlib and other Python modules using the Chimera Python and Chimera Python headers for use within Chimera. For the soon to be released Chimera production version (probably 1.2182) we will put the Chimera code and headers on the source code download page: http://www.cgl.ucsf.edu/chimera/sourcecode.html Currently the headers are not on that page and are hard to find in the Programmer's Guide. Tom
Charlie Moad wrote:
Also, here is a case scenario. I can build matplotlib (matplotlib.sf.net) with the following command:
CPPFLAGS="-I/usr/include/python2.4" /usr/local/chimera/bin/python2.4 setup.py install
I have python2.4.2 installed, so I just use those headers. This works. Now when I try to use matplotlib I get an unresolved symbol, "PyUnicodeUCS4_AsUnicode" from one of its shared libraries. This symbol is located in libpython2.4.so, which is not in the chimera bundle. I can work around this by launching chimera with:
LD_PRELOAD="/usr/lib/python2.4/config/libpython2.4.so" chimera
This is obviously a temporary work-around. I would hope windows won't be this complicated. Any suggestions on how to better address an issue like this?
This can't be a good solution. The symbol PyUnicodeUCS4_AsUnicode indicates your system Python that was compiled with --enable-unicode=ucs4 (enabling 4-byte Unicode strings). The Python binary that came with Chimera on my system was compiled with --enable-unicode=ucs2. When you compiled matplotlib with your system python, it read the system python headers and made some references to the Python 4-byte unicode functions. I'd bet dollars to donuts that if you attempted to do anythign with Unicode in matplotlib from that point you'd experience some problems. Please try downloading the Python headers for Chimera, install those, and build/install matplotlib using the Chimera python. Dave
I am using the standard python with Ubuntu 5.10. The headers I was pointed to in a previous e-mail only contain the headers for chimera. My current impression is that the python headers that chimera was built against are not available. If this is not the case, please point me to a direct link. Thanks, On 10/24/05, David E. Konerding <dekonerding@lbl.gov> wrote:
Charlie Moad wrote:
Also, here is a case scenario. I can build matplotlib (matplotlib.sf.net) with the following command:
CPPFLAGS="-I/usr/include/python2.4" /usr/local/chimera/bin/python2.4 setup.py install
I have python2.4.2 installed, so I just use those headers. This works. Now when I try to use matplotlib I get an unresolved symbol, "PyUnicodeUCS4_AsUnicode" from one of its shared libraries. This symbol is located in libpython2.4.so, which is not in the chimera bundle. I can work around this by launching chimera with:
LD_PRELOAD="/usr/lib/python2.4/config/libpython2.4.so" chimera
This is obviously a temporary work-around. I would hope windows won't be this complicated. Any suggestions on how to better address an issue like this?
This can't be a good solution. The symbol PyUnicodeUCS4_AsUnicode indicates your system Python that was compiled with --enable-unicode=ucs4 (enabling 4-byte Unicode strings). The Python binary that came with Chimera on my system was compiled with --enable-unicode=ucs2.
When you compiled matplotlib with your system python, it read the system python headers and made some references to the Python 4-byte unicode functions. I'd bet dollars to donuts that if you attempted to do anythign with Unicode in matplotlib from that point you'd experience some problems.
Please try downloading the Python headers for Chimera, install those, and build/install matplotlib using the Chimera python.
Dave
Hi Charlie, You're right, the header files I pointed you to in the previous email only inluded Chimera headers, not Python headers. Sorry about that. Here are the Chimera 2181 (same as 2180) headers for Chimera and Python. https://www.cgl.ucsf.edu/cgi-bin/chimera-get.py?file=source/chimera-1.2181-h... These will be shown on the Chimera source code page http://www.cgl.ucsf.edu/chimera/sourcecode.html when our web pages are updated tonight. Tom
Thanks for posting these. Unfortunately I am hitting a weird error on any cpython module I try to build. In file included from /usr/local/chimera/include/python2.4/Python.h:55, /usr/local/chimera/include/python2.4/pyport.h:612:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." error: command 'gcc' failed with exit status 1 There a lot of google hits referencing this error, but nothing recent or helpful. For some reason the architecture is incorrectly identified as 64-bit. I should note that the stock python does not generate this error. Are there any special requirements for build with chimera? - Charlie On 10/24/05, Thomas Goddard <goddard@cgl.ucsf.edu> wrote:
Hi Charlie,
You're right, the header files I pointed you to in the previous email only inluded Chimera headers, not Python headers. Sorry about that.
Here are the Chimera 2181 (same as 2180) headers for Chimera and Python.
https://www.cgl.ucsf.edu/cgi-bin/chimera-get.py?file=source/chimera-1.2181-h...
These will be shown on the Chimera source code page
http://www.cgl.ucsf.edu/chimera/sourcecode.html
when our web pages are updated tonight.
Tom
There are lots of special requirements for building chimera. A lot of the work we do is to get chimera running on a variety of platforms. For instance, the Linux chimera is built on Red Hat 7.1 using gcc 3.3.3. We build on an ancient version of Linux so chimera will run on most, if not all, of the current versions of Linux. I've attached the pyconfig.h file from our Linux build, which is probably different than the chimera/include/python2.4/pyconfig.h that you have. For compiler flags, we always pass in "-ansi -pthread -fPIC -malign-double" to gcc. - Greg On Tue, 25 Oct 2005, Charlie Moad wrote:
Date: Tue, 25 Oct 2005 11:55:55 -0500 From: Charlie Moad <cwmoad@gmail.com> To: Thomas Goddard <goddard@cgl.ucsf.edu> Cc: chimera-users@cgl.ucsf.edu Subject: Re: [Chimera-users] new version available
Thanks for posting these. Unfortunately I am hitting a weird error on any cpython module I try to build.
In file included from /usr/local/chimera/include/python2.4/Python.h:55, /usr/local/chimera/include/python2.4/pyport.h:612:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." error: command 'gcc' failed with exit status 1
There a lot of google hits referencing this error, but nothing recent or helpful. For some reason the architecture is incorrectly identified as 64-bit. I should note that the stock python does not generate this error. Are there any special requirements for build with chimera?
- Charlie
On 10/24/05, Thomas Goddard <goddard@cgl.ucsf.edu> wrote:
Hi Charlie,
You're right, the header files I pointed you to in the previous email only inluded Chimera headers, not Python headers. Sorry about that.
Here are the Chimera 2181 (same as 2180) headers for Chimera and Python.
https://www.cgl.ucsf.edu/cgi-bin/chimera-get.py?file=source/chimera-1.2181-h...
These will be shown on the Chimera source code page
http://www.cgl.ucsf.edu/chimera/sourcecode.html
when our web pages are updated tonight.
Tom
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
My guess about Charlie's problem is that we are giving him the Python header files from our 64-bit Alpha machine. Perhaps the pyconfig.h you attached will cure this ill. --Eric On Oct 25, 2005, at 10:31 AM, Greg Couch wrote:
There are lots of special requirements for building chimera. A lot of the work we do is to get chimera running on a variety of platforms. For instance, the Linux chimera is built on Red Hat 7.1 using gcc 3.3.3. We build on an ancient version of Linux so chimera will run on most, if not all, of the current versions of Linux. I've attached the pyconfig.h file from our Linux build, which is probably different than the chimera/include/python2.4/pyconfig.h that you have. For compiler flags, we always pass in "-ansi -pthread -fPIC -malign-double" to gcc.
- Greg
On Tue, 25 Oct 2005, Charlie Moad wrote:
Date: Tue, 25 Oct 2005 11:55:55 -0500 From: Charlie Moad <cwmoad@gmail.com> To: Thomas Goddard <goddard@cgl.ucsf.edu> Cc: chimera-users@cgl.ucsf.edu Subject: Re: [Chimera-users] new version available
Thanks for posting these. Unfortunately I am hitting a weird error on any cpython module I try to build.
In file included from /usr/local/chimera/include/python2.4/Python.h:55, /usr/local/chimera/include/python2.4/pyport.h:612:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." error: command 'gcc' failed with exit status 1
There a lot of google hits referencing this error, but nothing recent or helpful. For some reason the architecture is incorrectly identified as 64-bit. I should note that the stock python does not generate this error. Are there any special requirements for build with chimera?
- Charlie
On 10/24/05, Thomas Goddard <goddard@cgl.ucsf.edu> wrote:
Hi Charlie,
You're right, the header files I pointed you to in the previous email only inluded Chimera headers, not Python headers. Sorry about that.
Here are the Chimera 2181 (same as 2180) headers for Chimera and Python.
https://www.cgl.ucsf.edu/cgi-bin/chimera-get.py?file=source/chimera -1.2181-headers.tar.gz
These will be shown on the Chimera source code page
http://www.cgl.ucsf.edu/chimera/sourcecode.html
when our web pages are updated tonight.
Tom
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users <pyconfig.h>_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
The new pyconfig file worked. Thanks for walking me through this. - Charlie On 10/25/05, Eric Pettersen <pett@cgl.ucsf.edu> wrote:
My guess about Charlie's problem is that we are giving him the Python header files from our 64-bit Alpha machine. Perhaps the pyconfig.h you attached will cure this ill.
--Eric
On Oct 25, 2005, at 10:31 AM, Greg Couch wrote:
There are lots of special requirements for building chimera. A lot of the work we do is to get chimera running on a variety of platforms. For instance, the Linux chimera is built on Red Hat 7.1 using gcc 3.3.3. We build on an ancient version of Linux so chimera will run on most, if not all, of the current versions of Linux. I've attached the pyconfig.h file from our Linux build, which is probably different than the chimera/include/python2.4/pyconfig.h that you have. For compiler flags, we always pass in "-ansi -pthread -fPIC -malign-double" to gcc.
- Greg
On Tue, 25 Oct 2005, Charlie Moad wrote:
Date: Tue, 25 Oct 2005 11:55:55 -0500 From: Charlie Moad <cwmoad@gmail.com> To: Thomas Goddard <goddard@cgl.ucsf.edu> Cc: chimera-users@cgl.ucsf.edu Subject: Re: [Chimera-users] new version available
Thanks for posting these. Unfortunately I am hitting a weird error on any cpython module I try to build.
In file included from /usr/local/chimera/include/python2.4/Python.h:55, /usr/local/chimera/include/python2.4/pyport.h:612:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)." error: command 'gcc' failed with exit status 1
There a lot of google hits referencing this error, but nothing recent or helpful. For some reason the architecture is incorrectly identified as 64-bit. I should note that the stock python does not generate this error. Are there any special requirements for build with chimera?
- Charlie
On 10/24/05, Thomas Goddard <goddard@cgl.ucsf.edu> wrote:
Hi Charlie,
You're right, the header files I pointed you to in the previous email only inluded Chimera headers, not Python headers. Sorry about that.
Here are the Chimera 2181 (same as 2180) headers for Chimera and Python.
https://www.cgl.ucsf.edu/cgi-bin/chimera-get.py?file=source/chimera -1.2181-headers.tar.gz
These will be shown on the Chimera source code page
http://www.cgl.ucsf.edu/chimera/sourcecode.html
when our web pages are updated tonight.
Tom
_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users <pyconfig.h>_______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
Hi Charlie, As noted by Greg and Eric the Python configuration header file pyconfig.h depends on the operating system. It is created when Python is configured. To handle this I have changed our source code download page to provide header distributions for different platforms. When that page is updated tonight it will have the Tru64 headers and Linux headers. Thanks for your patience. Our C++ and header source code distributions are new and we're still figuring out how to make this work. Tom
While the help notes for the alignment editor says that gaps can be created, I can't see how! Surely I'm missing something... Selecting a residue or set of residues to create a region, then applying ctrl-left-arrow (or right arrow) yields an error complaining of a lack of gaps in the region ("No gap available in <seq name>"). This makes me think that regions can only be moved if they are already bounded by gaps. Which in turn leaves me stumped as how to create the initial gaps manually...! What I had expected was for it to insert new gaps to the let of the region if applying ctrl-right-arrow to a region and vice versa for using ctrl-left-arrow. I'm using 2.180 on Mac OS X 10.4.2 Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 478 0095 (office, after 10am) PO Box 6129, or +64 27 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training 15 years experience in bioinformatics ready to solve your problem Check out the website for more details: http://www.bioinfotools.com The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents.
Hi Grant, The editing facilities in Multalign Viewer are somewhat basic and could stand improvement (e.g. undo would be nice). You can only move a region in a certain direction if there is a gap somewhere ahead of the region that can be removed and placed behind the moving region. MAV won't increase the length of your alignment (by placing an all-gap column on the end) in order to allow the motion [this is mentioned in the docs]. A workaround is to save your alignment to a file and edit the file to add the all-gap columns necessary to allow your motion. I would suggest FASTA or PIR formats, since those are the simplest to change. Of course, at that point you may be able to make all the changes you want with a text editor and just cut MAV out of the loop -- it would depend on what you're doing. --Eric Eric Pettersen UCSF Computer Graphics Lab pett@cgl.ucsf.edu http://www.cgl.ucsf.edu On Oct 27, 2005, at 4:09 AM, Grant Jacobs wrote:
While the help notes for the alignment editor says that gaps can be created, I can't see how! Surely I'm missing something...
Selecting a residue or set of residues to create a region, then applying ctrl-left-arrow (or right arrow) yields an error complaining of a lack of gaps in the region ("No gap available in <seq name>"). This makes me think that regions can only be moved if they are already bounded by gaps. Which in turn leaves me stumped as how to create the initial gaps manually...!
What I had expected was for it to insert new gaps to the let of the region if applying ctrl-right-arrow to a region and vice versa for using ctrl-left-arrow.
I'm using 2.180 on Mac OS X 10.4.2
Grant -- ------------------------------------------------------------------- Grant Jacobs Ph.D. BioinfoTools ph. +64 3 478 0095 (office, after 10am) PO Box 6129, or +64 27 601 5917 (mobile) Dunedin, gjacobs@bioinfotools.com NEW ZEALAND. Bioinformatics tools: deriving knowledge from biological data Bioinformatics tools - software development - consulting - training 15 years experience in bioinformatics ready to solve your problem Check out the website for more details: http://www.bioinfotools.com
The information contained in this mail message is confidential and may be legally privileged. Readers of this message who are not the intended recipient are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify the sender immed- iately and destroy the original message. This applies also to any attached documents. _______________________________________________ Chimera-users mailing list Chimera-users@cgl.ucsf.edu http://www.cgl.ucsf.edu/mailman/listinfo/chimera-users
I have had great success building an integrating matplotlib into a plugin. I was able to build a binary plugin for windows and linux. Now I am curious what header files I will need for osx/x11. Do I just need a different pyconfig.h file? Thanks, Charlie On 10/25/05, Thomas Goddard <goddard@cgl.ucsf.edu> wrote:
Hi Charlie,
As noted by Greg and Eric the Python configuration header file pyconfig.h depends on the operating system. It is created when Python is configured.
To handle this I have changed our source code download page to provide header distributions for different platforms. When that page is updated tonight it will have the Tru64 headers and Linux headers.
Thanks for your patience. Our C++ and header source code distributions are new and we're still figuring out how to make this work.
Tom
Hi Charlie, You will need the Mac Python configuration header file pyconfig.h to compile your Python module on the Mac and have it work with Chimera. I added Chimera and third party header files for the Mac to our source code download page: http://www.cgl.ucsf.edu/chimera/sourcecode.html Compiling a python module on the Mac also involves some special linking flags. The Mac has "dynamic libraries" and "bundles" and as far as I know Python can only import bundles. That was the case a few years ago. Here are a couple link examples that make bundles on the Mac. gcc -I/usr/local/src/staff/goddard/mac-10.4/build/include -L/usr/local/src/staff/goddard/mac-10.4/build/lib -DUSE_DYLD_GLOBAL_NAMESPACE -bundle -bundle_loader /usr/local/src/staff/goddard/mac-10.4/foreign/Python-2.4/bin/python2.4 Scientific_netcdf.o -Lnetcdf/lib -lnetcdf -o Scientific_netcdf.so cc -bundle -bundle_loader /usr/local/src/staff/goddard/builds/mac-10.3/chimera-2095/build/bin/python2.4 -o _contour.so -O -Wall -Wno-long-double contourdata.o pycontour.o _contour.o ContourObject.o -L/usr/local/src/staff/goddard/builds/mac-10.3/chimera-2095/build/lib -L../_volumearray -lrcarray -lwrappy -lstdc++ The flags -bundle and -bundle_loader <path-to-python-executable> are the important ones. These replace the usual -shared on other platforms. I'm not sure about -DUSE_DYLD_GLOBAL_NAMESPACE -- we don't use that for building the python modules we write but it appears that third-party packages we use define that macro. Tom
participants (7)
-
Charlie Moad -
David E. Konerding -
Eric Pettersen -
Grant Jacobs -
Greg Couch -
Mingfeng Yang -
Thomas Goddard