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]> 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] <[email protected]> > phone: 360-654-0709 > cell: 425-923-7713 > > > > Thursday, December 9, 2010, 11:40:06 AM, Richard Fuhr < > [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] > > 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] >
