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

                    http://www.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

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

                    http://www.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

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

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

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

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

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

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