🌐 Mailman 3 September 2009 - Pythonmac-SIG - python.org

py2app cannot move to target thread error
by Scott Frankel Sept. 21, 2009

Sept. 21, 2009

Hello, I'm troubleshooting a PyQt-PostgreSQL py2app error: "Cannot move to target thread". Note that a test app builds and runs happily. The error only comes up when I add PyQt4.QtSql' to py2app's option includes. eg: This works: OPTIONS = {'argv_emulation': True, 'includes': ['sip', 'PyQt4._qt']} This doesn't: OPTIONS = {'argv_emulation': True, 'includes': ['sip', 'PyQt4._qt', 'PyQt4.QtSql']} Researching the error, I've set DYLD_PRINT_LIBRARIES=1 in my shell and am looking for duplicate instances of Qt libraries. I'm not seeing anything obvious. But I also don't know exactly what to look for. For example, should I be concerned with dyld output running the app or building it? I created my build environment using macports. It looks like the correct libs are being accessed. The last of the dyld output looks like this: dyld: loaded: /opt/local/libexec/qt4-mac/plugins/sqldrivers/ libqsqlpsql.bundle dyld: loaded: /opt/local/lib/postgresql83/libpq.5.dylib dyld: loaded: /opt/local/libexec/qt4-mac/lib/QtSql.framework/Versions/ 4/QtSql dyld: loaded: /opt/local/libexec/qt4-mac/lib/QtCore.framework/Versions/ 4/QtCore dyld: loaded: /opt/local/lib/libz.1.dylib dyld: loaded: /opt/local/lib/libssl.0.9.8.dylib dyld: loaded: /opt/local/lib/libcrypto.0.9.8.dylib QObject::moveToThread: Current thread (0x1d17d0) is not the object's thread (0x1a7820). Cannot move to target thread (0x1a7820) Suggestions? Thanks in advance! Scott

3 9

Building packages under Snow Leopard and Python 2.6.x
by Jerry LeVan Sept. 21, 2009

Sept. 21, 2009

Hi I have the community version of Python 2.6.2 installed on my MacBook Pro running 10.6.1. I am trying to build psycopg2 ( 2.0.12) on my mac and am no having much luck... [mbp:~/python/psycopg2-2.0.12]$ python setup.py build running build running build_py running build_ext building 'psycopg2._psycopg' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 - DPSYCOPG_DEFAULT_PYDATETIME=1 -DPSYCOPG_VERSION="2.0.12 (dt dec ext pq3)" -DPG_VERSION_HEX=0x080401 -DPSYCOPG_EXTENSIONS=1 - DPSYCOPG_NEW_BOOLEAN=1 -DHAVE_PQFREEMEM=1 -DHAVE_PQPROTOCOL3=1 -I/ Library/Frameworks/Python.framework/Versions/2.6/include/python2.6 -I. -I/usr/local/pgsql/include -I/usr/local/pgsql/include/server -c psycopg/psycopgmodule.c -o build/temp.macosx-10.3-fat-2.6/psycopg/ psycopgmodule.o In file included from /Library/Frameworks/Python.framework/Versions/ 2.6/include/python2.6/unicodeobject.h:4, from /Library/Frameworks/Python.framework/Versions/ 2.6/include/python2.6/Python.h:85, from psycopg/psycopgmodule.c:23: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory In file included from /Library/Frameworks/Python.framework/Versions/ 2.6/include/python2.6/unicodeobject.h:4, from /Library/Frameworks/Python.framework/Versions/ 2.6/include/python2.6/Python.h:85, from psycopg/psycopgmodule.c:23: /Developer/SDKs/MacOSX10.4u.sdk/usr/include/stdarg.h:4:25: error: stdarg.h: No such file or directory lipo: can't figure out the architecture type of: /var/folders/5N/ 5N7bzOiYF3ONFPRhfGuq3k+++TI/-Tmp-//ccch66qm.out error: command 'gcc' failed with exit status 1 *************************** It looks like it is trying to build against a very old toolkit ( 10.4)... The error messages are not clear to me.. the stdarg.h file exists in the 10.4u directory and includes the 'standard' stdarg.h I have built a 32 bit i386 only version of postgresql ( 8.4.1) Any suggestions? Jerry

