Re: [COOT] Graphics problem running Coot with EdUbuntu 8.10

[Ed Pozharski]

It is not a Ubuntu problem.  I have the same issue on my laptop, and
it's because it has Intel onboard graphics chip.  With NVIDIA cards (at
least on all the desktops I've seen), coot runs fine when you enable
compiz (of course, I do use proprietary nvidia drivers).

On Tue, 2009-05-12 at 14:34 +1200, Shaun Lott wrote:
> Hi Stephen
> 
> On the money - thanks!
> 
> Running GNOME as the desktop environment, doing exactly as you suggest  
> fixes the problem. GNOME was having other stability issues also, which  
> caused some student frustration.
> 
> Alternatively, using Xfce as the desktop environment worked right off  
> the bat.
> 
> I also tried KDE, and if anything it was worse than GNOME, plus I  
> couldn't find where to disable Compiz.
> 
> Hope this helps anyone else who may have struggled with this issue.
> 
> cheers
> 
> Shaun
> 
> --
> Dr J. Shaun Lott
> AgResearch Senior Lecturer in Structural Biology
> Laboratory of Structural Biology & Maurice Wilkins Centre
> School of Biological Sciences
> 3a Symonds Street
> University of Auckland
> Private Bag 92019
> Auckland 1142
> New Zealand
> 
> t   : +64 9 3737599 x87074
> f   : +64 9 3737416
> http://shaunlott.blogspot.com
> 
> On 11 May 2009, at 17:51, Stephen Graham wrote:
> 
> > Hi Shaun,
> >
> > Have you tried turning off compiz?
> > (System > Preferences > Appearance > Visual Effects: Select 'None')
> >
> > Cheers,
> >
> > Stephen
> >
> > On 11/05/2009, Shaun Lott  wrote:
> >> Hi
> >>
> >> Apologies if this problem has been dealt with elsewhere - I scanned  
> >> the
> >> archives but couldn't see anything that looked similar.
> >>
> >> I'm about to use Coot as part of a graduate teaching exercise.  
> >> Version 0.52
> >> starts ok, and can load co-ords and maps, but whenever one clicks,  
> >> the
> >> screen gets corrupted - see attached image. You can get a normal  
> >> view back
> >> by rotating the molecule, but the whole user experience is a pretty
> >> frustrating one, as it is pretty much impossible to click on  
> >> anything. The
> >> fault seems to be hardware and Coot version independent - it  
> >> manifests in
> >> 0.5.2 and also using
> >> 0.6-pre-1-revision-1997-binary-Linux-i686-ubuntu-8.04.2, though less
> >> dramatically in the latter - just a grey screen rather than the  
> >> corrupted
> >> one. The same thing occurs when using a Dell or an iMac running  
> >> Ubuntu
> >> (don't ask...)
> >>
> >> So I'm guessing it's a(n) Ubuntu thing. The machine are running the  
> >> same
> >> versrion of EdUbuntu 8.10, details as below.
> >>
> >> Has anyone else seen this? Does anyone have a fix?
> >>
> >> cheers
> >>
> >> Shaun
> >>
> >>> cat /proc/version
> >> Linux version 2.6.27-7-generic (bui...@palmer) (gcc version 4.3.2  
> >> (Ubuntu
> >> 4.3.2-1ubuntu11) ) #1 SMP Tue Nov 4 19:33:20 UTC 2008
> >>
> >>
> >>
> >
> >
> > -- 
> > Dr Stephen Graham
> > Division of Structural Biology
> > Wellcome Trust Centre for Human Genetics
> > Roosevelt Drive
> > Oxford OX3 7BN
> > United Kingdom
> > Phone: +44 1865 287 549
-- 

Re: [COOT] subversion build on ubuntu 9.04 fails : [: =: unary operator expected error

[hari jayaram]

Hello ,
The jaunty 32 bit build seems to fail ( with subversion revision 2002 as
well)
It seems like based on what Ed Pozharsky wrote in ..its a problem with guile
in Ubuntu jaunty (9.04) ..

On my 32 bit , 9.04 installation , the build-it-gtk2-simple script chugs
along fine and then declares the following contradictory message

checking for Clipper... yes
Congratulations, you are using Guile
checking for guile... no
configure: error: guile required but not found

Regardless ..I will try Bill Scots or the CCP4 wiki
methodof
separately compiling all the coot dependencies . But though I would
wrote
in to inquire if there was already a simpler fix.

Thanks

Hari


On Fri, May 8, 2009 at 7:35 PM, Paul Emsley wrote:

> hari jayaram wrote:
>
>> Hi ..I tried a coot subversion (revision 1994) built-it-simple python on
>> the newest ubuntu 9.04
>>
>> The build crashes just after it builds guile and ( 16-coot.txt in the
>> build directory ) reads :
>>
>> checking for Clipper... yes
>> Congratulations, you are using Guile
>> checking for guile... no
>> configure: error: guile required but not found
>> ./build-it-gtk2-simple: line 2742: [: =: unary operator expected
>> NO need to update libtool
>> /home/hari/autobuild/ex-charlie_2009-05-08__T20_14_49/coot-0.6-pre-1
>> make: *** No targets specified and no makefile found.  Stop.
>>
>> This happens only on the new ubuntu (on a 32 bit 9.04 system) .
>> I was able to build this revision without any problem on Ubuntu 8.04 64
>> bit
>>
>
> Thanks update_libtool is not set sometimes, so using it as in 1994 is
> wrong.  I've tweaked the script.
>
> But the problem for you lies above that..
> > checking for guile... no
> > configure: error: guile required but not found
>
> Hmm!  what went wrong there..?
>
> I'll try to build from scratch on Jaunty myself.
>
> Cheers,
>
> Paul.
>

Re: [COOT] subversion build on ubuntu 9.04 fails : [: =: unary operator expected error

[William G. Scott]

I have the following guile-like stuff installed, if it is of any help:

diablo-% which dpkg-list
dpkg-list () {
dpkg --list \...@\*
}
diablo-% dpkg-list guile | grep "ii"
ii  guile-1.6-libs  
1.6.8-6.3ubuntu1 Main Guile libraries
ii  guile-1.8   
1.8.5+1-4.1ubuntu1   The GNU extension language  
and Scheme interp
ii  guile-1.8-dev   
1.8.5+1-4.1ubuntu1   Development files for Guile 1.8
ii  guile-1.8-doc   
1.8.5+1-4.1ubuntu1   Documentation for Guile 1.8
ii  guile-1.8-libs  
1.8.5+1-4.1ubuntu1   Main Guile libraries
ii  guile-g-wrap
1.9.11-1.1build1 scripting interface generator  
for C - Guile
ii  guile-gnome0-canvas 
2.15.95-2ubuntu1 Guile bindings for  
libgnomecanvas
ii  guile-gnome0-glib   
2.15.95-2ubuntu1 Guile bindings for GLib
ii  guile-goosh 
1.3-1Installs goosh
ii  guile-gui   
0.2-2Installs guile-gui for  
guile-1.8
ii  guile-lib   
0.1.6Installs guile-lib
ii  guile-net-http  
0.3.1-1  Installs the net-http scm file
ii  guile18-gtk 
2.0  guile-gtk-2.0 for guile18
ii  libguile-ltdl-1 
1.6.8-6.3ubuntu1 Guile's patched version of  
libtool's libltdl


I've also noticed that sometimes what the configure error reports  
isn't accurate when you look at the log files -- it might be choking  
on something else.


On May 12, 2009, at 8:11 AM, hari jayaram wrote:


Hello ,
The jaunty 32 bit build seems to fail ( with subversion revision  
2002 as

well)
It seems like based on what Ed Pozharsky wrote in ..its a problem  
with guile

in Ubuntu jaunty (9.04) ..

On my 32 bit , 9.04 installation , the build-it-gtk2-simple script  
chugs

along fine and then declares the following contradictory message

checking for Clipper... yes
Congratulations, you are using Guile
checking for guile... no
configure: error: guile required but not found

Regardless ..I will try Bill Scots or the CCP4 wiki
methodof

separately compiling all the coot dependencies . But though I would
wrote
in to inquire if there was already a simpler fix.

Thanks

Hari


On Fri, May 8, 2009 at 7:35 PM, Paul Emsley >wrote:



hari jayaram wrote:

Hi ..I tried a coot subversion (revision 1994) built-it-simple  
python on

the newest ubuntu 9.04

The build crashes just after it builds guile and ( 16-coot.txt in  
the

build directory ) reads :

checking for Clipper... yes
Congratulations, you are using Guile
checking for guile... no
configure: error: guile required but not found
./build-it-gtk2-simple: line 2742: [: =: unary operator expected
NO need to update libtool
/home/hari/autobuild/ex-charlie_2009-05-08__T20_14_49/coot-0.6-pre-1
make: *** No targets specified and no makefile found.  Stop.

This happens only on the new ubuntu (on a 32 bit 9.04 system) .
I was able to build this revision without any problem on Ubuntu  
8.04 64

bit



Thanks update_libtool is not set sometimes, so using it as in 1994 is
wrong.  I've tweaked the script.

But the problem for you lies above that..

checking for guile... no
configure: error: guile required but not found


Hmm!  what went wrong there..?

I'll try to build from scratch on Jaunty myself.

Cheers,

Paul.

Re: [COOT] ELFCLASS64

[Ed Pozharski]

Didn't help.

It must have something to do with my configuration.  I have no problems
on other machines running Hardy.  

Which executable actually requires this library?  I put "ldd $coot_real"
into the xxx/bin/coot script, and it does list many libraries in xxx/lib
properly.  However, the one in question is not listed (in fact, coot
also complains about canberra-gtk-module, libgiogconf, libgvfsdbus,
libgioremote-volume-monitor, but these are perhaps not critical so it
does not crash).  

This may be irrelevant, but I made the following observations:

- when coot crashes, it says "ERROR: In procedure dynamic-link:"
- when I look in the source, the only place which has these very words
(i.e. dynamic-link) is in scheme/my-readline.scm
- it says (dynamic-link "libguilereadline-v-12")))
- libguilereadline-v-12 is in guile-1.6-libs, not 1.8
- moreover, coot/lib has libguilereadline-v-17, not 12
- there is /usr/lib32/libguilereadline-v-17, but not 12

I tried to remove/reinstall both guile-1.6-libs and guile-1.8-libs, and
it didn't help.

Ed.


On Tue, 2009-05-12 at 00:34 +0100, Paul Emsley wrote:
> Ed Pozharski wrote:
> > After recent upgrade to Ubuntu 9.04, coot binaries that worked fine
> > before started reporting the "ELFCLASS64" error when loading a
> > particular library, namely /usr/lib/libguile-srfi-srfi-1-v-3.so.3.  
> > 
> > I understand that the real root of this problem is my bizarre obsession
> > with installing 64-bit Linux and then being too lazy to compile coot
> > from source and instead trying to use 32-bit coot binaries.  To resolve
> > the ELFCLASS64 issue, I downloaded guile1.8 32-bit debian package from
> > ubuntu repositories and placed libraries into /usr/lib32.  That, of
> > course, didn't help and I had to redirect the symbolic link in /usr/lib
> > to /usr/lib32.  
> 
> 
> OK, try this:
> 
> in your xxx/bin/coot script,
> 
> after the line
> 
> export LD_LIBRARYN32_PATH
> 
> add:
> 
> LTDL_LIBRARY_PATH=$COOT_PREFIX/lib
> export LTDL_LIBRARY_PATH
> 
> 
> Paul.
-- 

Re: [COOT] Graphics problem running Coot with EdUbuntu 8.10

[Shaun Lott]

I'm running this in undergraduate teaching labs containing cheap Dell  
boxes or iMacs, both of which are only a couple of years old. Off-hand  
I don't know what graphics cards the former have, but the latter  
should have nVidia cards. Maybe it's the drivers?


--
Dr J. Shaun Lott
AgResearch Senior Lecturer in Structural Biology
Laboratory of Structural Biology & Maurice Wilkins Centre
School of Biological Sciences
3a Symonds Street
University of Auckland
Private Bag 92019
Auckland 1142
New Zealand

t   : +64 9 3737599 x87074
f   : +64 9 3737416
http://shaunlott.blogspot.com

On 13 May 2009, at 02:36, Ed Pozharski wrote:


It is not a Ubuntu problem.  I have the same issue on my laptop, and
it's because it has Intel onboard graphics chip.  With NVIDIA cards  
(at

least on all the desktops I've seen), coot runs fine when you enable
compiz (of course, I do use proprietary nvidia drivers).

On Tue, 2009-05-12 at 14:34 +1200, Shaun Lott wrote:

Hi Stephen

On the money - thanks!

Running GNOME as the desktop environment, doing exactly as you  
suggest
fixes the problem. GNOME was having other stability issues also,  
which

caused some student frustration.

Alternatively, using Xfce as the desktop environment worked right off
the bat.

I also tried KDE, and if anything it was worse than GNOME, plus I
couldn't find where to disable Compiz.

Hope this helps anyone else who may have struggled with this issue.

cheers

Shaun

--
Dr J. Shaun Lott
AgResearch Senior Lecturer in Structural Biology
Laboratory of Structural Biology & Maurice Wilkins Centre
School of Biological Sciences
3a Symonds Street
University of Auckland
Private Bag 92019
Auckland 1142
New Zealand

t   : +64 9 3737599 x87074
f   : +64 9 3737416
http://shaunlott.blogspot.com

On 11 May 2009, at 17:51, Stephen Graham wrote:


Hi Shaun,

Have you tried turning off compiz?
(System > Preferences > Appearance > Visual Effects: Select 'None')

Cheers,

Stephen

On 11/05/2009, Shaun Lott  wrote:

Hi

Apologies if this problem has been dealt with elsewhere - I scanned
the
archives but couldn't see anything that looked similar.

I'm about to use Coot as part of a graduate teaching exercise.
Version 0.52
starts ok, and can load co-ords and maps, but whenever one clicks,
the
screen gets corrupted - see attached image. You can get a normal
view back
by rotating the molecule, but the whole user experience is a pretty
frustrating one, as it is pretty much impossible to click on
anything. The
fault seems to be hardware and Coot version independent - it
manifests in
0.5.2 and also using
0.6-pre-1-revision-1997-binary-Linux-i686-ubuntu-8.04.2, though  
less

dramatically in the latter - just a grey screen rather than the
corrupted
one. The same thing occurs when using a Dell or an iMac running
Ubuntu
(don't ask...)

So I'm guessing it's a(n) Ubuntu thing. The machine are running the
same
versrion of EdUbuntu 8.10, details as below.

Has anyone else seen this? Does anyone have a fix?

cheers

Shaun


cat /proc/version

Linux version 2.6.27-7-generic (bui...@palmer) (gcc version 4.3.2
(Ubuntu
4.3.2-1ubuntu11) ) #1 SMP Tue Nov 4 19:33:20 UTC 2008






--
Dr Stephen Graham
Division of Structural Biology
Wellcome Trust Centre for Human Genetics
Roosevelt Drive
Oxford OX3 7BN
United Kingdom
Phone: +44 1865 287 549

--

[COOT] Fit protein suggestion/query

[Oliver Clarke]

Hi,

I like the fit protein script - at low resolution, initial rounds of  
fitting and refinement often result in my leucines/isoleucines having  
fairly implausible rotamers, and fit protein is a great way of quickly  
fixing up the worst of these.


However, it doesn't seem to deal so well with residue types where  
there are many almost equally probably rotamers (eg lys, arg), and in  
poor density these often end up with sidechains lodged firmly in  
density that belongs to the neighbouring strand of a beta sheet, for  
example.


Is there any way to script a function that will allow rotamer-fitting  
of specific residue types (eg all except lys, arg and maybe glu and  
gln)?


Cheers,
Oliver Clarke