Points well taken about the perils of 64-bit / 32-bit compatibility.
Thanks !!!
On Thu, Dec 9, 2010 at 2:05 PM, Melissa Rice <[email protected]
<mailto:[email protected]>> wrote:
I agree with Chris, this certainly looks like an architecture clash.
The same sort of thing happens on Windows (complains about the .dll
instead of the .so)
when you are attempting 64-bit package with 32-bit python or vice
versa.
Another symptom of this architecture clash (on Windows) is when the
installer can't
find python in the registry. If you install anyway, by pointing the
installer to
the desired python installation, then you next get the message (upon
import) that
it can't find the dll or load the dll, etc.
It has been my experience that you have to really closely follow the
explicit
(and implicit!) compatibility instructions for python packages and
bindings.
I have about six installations on my machine for this reason (32-bit
Py2.5,
64-bit Py2.7, 32-bit Py2.7, 32-bit Py3.1, etc) because package x.1.5
is only
compatible with external tool y.8.3 and then you have to choose the
version of
the package which is designed to work with your python version (or
install a new
python version) and they also all have to be the same architecture
(32-bit or 64-bit).
AMD vs Intel may be a problem also, though some packages labeled AMD
have worked
on intel as long as everything is 64-bit. Some packages are labeled
AMD but if you
read the fine-print it says they work on Intel as well.
So, my new policy is never install 64-bit python unless I need
really large files
(4GB). I'm not sure if there are other reasons to desire 64-bit
python besides the
larger address space, but what I have found is there are lots of
problems with packages
not being 64-bit compatible so much safer to go with the 32-bit
solution for most
purposes. Originally I was using 64-bit packages just because I had
a 64-bit architecture
but now I see this is not as sensible as I originally assumed.
Good luck!
Best regards,
Melissa
-----
Dr. Melissa Rice, PhD
Full Moon Technical Solutions, LLC
14202 60th Ave, NW
Stanwood, WA 98292-4808
email: mailto:[email protected]
phone: 360-654-0709
cell: 425-923-7713
Thursday, December 9, 2010, 11:40:06 AM, Richard Fuhr
<[email protected] <mailto:[email protected]>> wrote:
After installing the Mac distribution of wx for Python 2.7, which
is called wxPython2.8-osx-unicode-2.8.11.0-universal-py2.7.dmg
I got the following, upon launching python 2.7.1 and importing wx.
Instead of pursuing the problem in any detail, I just downloaded and
installed
wx for Python 2.6 and it seems to work fine.
But, for reference, here is the transcript of my Python 2.7 session.
Richard-Fuhrs-iMac:~ richardfuhr$ python
Python 2.7.1 (r271:86882M, Nov 30 2010, 10:35:34)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
> >> import wx
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File
"/usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.7/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.11.0/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core.py",
line 4, in <module>
import _core_
ImportError:
dlopen(/usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so,
2): no suitable image found. Did find:
/usr/local/lib/wxPython-unicode-2.8.11.0/lib/python2.7/site-packages/wx-2.8-mac-unicode/wx/_core_.so:
no matching architecture in universal wrapper
On Thu, Dec 9, 2010 at 11:19 AM, Christopher
Barker <[email protected] <mailto:[email protected]>> wrote:
On 12/9/10 11:02 AM, Richard Fuhr wrote:
that enabled the
user to explore
some of the properties of Bezier and spline curves.
OK -- so you really do need "real" Bezier cublic splines.
Now it is time to implement the graphics and a GUI, and I am looking for
the following:
* APIs that draw cubic Bezier curves ( or several cubic Bezier
curves joined together ) ideally without requiring the programmer
to implement a linear approximation of the curves (and it looks
like wxPython is quite suitable)
yup -- wx.GraphicsContext should do that fine.
* GUI functionality that responds to mouse down, mouse moved, and
mouse up events, so that the user can drag around control points (
represented by circles on the canvas ) and thus modify the curve.
None of that interaction comes out of the box with wx. My
FloatCanvas would make that pretty easy, once you added the Spline.
See the demos that come with the source code in SVN, in particular
PolyEditor.py
FloatCanvas2 might make it even easier, but I'm not very familiar
with that one -- you might try out its demo -- there's a lot of
stuff in there. Also -- at one point, it didn't render right on OS-X
-- I'm not sure where that's at. A question to the FloatCanvas list
should get you an answer.
I have just started to explore wxPython today, so this is all still
new. I had trouble getting the Python 2.7 wx to work,
What were your troubles? I haven't tried 2.7 yet, but it *should*
work. Have you posted to the wxyPython list with a questions/bug report?
but have
downloaded and installed the Python 2.6 version, which is working.
which is fine anyway.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
[email protected] <mailto:[email protected]>