5 4

machine architecture 32/64 with Python 2.6 on Snow Leopard?
by Bill Janssen Sept. 19, 2009

Sept. 19, 2009

I'm running /usr/bin/python on SL, and import platform; print platform.machine() give me i386 But Activity Monitor shows Python as "Intel (64-bit)". Is this a bug in platform.machine(), or am I misunderstanding what i386 means? "platform.architecture()" returns ('64bit', ''). Bill

4 6

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 77, Issue 16
by Edward Hartley Sept. 19, 2009

Sept. 19, 2009

On 14 Sep 2009, at 16:05, pythonmac-sig-request(a)python.org wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/pythonmac-sig > or, via email, send a message with subject or body 'help' to > pythonmac-sig-request(a)python.org > > You can reach the person managing the list at > pythonmac-sig-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Pythonmac-SIG digest..." > Today's Topics: > > 1. Re: Pythonmac-SIG Digest, Vol 77, Issue 15 (Geert Dekkers) > 2. Re: Pythonmac-SIG Digest, Vol 77, Issue 15 (Geert Dekkers) > > From: Geert Dekkers <geert(a)nznl.com> > Date: 14 September 2009 15:44:06 BST > To: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 77, Issue 15 > > > Thanks David. As you suggested, I did a "file" on a python > executable, and found that while you are quite correct that python > is compiled a 2 way binary on a client 10.5, it's already a 4 way > binary on the new xserve I have running 10.5 even though it's > version 2.5. I also discovered that pyobjc will not automatically > build as a 4 way bin against a 4 way build of python, and if you > force it to, (by re-issuing a gcc command adding arch flags for 64 > bit ppc and intel) it will complain about a missing architecture in > *.o file. > Mostly and I'm working from memory here to make PIL work effectively on 2.0 Python forward you need both numeric and IIRC ImageMagick and Jpeglib. This has gone through several transitions s since I was actively using it. It is worth installing and works very well particularly since you can get the PIL image in and out of numeric nicely. Again from memory you need the third party jpeglib and not the OS X installed one. HTH Ed Hartley > I'll try doing a python 2.6 build next, and go from there. > > Geert > > > On 14/09/2009, at 12:00 PM, pythonmac-sig-request(a)python.org wrote: > > > From: David Warde-Farley <dwf(a)cs.toronto.edu> > Date: 14 September 2009 9:48:02 AM > To: Pythonmac-Sig 3 <pythonmac-sig(a)python.org> > Subject: > > > On 13-Sep-09, at 10:58 AM, Geert Dekkers wrote: > >> The problem is of course that I need to coax PyObjC to be run by 64 >> bit Apache. I read about the ability for PyObjC to run in 64-bit >> mode athttp://pyobjc.sourceforge.net/documentation/pyobjc-core/news.html >> . I don't know where to find out if my python is built with the >> required MACOSX_DEPLOYMENT_TARGET=10.5, but I would think so (as >> I'm running 10.5.8). (And you must realise I'm no hard-core >> programmer -- I learn as I go -- make heaps of mistakes doing so) >> >> I did try a few tricks to get pyobjc to build as full fat binary >> (that is -arch ppc -arch i386 -arch ppc64 -arch x86_64) but so far >> no joy. > > type="cite">(Actually one of the results was quite discerning: an > example "ld warning: in build/temp.macosx-10.5-i386-2.5/Modules/ > _sortandmap.o, missing required architecture ppc64 in file >> ld warning: in build/temp.macosx-10.5-i386-2.5/Modules/ >> _sortandmap.o, missing required architecture x86_64 in file") > > Neither the Python 2.5 shipped with Leopard nor the Python 2.5 at > Python.org are 64-bit builds/include 64 bit support. Try running > 'file' on the python executable, you'll see only i386 and ppc. > > You'll have to build a Python framework build from source as a 4-way > universal (I'd recommend 2.6, as there is a script in the > distribution for doing this on the Mac, and it might not even be > possible on 2.5). Then you'll be able to build 4-way PyObjC (in > fact, it should build that way automatically I think). > >> And I'm wondering if this is at all necessary. Because -- why can >> Apache run PIL? ?? -- th full fat, but you can indeed do "import >> Image" >> >> dekkers-2:~ geert$ file /Library/Python/2.5/site-packages/PIL/ >> _imaging.so >> /Library/Python/2.5/site-packages/PIL/_imaging.so: Mach-O universal >> binary with 2 architectures >> /Library/Python/2.5/site-packages/PIL/_imaging.so (for architecture >> i386): Mach-O bundle i386 >> /Library/Python/2.5/site-packages/PIL/_imaging.so (for architecture >> ppc7400): Mach-O bundle ppc >> >> But if you do "import _imaging", Apache gives you: "Could not >> import ccnet.views. Error was: dlopen(/Library/Python/2.5/site- >> packages/PIL/_imaging.so, 2): no suitable image fo und. Did 5/site- >> packages/PIL/_imaging.so: no matching architecture in universal >> wrapper" > > > My best guess (as I've never poked around in the guts of PIL) is > that there is a pure Python version that is slow-as-molasses and > then a sped up C version which is used if possible (_imaging.so). > PIL invoked from Apache will thus probably use the slow-as-molasses > version as the import of _imaging will silently fail somewhere in > the Python code but be caught by an exception handler. > > David > > > > > > From: Geert Dekkers <geert(a)nznl.com> > Date: 14 September 2009 16:05:13 BST > To: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 77, Issue 15 > > > UPDATE: Sorry, I was wrong. Client and server are equal in this > respect. Look: > > geert-dekkerss-macbook-pro:~ geert$ file /System/Library/Frameworks/ > Python.framework/Versions/2.5/Python > /System/Library/Frameworks/Python.framework/Versions/2.5/Python: > Mach-O universal binary with 4 architectures > /System/Library/Frameworks/Python.framework/Versions/2.5/Python (for > architecture ppc7400): Mach-O dynamically linked shared library ppc > /System/Library/Frameworks/Python.framework/Versions/2.5/Python (for > architecture ppc64): Mach-O 64-bit dynamically linked shared library > ppc64 > /System/Library/Frameworks/Python.framework/Versions/2.5/Python (for > architecture i386): Mach-O dynamically linked shared library i386 > /System/Library/Frameworks/Python.framework/Versions/2.5/Python (for > architecture x86_64): Mach-O 64-bit dynamically linked shared > library x86_64 > geert-dekkerss-macbook-pro:~ geert$ file /System/Library/Frameworks/ > Python.framework/Versions/2.5/bin/python2.5 > /System/Library/Frameworks/Python.framework/Versions/2.5/bin/ > python2.5: Mach-O universal binary with 2 architectures > /System/Library/Frameworks/Python.framework/Versions/2.5/bin/ > python2.5 (for architecture ppc7400): Mach-O executable ppc > /System/Library/Frameworks/Python.framework/Versions/2.5/bin/ > python2.5 (for architecture i386): Mach-O executable i386 > geert-dekkerss-macbook-pro:~ geert$ file /System/Library/Frameworks/ > Pyth on.frame hon > /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python: > Mach-O universal binary with 2 architectures > /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python > (for architecture ppc7400): Mach-O executable ppc > /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python > (for architecture i386): Mach-O executable i386 > > Python -- with a capital P -- is 4 way, lowercase python 2 way. > Would Python contain classes, called by python or python2.5??? > > Geert > > > On 14/09/2009, at 12:00 PM, pythonmac-sig-request(a)python.org wrote: > >> >> From: David Warde-Farley <dwf(a)cs.toronto.edu> >> Date: 14 September 2009 9:48:02 AM >> To: pythonmac-sig(a)python.org> >> Subject: Re: [Pythonmac-SIG] django webapp using CoreGraphics >> complains about "wrong architecture" >> >> >> On 13-Sep-09, at 10:58 AM, Geert Dekkers wrote: >> >>> The problem is of course that I need to coax PyObjC to be run by >>> 64 bit Apache. I read about the ability for PyObjC to run in 64- >>> bit mode athttp://pyobjc.sourceforge.net/documentation/pyobjc-core/news.html >>> . I don't know where to find out if my python is built with the >>> required MACOSX_DEPLOYMENT_TARGET=10.5 , but I nning 10.5.8). (And >>> you must realise I'm no hard-core programmer -- I learn as I go -- >>> make heaps of mistakes doing so) >>> >>> I did try a few tricks to get pyobjc to build as full fat binary >>> (that is -arch ppc -arch i386 -arch ppc64 -arch x86_64) but so far >>> no joy. >>> >>> (Actually one of the results was quite discerning: an example "ld >>> warning: in build/temp.macosx-10.5-i386-2.5/Modules/_sortandmap.o, >>> missing required architecture ppc64 in file >>> ld warning: in build/temp.macosx-10.5-i386-2.5/Modules/ >>> _sortandmap.o, missing required architecture x86_64 in file") >> >> Neither the Python 2.5 shipped with Leopard nor the Python 2.5 at >> Python.org are 64-bit builds/include 64 bit support. Try running >> 'file' on the python executable, you'll see only i386 and ppc. >> >> You'll have t o build from source as a 4-way universal (I'd >> recommend 2.6, as there is a script in the distribution for doing >> this on the Mac, and it might not even be possible on 2.5). Then >> you'll be able to build 4-way PyObjC (in fact, it should build that >> way automatically I think). >> >>> And I'm wondering if this is at all necessary. Because -- why can >>> Apache run PIL??? -- the .so files are also not full fat, but you >>> can indeed do "import Image" >>> >>> dekkers-2:~ geert$ file /Library/Python/2.5/site-packages/PIL/ >>> _imaging.so >>> /Library/Python/2.5/site-packages/PIL/_imaging.so: Mach-O >>> universal binary with 2 architectures >>> /Library/Python/2.5/site-packages/PIL/_imaging.so (for >>> architecture i386): Mach-O bundle i386 >>> /Libr ary/Pyth _imaging.so (for architecture ppc7400): Mach-O >>> bundle ppc >>> >>> But if you do "import _imaging", Apache gives you: "Could not >>> import ccnet.views. Error was: dlopen(/Library/Python/2.5/site- >>> packages/PIL/_imaging.so, 2): no suitable image found. Did find: / >>> Library/Python/2.5/site-packages/PIL/_imaging.so: no matching >>> architecture in universal wrapper" >> >> >> My best guess (as I've never poked around in the guts of PIL) is >> that there is a pure Python version that is slow-as-molasses and >> then a sped up C version which is used if possible (_imaging.so). >> PIL invoked from Apache will thus probably use the slow-as-molasses >> version as the import of _imaging will silently fail somewhere in >> the Python code but be caught by an exception handler. >> >> David >> > > >

