mailRe: gui vs wx python


Others Months | Index by Date | Thread Index
>>   [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Header


Content

Posted by Edward d'Auvergne on June 06, 2011 - 16:44:
Hi,

This looks fine.  The first argument is a wx object (static text) and
adding it to the grid sizer should be fine.  This must be a problem
with wx.  You could try to remove that entire loop with the failing
code, and see if the GUI can launch, or whether this problem is more
widespread.

Regards,

Edward



On 6 June 2011 16:33, Sébastien Morin <sebastien.morin.1@xxxxxxxxx> wrote:
Hi,

Here's the output with the print statement:

====
./relax -g
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050bd490> >
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050c4c10> >
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050c7980> >
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050ca520> >
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050cd2d0> >
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050cfdc0> >
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050d27c0> >
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050d51e0> >
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050d7b20> >
<wx._controls.StaticText; proxy of <Swig Object of type 'wxStaticText *' at
0x1050da640> >
Traceback (most recent call last):
...
====

Does this turn some lights on ?


Séb  :)


On 11-06-06 4:25 PM, Edward d'Auvergne wrote:

Hi,

That error looks like it's a problem with wxPython, although maybe
not.  wxPython should catch this if the args are wrong.  Michael,
could it be the call:

File
"/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/gui/components/spectrum.py",
line 152, in __init__
    sizer_grid.Add(self.field_rx_list[-1], 0, wx.ADJUST_MINSIZE, 0)

Seb, if you add the line "print self.field_rx_list[-1]" prior to this,
what do you see?

Cheers,

Edward



On 6 June 2011 15:31, Sébastien Morin<sebastien.morin.1@xxxxxxxxx>  wrote:

Hi Ed,

Thanks for your help !

I checked the wxPython website more carefully and found something quite
interesting:

===============
Mac OSX Binaries
The wxPython binaries for OSX are mountable disk images. Simply double
click
to mount the image and then run the installer application in the image.
Be
sure to download the image that matches the version of Python that you
want
to use it with.

The files with "carbon" in the name use the Carbon API for implementing
the
GUI, are compatible with PPC and i386 machines are will work on OSX 10.4
and
onwards. Since they use the Carbon API they are limited to running in
32-bit
mode.

The file with "cocoa" in the name use the Cocoa API for implementing the
GUI, requires at least OSX 10.5, and supports either 32-bit or 64-bit
architectures. If you would like to have both the Carbon and Cocoa
versions
installed you will need to do something like install the Carbon build for
Python 2.6 and install the Cocoa build for Python 2.7.

wxPython2.9-osx-carbon-py2.5
wxPython2.9-osx-carbon-py2.6
wxPython2.9-osx-carbon-py2.7
wxPython2.9-osx-cocoa-py2.7
===============

So, I installed Python-2.7.1 and wxPython-2.9 using Cocoa (64-bit
compatible). Everything was smooth and wx could be import in
python-2.7.1.
Of course, for relax to be happy, I also had to install numpy for
python-2.7.1. Numpy was easy using successively "git clone
git://github.com/numpy/numpy.git numpy", "python setup.py build", and
"python setup.py install".

For scipy, manual installation did not work because of a problem in the
"umfpack" module. However, when removing the module (by commenting out
the
line "" in ""), the program compiled without problem. However, as for the
compiled package using Mac installer, there was a 32/64-bit problem with
"cephes.so" when starting relax. Since scipy is not a strict dependence
for
relax (i.e. it is only needed for the frame order theory analysis), I
decided to go on without (after more than an hour struggling).

...

Then, I tried starting the gui..! The splash screen appeared (!), but it
then crashed with the following error:

=====
$  ./relax -g
Traceback (most recent call last):
 File "./relax", line 381, in<module>
   Relax()
 File "./relax", line 127, in __init__
   app = gui.App(script=self.script_file)
 File

"/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/gui/__init__.py",
line 84, in __init__
   super(App, self).__init__(redirect=redirect, filename=filename,
useBestVisual=useBestVisual, clearSigInt=clearSigInt)
 File

"/usr/local/lib/wxPython-2.9.1.1/lib/python2.7/site-packages/wx-2.9.1-osx_cocoa/wx/_core.py",
line 8470, in __init__
   self._BootstrapApp()
 File

"/usr/local/lib/wxPython-2.9.1.1/lib/python2.7/site-packages/wx-2.9.1-osx_cocoa/wx/_core.py",
line 8035, in _BootstrapApp
   return _core_.PyApp__BootstrapApp(*args, **kwargs)
 File

"/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/gui/__init__.py",
line 94, in OnInit
   main = Main(parent=None, id=-1, title="", script=self.script)
 File

"/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/gui/relax_gui.py",
line 121, in __init__
   self.build_main_window()
 File

"/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/gui/relax_gui.py",
line 244, in build_main_window
   self.analysis_frames[self.hardcoded_index_r1_3] = Auto_r1(self,
self.notebook_frq_3, hardcoded_index=self.r1_index[2])
 File

