Re: [COOT] ipod version of coot?
The problem with the iPhone is that the OpenGL library it uses is only a subset of the OpenGL used on real computers, so porting any existing molecular graphics application would be non-trivial, aside from the many other issues with developing for iPhone. I do like the idea of using the touch-screen for building, though. The graphics chip itself is actually quite powerful so there's no reason why it couldn't be done. . . but who has time? On Mon, Jul 28, 2008 at 10:01 AM, William G. Scott < [EMAIL PROTECTED]> wrote: > This is via VNSea (jailbroken ipod), but it got me thinkin'... > >
Re: [COOT] Fedora 8 binary core dumps - please help
This may not be required any more, but I remember having to explicitly add the GLX module to the list of extensions to get NVidia cards to work. I'm not sure exactly what the syntax is, but I know the module is just called "glx", so maybe try putting 'Options "glx" "Enabled"' in the 'Extensions' section. On Mon, Oct 20, 2008 at 1:38 PM, Scott Classen <[EMAIL PROTECTED]> wrote: > SO I added the "Extensions" stanza to my xorg.conf file as you suggested > but I still get a non-functional COOT. > > FYI here is my xorg.conf file: > > > # nvidia-settings: X configuration file generated by nvidia-settings > # nvidia-settings: version 1.0 ([EMAIL PROTECTED]) Thu Feb 14 > 18:21:33 PST 2008 > > # Xorg configuration created by system-config-display > > Section "ServerLayout" >Identifier "single head configuration" >Screen 0 "Screen0" 0 0 >InputDevice"Mouse0" "CorePointer" >InputDevice"Keyboard0" "CoreKeyboard" > EndSection > > Section "ServerFlags" >Option "Xinerama" "0" > EndSection > > Section "Extensions" >Option "Composite" "Disabled" > EndSection > > Section "InputDevice" > ># generated from default >Identifier "Mouse0" >Driver "mouse" >Option "Protocol" "auto" >Option "Device" "/dev/input/mice" >Option "Emulate3Buttons" "no" >Option "ZAxisMapping" "4 5" > EndSection > > Section "InputDevice" >Identifier "Keyboard0" >Driver "kbd" >Option "XkbModel" "pc105" >Option "XkbLayout" "us+inet" > EndSection > > Section "Monitor" >Identifier "Monitor0" >VendorName "Unknown" >ModelName "CRT-0" >HorizSync 30.0 - 110.0 >VertRefresh 50.0 - 150.0 >Option "DPMS" > EndSection > > Section "Device" >Identifier "Videocard0" >Driver "nvidia" >VendorName "NVIDIA Corporation" >BoardName "GeForce FX 5200" > EndSection > > Section "Screen" >Identifier "Screen0" >Device "Videocard0" >Monitor"Monitor0" >DefaultDepth24 >Option "TwinView" "0" >Option "TwinViewXineramaInfoOrder" "CRT-0" >Option "metamodes" "1600x1200_60 +0+0" >SubSection "Display" >Depth 24 >EndSubSection > EndSection > > > The main COOT window pane displays with all the menu items but the contents > of the window (i.e. the really important stuff) just shows a ghost of my > desktop. > > These are the errors that are output from the terminal: > > > (coot-real:5388): GtkGLExt-WARNING **: cannot create GdkGLContext > > > (coot-real:5388): GdkGLExt-CRITICAL **: > gdk_gl_window_impl_x11_make_context_current: assertion > `GDK_IS_GL_CONTEXT_IMPL_X11 (glcontext)' failed > > (coot-real:5388): GtkGLExt-WARNING **: cannot create GdkGLContext > > > (coot-real:5388): GdkGLExt-CRITICAL **: > gdk_gl_window_impl_x11_make_context_current: assertion > `GDK_IS_GL_CONTEXT_IMPL_X11 (glcontext)' failed > > (coot-real:5388): GtkGLExt-WARNING **: cannot create GdkGLContext > > > (coot-real:5388): GdkGLExt-CRITICAL **: > gdk_gl_window_impl_x11_make_context_current: assertion > `GDK_IS_GL_CONTEXT_IMPL_X11 (glcontext)' failed > > (coot-real:5388): GtkGLExt-WARNING **: cannot create GdkGLContext > > > - Original Message - > From: Tim Fenn <[EMAIL PROTECTED]> > Date: Friday, October 17, 2008 5:38 pm > Subject: Re: Fedora 8 binary core dumps - please help > To: COOT@JISCMAIL.AC.UK > > > On Fri, 17 Oct 2008 16:55:17 -0700 Scott Classen <[EMAIL PROTECTED]> > > wrote: > > > > > Hello, > > > > > > Desktop effects are NOT turned on. > > > ccp4i 6.0.2 works fine. > > > > > > I just tried the latest nightly and that didn't work either > > > > > > coot-0.5.1-pre-1-revision-1502-binary-Linux-i386-fedora-8-python- > > gtk2.tar.gz> > > > I have a hunch this has something to do with my graphics card. I > > have> an NVIDIA card (GeForce FX 5200) I've installed the nvidia linux > > > drivers NVIDIA Driver Version 169.12 > > > > > > > Most likely its a xorg thing - can you post your xorg.conf? Did you > > check the xorg log for errors? Did you use the nvidia installer > > script, or a pre-built binary for your distribution? I do recall there > > being problems with nvidia's driver and the composite extension that > > would cause this sort of thing (since GLX gets disabled if there is a > > conflict), you may want to check that the following is in your > > xorg.conf: > > > > Section "Extensions" > >Option "Composite" "Disabled" > > EndSection > > > > -Tim > > > > -- > > - > > > >Tim Fenn > >[EMAIL PROTECTED] > >Stanford University, School of Medicine > >James H. Clark Center > >318 Campus Drive, Room E300 > >Stanford, CA 94305-5432 > >Phone: (650) 736-1714 > >FAX: (650) 736-1961 > > > > --
Re: [COOT] coot for 10.4 and 10.5 intel
On Thu, Dec 11, 2008 at 3:05 AM, William Scott wrote: > I need a couple of people to volunteer to test this on 10.4 and 10.5 intel > machines: > > http://sage.ucsc.edu/xtal/coot/coot-0.5-pre1-intel_10.4_10.5.tgz > This build appears to have python embedded more or less correctly, so it now uses the built-in interpreter when launched with "--script test.py": coot-0.5: sys.executable = /Users/nat/phenix/build/bin/python coot-0.5-pre1: sys.executable = /usr/local/xtal/coot/bin/coot-real I wish I knew what the difference in the builds was. . . I'm going to try the fink version next. Unfortunately, there appear to be problems with the actual Python modules. I'm not entirely sure what specifically is broken, but I have to manually add /usr/local/xtal/coot/share/coot/python to sys.path, and the module formerly known as coot_python does not appear to exist any more (but is still referenced in several places). So it doesn't look like it's possible to manipulate the GUI from Python right now, although this is clearly a step in the right direction. [I can send more info to Paul/Bernhard off-list if this isn't a known problem.] thanks, Nat
Re: [COOT] coot for 10.4 and 10.5 intel
Hey Bill, this has the correct and complete Python module search paths too (although /usr/local/xtal/coot/share/coot/python is repeated four times, but this doesn't appear to break anything). What's the difference between this and the coot-0.5-pre1 build you sent out on Thursday? thanks, Nat (still no coot_python, but I'm pretty sure that's a different problem.) On Fri, Dec 12, 2008 at 9:40 PM, William Scott wrote: > Is this one any better? > > > http://sage.ucsc.edu/~wgscott/xtal/wiki/index.php/Coot-0.5.1-pre1_revision_1661_for_intel-10.4-10.5 > > > > On Fri, December 12, 2008 2:53 am, Valerie Biou wrote: > > Hi Bill, > > > > I installed it this morning and it starts ok. all I tried is SSM, it > still > > crashes. Do you want me to test other things? > > all the best > > > > Valerie > > > > > > > > William G. Scott > > Contact info: > http://chemistry.ucsc.edu/~wgscott/ >
Re: [COOT] python and coot question
This has been a problem on and off with recent OS X binary builds too. The interpreter is actually supposed to be coot itself - I don't think /sw/bin/python is going to do you any good, since it doesn't have access to the memory of the running coot process. I don't know what the source of the variability is, unfortunately, but the binaries I was using of coot-0.5-pre1 had this problem, while coot-0.5.1-pre1-1661 used the correct interpreter. I assume it's something in the makefiles, or some difference in configure options. . . but I don't have these. On Fri, Jan 30, 2009 at 10:35 AM, William G. Scott < wgsc...@chemistry.ucsc.edu> wrote: > Hi citizens: > > OS X comes with a version of python that doesn't play well with > x-windows-based modules, so when compiling and running coot, I would like to > make sure that I use a different version of python that has things like the > gtk2 modules in its sys.path. However, despite having the other python > (/sw/bin/python) at the head of my $PATH, the system python seems to be > embedded in coot's interpreter, at least from what I can see: > > This is what I want: > > zsh-% which python > /sw/bin/python > > zsh-% python > Python 2.6 (r26:66714, Nov 2 2008, 12:54:49) > [GCC 4.0.1 (Apple Inc. build 5484)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import sys > >>> print sys.path > ['', '/sw/lib/python26.zip', '/sw/lib/python2.6', > '/sw/lib/python2.6/plat-darwin', '/sw/lib/python2.6/plat-mac', > '/sw/lib/python2.6/plat-mac/lib-scriptpackages', '/sw/lib/python2.6/lib-tk', > '/sw/lib/python2.6/lib-old', '/sw/lib/python2.6/lib-dynload', > '/sw/lib/python2.6/site-packages', > '/sw/lib/python2.6/site-packages/Numeric', > '/sw/lib/python2.6/site-packages/gtk-2.0'] > >>> > > > But with coot, I think it is using /usr/bin/python, because I get this: > > COOT_PYTHON_DIR was defined to be /sw/share/coot/python > but no PyGtk and hence no coot_gui. > Entry contents: print sys.path > Running string: print sys.path > ['/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python25.zip', > '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5', > '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-darwin', > '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac', > '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/plat-mac/lib-scriptpackages', > '/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python', > '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-tk', > '/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/lib-dynload', > '/Library/Python/2.5/site-packages', > '/System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/PyObjC', > '/sw/share/coot/python', '/sw/share/coot/python', '/sw/share/coot/python', > '/sw/share/coot/python'] > > which is the same sys.path I get for /usr/bin/python, apart from the last > four redundant entries. > > How do I deal with this? > > > Bill >
Re: [COOT] on the topic of secondary struct. assignments...
There is an open-source implementation of the dssp method called ksdssp, written by the UCSF group that distributes Chimera. I haven't had reason to use it yet but the source definitely has functions for writing out the pdb records. I suspect that one of the BioPython/perl/ etc. modules has the necessary conversion functions, although it might take a bit of coding to apply them. On Feb 8, 2009, at 4:32 PM, Don Kerkow wrote: Hi all, After seeing the string on secondary struct. assignment and molecular visualization, I was wondering if anyone knows if there is a way to produce the HELIX and SHEET records (i.e. explicit secondary struct. assignment) automatically without depositing to PDB. Obviously, I realize I could write this header manually based on the assignments I get from DSSP, but for a large structure I was hoping there is an easier way. I need this header for making accurate cartoon figures in Pymol, but I am not yet ready to deposit the structure if that is the only way to acquire such a header automatically. Any help is much appreciated! Don Kerkow
[COOT] how do I delete all objects with a script?
Is this even possible? Either Python or Scheme would be okay. I figured out how to hide everything (in Python), but I'm trying to reload files via a button, and they always have the same name, so the display manager becomes confusing quickly. thanks, Nat
Re: [COOT] automated update of PDB file
> > I'm looking for a script that automatically loads a PDB file when it has >> changed on disk in order to display the changes with a previous version of >> that file. >> > Here is a Python version. I prefer to overwrite the old molecule - but this will work either way. (I think - it is untested but I do similar things already.) import os.path import gobject import coot # usage: # pdb_file_monitor(pdb_file) # or: # imol = read_pdb(pdb_file) # pdb_file_monitor(pdb_file, imol) # class pdb_file_monitor (object) : def __init__ (self, pdb_file, pdb_object_id=None) : self.pdb_file = pdb_file self.pdb_object_id = pdb_object_id self.last_mtime = os.path.getmtime(pdb_file) gobject.timeout_add(200, self.update_pdb) def update_pdb (self, *args) : current_mtime = os.path.getmtime(self.pdb_file) if current_mtime > self.last_mtime : if self.pdb_object_id is None : handle_read_draw_molecule_with_recentre(self.pdb_file) else : clear_and_update_model_molecule_from_file(self.pdb_object_id, self.pdb_file) self.last_mtime = current_mtime
Re: [COOT] Colour by ramachandran?
On Tue, Apr 28, 2009 at 3:52 PM, Oliver Clarke wrote: > Is it possible in coot to script a way to colour residues by their position > on the ramachandran plot? This would be really handy, particularly for large > structures, in order to visually see where problem areas of the structure > are. I'm thinking of something like alpha=green, beta=blue, left=yellow, and > outliers=red. On a similar note, would it be possible to map the output of > the rotamer analysis and density fit tools onto the structure by colouring > each residue according to rotamer-likelihood or real-space CC? > I have a more general version of this question: is there a function in the scripting interface that would permit atom- or residue-specific manipulations, of color or other properties? I would also find what Oliver describes useful, but I'm limited to doing this in PyMOL right now.
Re: [COOT] problem with install on new Macbook Pro (OS X 10.5)
On Fri, Jun 5, 2009 at 9:54 AM, Jason Greenwald < jason.greenw...@phys.chem.ethz.ch> wrote: > In the meantime I am using the COOT.app package from the CCP4 download > site, so if anyone knows how to save more than one session using this > installation, I would be happy to hear it. > I couldn't find this package anywhere on the CCP4 site, so perhaps they've removed it. However, I assume that it works like any other Mac app, i.e. the actual executable is embedded somewhere in the bundle, usually in a standard place. If you're opening the program in the Finder, it will always start in your home directory. However, you can still launch the program on the command line in any directory you choose, by calling the executable itself. For instance, in MacPyMOL, /Applications/MacPyMOL.app/Contents/MacOS/MacPyMOL is the real command, and I have alias pymol='/Applications/MacPyMOL.app/Contents/MacOS/MacPyMOL' in my .profile.
Re: [COOT] Coot finding phenix.probe and not standalone probe
On Mon, Aug 17, 2009 at 8:32 AM, Ben Eisenbraun wrote: > I have a very odd issue. I have two builds of Coot, one for OS X Intel and > one for OS X PPC. On each of those platforms, I have a standalone > probe/reduce in the shell PATH. When I run either of these Coots, they > manage to find and try to use the phenix.probe installed in our linux > branch. > Is Coot doing some magic when it tries to figure out where probe/reduce are > installed? Grepping through the source looking for phenix didn't turn > anything obvious up. The file ~/.coot may define a specific binary, which I assume will override anything in $PATH. The Phenix GUI will modify this file (only if you launch Coot from it) to ensure that Coot can find Probe, which could be causing the problem - I didn't take into account the possibility of a home directory being shared across multiple platforms. Sorry if this is the case. Fortunately, I'm pretty sure I can do this on the fly from Python instead and leave ~/.coot alone. -Nat
Re: [COOT] Coot finding phenix.probe and not standalone probe
On Mon, Aug 17, 2009 at 9:50 AM, Ben Eisenbraun wrote:
> > The Phenix GUI will modify this file (only if you launch Coot from it) to
> > ensure that Coot can find Probe, which could be causing the problem - I
> > didn't take into account the possibility of a home directory being shared
> > across multiple platforms.
>
> Yes, that's the situation. NFS home directories for everyone over here.
>
Oops. I'll get rid of that "feature". However, I'm having trouble doing
the equivalent in Python - I tried this:
run_scheme_command("define *probe-command* \"%s\"" % probe_command)
and it gave me this output:
INFO:: Command: define *probe-command*
"/Users/nat/phenix/src/build/mac-intel-osx/bin/phenix.probe"
I tried it with parentheses too, but either way, I don't get an error but
Coot still doesn't think Probe is there (i.e. the menu item is grayed out).
Is it even possible to set these paths from Python?
thanks,
Nat
[COOT] map coefficient labels
Is there a way to open map files from a script with the actual column labels alone, instead of /crystal/dataset/F, etc.? I tried /*/*/F, but this doesn't work in 0.6. One of my coworkers claims that MTZ files don't allow duplicate column names regardless of which crystal or dataset ID they're associated with, and in practice none of the programs I've used output columns for more than one crystal/dataset anyway. However, some of them *do* produce very different crystal or dataset IDs - in some cases, it appears to be nearly random! Right now I have to open up the MTZ file separately and figure out what they are, which is a little more overhead than I'd like. thanks, Nat
Re: [COOT] Scripting missing in CCP4 distribution of COOT v0.6.0 CCP4 (OS X 10.4+ universal dmg installer)
On Mon, Jan 4, 2010 at 12:43 PM, Huw Jenkins wrote: > I guess this means something to do with the scheme scripting isn't getting > properly defined in the coot script but I can't work out what from > comparisons of the old and new coots. > The package distributed by CCP4 was not compiled with support for either Scheme or Python. I'm pretty sure this isn't something you can patch, so you'll need to use one of Bill's tarballs or the Fink distribution. clover:~ > /Applications/Coot.app/Contents/MacOS/coot --version COOT_PREFIX is /Applications/Coot.app/Contents/MacOS/../coot /Applications/Coot.app/Contents/MacOS/../coot/bin/coot-real --version 0.6 (revision 2540) clover:~ > /sw/bin/coot --version 0.6 (revision 2540) [with guile 1.8.6 embedded] [with python 2.6.4 embedded] -Nat
Re: [COOT] how to do sphere refinement
2010/1/11 Sara Züger > Thanks Miguel, > > but is there another way to do this sphere refinement? I'm working on a > shared computer and have no administrator rights and also no experience > with > python/file handling of coot. > > Or else, if there is no other way, can somebody explain me exactly what I > have to do/type (like copying a coot.py file into a local folder and change > that, but how then to tell coot to use this file?) > Coot will automatically use ~/.coot.py if present - all you need to do is copy-and-paste Miguel's code snippet. You don't need administrator rights, since you're only modifying your home directory. -Nat
Re: [COOT] opening PDB downloaded .cif files in Mac OS
On Fri, Feb 5, 2010 at 12:34 PM, subh wrote: > Hi, > I am trying to open the .cif file (in coot) that I downloaded from PDB, in > my Mac OS X. > Coot cannot open the map. Could you suggest how I can see the map that is > downloaded form the PDB-RCSB web site. > What does Coot print out on the console when you try to open the file? The data in these files isn't consistent, so there could be multiple reasons why it doesn't work (I just tried two different files and got two different errors). Missing symmetry information is the most obvious. Nat
Re: [COOT] hydrogens hanging after removal of alternate conformation
On Tue, Mar 16, 2010 at 12:56 PM, Paul Emsley wrote: > Coot is distributed with a copy of the refmac library, which has PDB > version 2.3 atom names. > > You can override that dictionary by setting up CCP4 in the normal way. > You can further override the dictionary by setting the environment variable > COOT_REFMAC_LIB_DIR > > So if Phenix distributes a version of the monomer library that has PDB > version 3.x atom names then Coot can use that if you point to it. Unfortunately, the monomer library in Phenix is still using the old atom names - the version 3.x names are handled internally in Python (and Reduce does its own thing anyway). -Nat
[COOT] PyGTK in standalone OS X builds
When I use the 0.6.1 package from Bill's web site, I get this error when I try to start the Python scripting GUI: COOT_PYTHON_DIR was defined to be /usr/local/xtal/coot64/share/coot/python but no PyGtk and hence no coot_gui. Not sure what to do about this, because it appears to have the module installed: nat:~ > ls /usr/local/xtal/coot64/lib/python2.6/site-packages/ README cairo gtk-2.0 numpy numpy-1.3.0-py2.6.egg-info pygtk.pth pygtk.py pygtk.pyo thanks, Nat
Re: [COOT] PyGTK in standalone OS X builds
On Fri, May 14, 2010 at 2:06 PM, William G. Scott < wgsc...@chemistry.ucsc.edu> wrote: > Check /usr/local/xtal/coot64/bin/coot > > to see if I set $PYTHONPATH right. > > It should have /usr/local/xtal/coot64/lib/python2.6/site-packages/gtk-2.0 It does (and that path appears in sys.path). And I just discovered that I can call "import gtk" from a Python script run by Coot, but "import coot_python" fails (which means I can't access the GUI for adding buttons, menus, etc.). Also, the output of "otool -L /usr/local/xtal/coot64/bin/coot-real" includes this: /System/Library/Frameworks/Python.framework/Versions/2.6/Python which doesn't seem right, since Coot comes with and if I add "print sys.executable" to my script, I see the Python interpreter I normally use, not the coot executable. So it appears to be a linker error; I know I've seen this before, but I don't think it's something I can fix. thanks, Nat