1 0

py2app sip recipe and Qt plugins
by Marc-Antoine Parent Sept. 19, 2009

Sept. 19, 2009

Good day! I was trying my hand at wrapping a PyQt application, and I stumbled on the plugin issue that seems to have plagued many here, where the plugins load another copy of the Qt frameworks, indicated as such: On Mac OS X, you might be loading two sets of Qt binaries into the same process. Check that all plugins are compiled against the right Qt binaries. Export DYLD_PRINT_LIBRARIES=1 and check that only one set of binaries are being loaded. I looked a bit at how to fix this, and here is what worked for me. I have not yet written code to automate this process; but this description may be useful to people willing to fix executables by hand. a) copy the plugin directory from /Developer/Applications/Qt/plugins to dist/<application.app>/Contents/plugins b) Create a file dist/<application.app>/Contents/Resources/qt.conf with contents as follows: [Paths] qt_plugpath=plugins The path is relative to Contents. Another path could be chosen, that could be more congenial to py2app. c) Adjust the paths of the plugins with install_name_tool. Eg, from the shell: find dist/<application.app>/Contents/plugins -type f -exec install_name_tool -change QtGui.framework/Versions/4/QtGui @executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui {} ';' find dist/<application.app>/Contents/plugins -type f -exec install_name_tool -change QtGui.framework/Versions/4/QtCore @executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore {} ';' (and so on if you need QtXml etc.) Cheers, Marc-Antoine Parent