"/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/gui/analyses/auto_rx_base.py",
line 82, in __init__
   main_box = self.build_main_box()
 File

"/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/gui/analyses/auto_rx_base.py",
line 370, in build_main_box
   right_box = self.build_right_box()
 File

"/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/gui/analyses/auto_rx_base.py",
line 406, in build_right_box
   self.peak_intensity = Peak_intensity(gui=self.gui, parent=self.parent,
data=self.data, label=self.label, box=box)
 File

"/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/gui/components/spectrum.py",
line 152, in __init__
   sizer_grid.Add(self.field_rx_list[-1], 0, wx.ADJUST_MINSIZE, 0)
 File

"/usr/local/lib/wxPython-2.9.1.1/lib/python2.7/site-packages/wx-2.9.1-osx_cocoa/wx/_core.py",
line 14035, in Add
   return _core_.Sizer_Add(*args, **kwargs)
wx._core.PyAssertionError: C++ assertion "Assert failure" failed at
/BUILD/wxPython-src-2.9.1.1/src/common/sizer.cpp(1369) in DoInsert(): too
many items (21>  2*10) in grid sizer (maybe you should omit the number of
either rows or columns?)
=====

Is this a bug in relax with how it deals with grid sizer, or is it a
problem
with wxPython ???
Any idea how I can solve this issue ??

...

Finally, you proposed that the Mac people should maybe get a relax
package
which has everything bundled together. This would be great, but I am not
sure if this is necessary... However, maybe more information on the steps
to
get the system working properly for relax would be good...

...

Thanks a lot again !!!!!!!!!!!!

Cheers,


Séb  :)



On 11-05-16 10:44 AM, Edward d'Auvergne wrote:

Hi,

Sorry for not responding earlier.  I would not worry about the 32-bit
vs. 64-bit issues.  This appears to simply be a badly packaged
wxPython file for 64-bit Mac OS X.  Could you try the source wxPython
package and see if you can compile it?  You could possible try older
version of wxPython from here
http://sourceforge.net/projects/wxpython/files/wxPython/ as well to
see if it is a version issue.  The real issue is within wxPython and
not anything else.  I'm starting to wonder if the Mac OS X people need
a relax package which has everything bundled together (python,
wxPython, minfx (http://gna.org/projects/minfx/), bmrblib
(http://gna.org/projects/bmrblib/), python-devel, scipy, scientific,
etc.).  This would be a huge effort though and would need to be
automated via scripts to build the package.

Regards,

Edward



On 25 April 2011 15:18, Sébastien Morin<sebastien.morin.1@xxxxxxxxx>
 wrote:

Hi,

Instead of switching the system python installation to its 32-bit
version
using "export VERSIONER_PYTHON_PREFER_32_BIT=yes", as stated before, I
manually switched to using 32-bit python (2.6.6), numpy (1.5.1) and
scipy
(0.9.0) from fink (instead of 64-bit python 2.6.1, numpy 2.0.0, and
scipy
0.10.0 directly under Mac OS X). As relax uses the "/usr/bin/env
python"
in
order to get the python path (header of executable file "relax"), I had
to
manually change it to "/sw/bin/python2.6" (the fink path for python-2.6
binary) to do so.

The unit tests all passed without the warnings discussed before (post
at
https://mail.gna.org/public/relax-devel/2011-04/msg00050.html ;
Message-id:
<4DB419A4.1030201@xxxxxxxxx>). The warnings were also absent from the
system
tests, although 9 errors arose because of the unavailability of the C
modules:

====
RelaxError: RelaxError: Relaxation curve fitting is not available.  Try
compiling the C modules on your platform.
====

The C modules, however, compiled without error using scons-1.2.0-2
(also
from fink). However, when starting the relax prompt, the following
error
arose:

====
ImportError:


dlopen(/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/maths_fns/relax_fit.so,
2): no suitable image found.  Did find:



 
/Users/semor/Documents/pse-4/collaborations/relax/relax-1.3/maths_fns/relax_fit.so:
mach-o, but wrong architecture
Relaxation curve fitting is unavailable, try compiling the C modules.
====

It is as if, although python is switched to the 32-bit version from
fink,
scons still compiles the executables for the 64-bit Mac OS X system...
Indeed, the command file yields the following output:

====
./maths_fns/relax_fit.so: Mach-O 64-bit bundle x86_64
./maths_fns/c_chi2.os:      Mach-O 64-bit object x86_64
./maths_fns/exponential.os: Mach-O 64-bit object x86_64
./maths_fns/relax_fit.os:   Mach-O 64-bit object x86_64
====

Moreover, in addition to the C modules not being compiled properly, it
turns
out that fink does not allow the installation of wxPython. Hence, I had
to
use the module installed for the system 64-bit python. In 32-bit
python,
this module loaded without error. However, when starting the gui
("relax
-g", the following error arose:

====
This program needs access to the screen.
Please run with 'pythonw', not 'python', and only when you are logged
in on the main display of your Mac.
====

Apparently, pythonw is present for the system (which is, unfortunately,
64-bit, thus incompatible to wxPython), but not present with the fink
installation (which is 32-bit, but since lacks pythonw, can't have
access
to
the graphical interface)...

This situaiton is becoming more and more complicated...
Maybe a simpler fix would be to find  simple way to really use a 32-bit
version of the system python installation...
Any idea how to solve this ?


Séb  :)



On 11-04-25 10:38 AM, Sébastien Morin wrote:

Hi,

In order to test the gui by manually changing to 32-bit python, I
typed
the following command:

     export VERSIONER_PYTHON_PREFER_32_BIT=yes

Python was then working in 32-bit mode, which allowed the import of wx
within python, hence allowing the dependency check for wx to pass and
the launch of the gui.

However, I then got the following error:

====
ImportError:



dlopen(/Library/Python/2.6/site-packages/scipy-0.10.0.dev_20110325-py2.6-macosx-10.6-universal.egg/scipy/special/_cephes.so,
2): Symbol not found: _aswfa_
   Referenced from:



/Library/Python/2.6/site-packages/scipy-0.10.0.dev_20110325-py2.6-macosx-10.6-universal.egg/scipy/special/_cephes.so
   Expected in: flat namespace
  in



/Library/Python/2.6/site-packages/scipy-0.10.0.dev_20110325-py2.6-macosx-10.6-universal.egg/scipy/special/_cephes.so
====

Testing further, it turns out that the relax prompt yields the same
error, similarly to the relax test-suite (i.e. the following commands
all yield the same error: "relax", "relax -g", "relax -u", "relax -s",
"relax -t", "relax -h", etc).

My scipy version is 0.10.0.dev (running under python 6.2.1, now in
32-bit mode). As reported in a recent post at
https://mail.gna.org/public/relax-devel/2011-04/msg00050.html
(Message-id:<4DB419A4.1030201@xxxxxxxxx>), testing scipy yielded some
errors and failures which could be related to the current problem (or
not).

Any idea what this could be a problem with running 32-bit python under
Mac OS X, or a problem specific to relax ???

Anyway, it turns out that simply switching from 64-bit to 32-bit
python
under Mac OS X does not allow the use of the gui...

Thanks a lot !!!!!!


Séb  :)



On 11-04-24 9:29 PM, Sébastien Morin wrote:

Hi,

I just installed wxPython on my Mac running OS X in order to be able
to
run the relax gui.

I installed "wxPython2.8-osx-unicode-py2.6" from
"http://www.wxpython.org/download.php#stable";.

When trying to start the gui, I get the following message:

      ""RelaxError: To use the GUI, the wx python module must be
installed."

When I try to import wx withon python, the module seems there, but
not
working, as I get the following error:

====
import wx
Traceback (most recent call last):
    File "<stdin>", line 1, in<module>
    File



"//usr/local/lib/wxPython-unicode-2.8.12.0/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/__init__.py",
line 45, in<module>
      from wx._core import *
    File



"//usr/local/lib/wxPython-unicode-2.8.12.0/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_core.py",
line 4, in<module>
      import _core_
ImportError:



/usr/local/lib/wxPython-unicode-2.8.12.0/lib/python2.6/site-packages/wx-2.8-mac-unicode/wx/_core_.so:
no appropriate 64-bit architecture (see "man python" for running in
32-bit mode)
====

On the wx python website, it is said that "These binaries should work
on
all versions of OSX from 10.3.9 onwards on either PPC or i386
architectures. Since they use the Carbon API they are limited to
running
in 32-bit mode."

However, my machine, a Macbook pro, is 64 bit and python runs in 64
bits
by default. I found that python can be set to use 32 or 64 bits.
However, I am afraid that these settings are system-wide. Would there
be
a way that relax tells the system to run python in 32 bit mode, maybe
only when the gui is invoked ?

Maybe this is too much asked... However, if it is simple, I guess it
would simplify the life of many users with recent Mac computers...

Thanks a lot !


Séb  :)

--
Sébastien Morin, Ph.D.
Postdoctoral fellow
S. Grzesiek NMR Laboratory
Biozentrum, Universität Basel
Basel, Switzerland


_______________________________________________
relax (http://nmr-relax.com)

This is the relax-devel mailing list
relax-devel@xxxxxxx

To unsubscribe from this list, get a password
reminder, or change your subscription options,
visit the list information page at
https://mail.gna.org/listinfo/relax-devel

--
Sébastien Morin, Ph.D.
Postdoctoral Fellow, S. Grzesiek NMR Laboratory
Department of Structural Biology
Biozentrum, Universität Basel
Klingelbergstrasse 70
4056 Basel
Switzerland



--
Sébastien Morin, Ph.D.
Postdoctoral Fellow, S. Grzesiek NMR Laboratory
Department of Structural Biology
Biozentrum, Universität Basel
Klingelbergstrasse 70
4056 Basel
Switzerland





Related Messages


Powered by MHonArc, Updated Mon Jun 06 17:20:14 2011