2 1

Re: [Pythonmac-SIG] Appscript and Snow Leopard
by has Sept. 18, 2009

Sept. 18, 2009

Norman Gray wrote: >> Did you force the reinstall? It appears so, since it reached the >> 10.6 appscript install. > > How do you do that? My own problem here [1] is that I can't work > out how to make appscript play with python 2.6 (or 10.6). If the problem is that easy_install is installing appscript for 2.5, not 2.6, try specifying the exact version of easy_install to use, e.g.: easy_install-2.6 appscript HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net

5 13

Re: [Pythonmac-SIG] django webapp using CoreGraphics complains about "wrong architecture"
by Geert Dekkers Sept. 17, 2009

Sept. 17, 2009

Would this then mean that PIL would also fail complaining about "wrong architecture" when running under 64-bit Apache? Geert > > > From: VanL <van.lindberg(a)gmail.com> > Date: 16 September 2009 7:54:39 PM > To: pythonmac-sig(a)python.org > Subject: Re: [Pythonmac-SIG] django webapp using CoreGraphics > complains about "wrong architecture" > > > David Warde-Farley wrote: > >> My best guess (as I've never poked around in the guts of PIL) is >> that there is a pure Python version that is slow-as-molasses and >> then a sped up C version which is used if possible (_imaging.so). >> PIL invoked from Apache will thus probably use the slow-as-molasses >> version as the import of _imaging will silently fail somewhere in >> the Python code but be caught by an exception handler. > > PIL is lazy. It will give you back an image object that will be > filled in when you look inside it. Thus, the pure Python create > image works, but the lazy hook bombs when you try to actually do > something with the image. > > Thanks, > > Van > >

2 1

Fwd: size of py2app app
by Charles Hartman Sept. 17, 2009

Sept. 17, 2009

Here was Sudhakar's comment (thanks), but it doesn't seem to help. The Python version doesn't change (2.6), nor the version of wxPython. All that changes, as far as I can see, is the very small edits I'm making in the code. For a while I thought trashing the old .app and the dist folder forced the smaller file-size, but now that doesn't seem to work either. What am I missing about py2app? > From: sudhakar s <ssquery(a)gmail.com> > Date: September 13, 2009 2:19:30 AM EDT > To: Charles Hartman <charles.hartman(a)conncoll.edu> > Subject: Re: [Pythonmac-SIG] size of py2app app > > This happens when you are trying to make a standalone > application(file size is less) and distributable application, ie is > run on other system then file size is more. > > i want to make sure whether ur app running on another sys and r u > using PMW module....if so there is little problem in converting > py2app. > > sudhakar. > > On Sat, Sep 12, 2009 at 12:30 AM, Charles Hartman <charles.hartman(a)conncoll.edu > > wrote: > My app changes just a little here and there between builds, and my > setup.py doesn't change at all. Sometimes the app (using "python > setup.py py2app --strip --iconfile MyApp.icns") comes out to about > 47 MB, and sometimes it comes out to I have an app that sometimes > comes out to about 95 MB. I can't pin down anything that makes the > difference. I know "--strip" is the default now, but putting it in > or leaving it out seems to have no effect. What am I missing? I'm > using py2app-0.4.2-py2.6.egg. > > Charles Hartman > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG(a)python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > -- > With Regards, > S Sudhakar.

3 3

django webapp using CoreGraphics complains about "wrong architecture"
by Geert Dekkers Sept. 17, 2009

Sept. 17, 2009

Hi there, I have a couple of webapps in django designed to run on xserves. When I started the apps last year, I found and used the CoreGraphics bindings for python as described at http://developer.apple.com/graphicsimaging/pythonandquartz.html and some other places. Actually, this was the reason I took up python in the first place (which was most certainly no mistake!). But -- as the xserve runs Apache as Intel64, I had to recompile stuff for Apache. Not a problem. The CoreGraphics bindings are used as a standalone cli app within my webapp, so no problem with those either, as long as Apache doesn't want to run them. A couple of things have changed in the last year, though. For starters, it seems the CoreGraphics bindings are going nowhere, PyObjC seems to be the way forward. A rather steep learning curve, but so be it. And then I have now found need for Apache to use CoreGraphics. I know I have alternatives (ReportLab for PDF's PIL for bitmaps) but my stance is that my platform of choice has perfectly good support for these formats, (and does blazingly fast conversions to boot!) so why go looking for others? The problem is of course that I need to coax PyObjC to be run by 64 bit Apache. I read about the ability for PyObjC to run in 64-bit mode at http://pyobjc.sourceforge.net/documentation/pyobjc-core/news.html. I don't know where to find out if my python is built with the required MACOSX_DEPLOYMENT_TARGET=10.5, but I would think so (as I'm running 10.5.8). (And you must realise I'm no hard-core programmer -- I learn as I go -- make heaps of mistakes doing so) I did try a few tricks to get pyobjc to build as full fat binary (that is -arch ppc -arch i386 -arch ppc64 -arch x86_64) but so far no joy. (Actually one of the results was quite discerning: an example "ld warning: in build/temp.macosx-10.5-i386-2.5/Modules/_sortandmap.o, missing required architecture ppc64 in file ld warning: in build/temp.macosx-10.5-i386-2.5/Modules/_sortandmap.o, missing required architecture x86_64 in file") And I'm wondering if this is at all necessary. Because -- why can Apache run PIL??? -- the .so files are also not full fat, but you can indeed do "import Image" dekkers-2:~ geert$ file /Library/Python/2.5/site-packages/PIL/ _imaging.so /Library/Python/2.5/site-packages/PIL/_imaging.so: Mach-O universal binary with 2 architectures /Library/Python/2.5/site-packages/PIL/_imaging.so (for architecture i386): Mach-O bundle i386 /Library/Python/2.5/site-packages/PIL/_imaging.so (for architecture ppc7400): Mach-O bundle ppc But if you do "import _imaging", Apache gives you: "Could not import ccnet.views. Error was: dlopen(/Library/Python/2.5/site-packages/PIL/ _imaging.so, 2): no suitable image found. Did find: /Library/Python/ 2.5/site-packages/PIL/_imaging.so: no matching architecture in universal wrapper" Does anyone have any experience using cocoa libs in a webapp like I want to do? I really would like to get this going. Tips, tricks & Enlightment would be very welcome! Geert

4 3

resuming python job
by DavidW Sept. 17, 2009

Sept. 17, 2009

Hi All, When I try to resume a stopped instantiation of Python 2.5.2 (r252:60911, Feb 22 2008, 07:57:53) on intel OSX 10.5.8 using eithr % or fg, the job aborts without any [error etc] message. Is this a known condition? Any solution? thanks, David ______________________________________________________ Dr David Worrall. - Experimental Polymedia: worrall.avatar.com.au - Sonification: www.sonifiction.com.au - Education for Financial Independence: www.mindthemarkets.com.au

2 1