Re: [Pythonmac-SIG] django webapp using CoreGraphics complains about wrong architecture
Would this then mean that PIL would also fail complaining about wrong architecture when running under 64-bit Apache? Geert From: VanL van.lindb...@gmail.com Date: 16 September 2009 7:54:39 PM To: pythonmac-sig@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 ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] resuming python job
DavidW wrote: 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? I'm not seeing this (OSX 10.5.7): mac:Downloads pmcnett$ python Python 2.5.4 (r254:67917, Dec 23 2008, 14:57:27) [GCC 4.0.1 (Apple Computer, Inc. build 5363)] on darwin Type help, copyright, credits or license for more information. [1]+ Stopped python mac:Downloads pmcnett$ fg python print 23 23 ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: size of py2app app
Charles Hartman wrote: 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? I don't know, this is weird. If you can find or re-build the small one, you can compare them and see what py2app is putting in the bigger one. I have a faint memory of finding two copies of the wxPython libs in a py2app bundle once, but I don't remember why or what I did about it, but that could explain a major jump in size! -- sorry I can't help more, but I found it by running du on the app bundle, and looking for large things -- I did find I could trim quite a few megabytes of stuff that way (then ended up adding a 100mb database to the bundle -- oh well!) Good luck, -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] django webapp using CoreGraphics complains about wrong architecture
David Warde-Farley wrote: On 13-Sep-09, at 10:58 AM, Geert Dekkers wrote: 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 I'm confused here -- is Django really running on a python running inside Apache (aka py_mod) -- I'd be really surprised if that's the case. 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 no, I'm pretty sure that's not the case -- PIL requires its compiled code. I suspect that Django is running on a python as a separate process fro Apache, perhaps something else is the problem here? You could probably poke around with ps to be sure. Also, if Django is running inside Apache, you may well be able to configure it not to. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app cannot move to target thread error
Has anyone within earshot of this list successfully built a PyQt
app with SQL support using py2app? I've been poking and prodding
at the problem for a few months now and I'm no closer to a solution
to the cannot move to thread ... error.
Yes, I think I got this to work recently with Qt3. If I remember
correctly, it was due to loading multiple versions of the QtCore
library. I think the problem has to do with with Qt plugins not being
handled correctly by py2app, and thus the plugins are not being
loaded from within in the app bundle. Here's the relevant snippets
from the setup.py that I used:
name = program
setup(
name = name,
...
setup_requires=[py2app],
options = {
py2app: dict(
argv_emulation=True,
frameworks=[
/path/to/qt/plugins/sqldrivers/libqsqlpsql.dylib,
],
)
},
...
)
if py2app in sys.argv:
# fix the bundle created by py2app
def do(cmd):
print .join(cmd)
subprocess.call(cmd)
appdir = os.path.abspath(os.path.join(dist, name + .app,
Contents))
...
# move the sql driver where Qt will find it
plugin_dir = join(appdir, Resources, sqldrivers)
os.makedirs(plugin_dir)
do([mv, join(appdir, Frameworks, libqsqlpsql.dylib),
plugin_dir])
It might be necessary to put the sqldrivers in Contents/MacOS rather
than Contents/Resources. I was doing a lot of other strange stuff
with this app because I was trying to bundle a bunch of legacy C apps
into a stand-alone application that would run on Mac OS.
I'm not familiar with using py2app with macports libraries. But it's
a red flag to me that your app is loading libraries from /opt/local/...
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
Shouldn't those libraries be in your app bundle? I would expect to
see them loading from somewhere like /path/to/your/program.app/
Contents/MacOS/../Frameworks
This leads me to believe that you are in fact loading more than one
Qt library, which is causing the cannot move to thread error, and
is probably due to Qt using the wrong plugin(s).
One more thing: I think the plugin resolution logic in Qt changed
between Qt3 and Qt4, so the recipe I gave above might not work.
You'll need to look that up in the Qt documentation.
~ Daniel
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: size of py2app app
Christopher Barker wrote: I have a faint memory of finding two copies of the wxPython libs in a py2app bundle once, but I don't remember why or what I did about it, but This happens when building a Universal app. You get the ones compiled for Intel, plus the ones compiled for Motorola. Paul ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Fwd: size of py2app app
Paul McNett wrote: Christopher Barker wrote: I have a faint memory of finding two copies of the wxPython libs in a py2app bundle once, but I don't remember why or what I did about it, but This happens when building a Universal app. You get the ones compiled for Intel, plus the ones compiled for Motorola. no, that wasn't it. And while yes, there are two copies of each lib, one each for PPC an Intel, they are actually put into one big file. In my case, I had two copies, and both had both architectures. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/ORR(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] django webapp using CoreGraphics complains about wrong architecture
On 17-Sep-09, at 7:07 AM, Geert Dekkers wrote: Would this then mean that PIL would also fail complaining about wrong architecture when running under 64-bit Apache? If you tried to actually access image data with it (like, poke at actual pixels), yes. David ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools...
Ronald Oussoren ronaldousso...@mac.com wrote: Bill, Appscript probably gets installed as a zipped egg, the .python-eggs directory gets created when a real filesystem path is needed for an item in such an egg. Yes, that's part of the problem. The other part is that .pth handling seems to have changed from 2.5 to 2.6. If you install appscript as an unzipped egg the problem should go away. How does one do that? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools...
On Thu, Sep 17, 2009, Bill Janssen wrote: Ronald Oussoren ronaldousso...@mac.com wrote: If you install appscript as an unzipped egg the problem should go away. How does one do that? You can unzip manually as with any other .ZIP file, or you can do easy_install with -Z. -- Aahz (a...@pythoncraft.com) * http://www.pythoncraft.com/ I won't accept a model of the universe in which free will, omniscient gods, and atheism are simultaneously true. --M ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools...
In article 20090917234722.gb26...@panix.com, Aahz a...@pythoncraft.com wrote: On Thu, Sep 17, 2009, Bill Janssen wrote: Ronald Oussoren ronaldousso...@mac.com wrote: If you install appscript as an unzipped egg the problem should go away. How does one do that? You can unzip manually as with any other .ZIP file, or you can do easy_install with -Z. ... and if you always want to install eggs unzipped, add the following to one of the distutils config files, i.e. ~/.pydistutils.cfg: [easy_install] zip-ok = 0 -- Ned Deily, n...@acm.org ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2app cannot move to target thread error
Hi Daniel,
Thanks for the info and sample code! I've now got libqsqlpsql.bundle
copying to the app bundle's frameworks dir.
Reading http://doc.trolltech.com/4.4/deployment-mac.html#linking-the-application-to-qt-as-frameworks
, I'm knee deep in otool and install_name_tool. I had no idea I had
to wrestle with this for a Python app.
I'll post back to the list once I've got things working. At least the
train is rolling again! Thanks for your help.
Scott
On Sep 17, 2009, at 10:55 AM, Daniel Miller wrote:
Has anyone within earshot of this list successfully built a PyQt
app with SQL support using py2app? I've been poking and prodding
at the problem for a few months now and I'm no closer to a solution
to the cannot move to thread ... error.
Yes, I think I got this to work recently with Qt3. If I remember
correctly, it was due to loading multiple versions of the QtCore
library. I think the problem has to do with with Qt plugins not
being handled correctly by py2app, and thus the plugins are not
being loaded from within in the app bundle. Here's the relevant
snippets from the setup.py that I used:
name = program
setup(
name = name,
...
setup_requires=[py2app],
options = {
py2app: dict(
argv_emulation=True,
frameworks=[
/path/to/qt/plugins/sqldrivers/libqsqlpsql.dylib,
],
)
},
...
)
if py2app in sys.argv:
# fix the bundle created by py2app
def do(cmd):
print .join(cmd)
subprocess.call(cmd)
appdir = os.path.abspath(os.path.join(dist, name + .app,
Contents))
...
# move the sql driver where Qt will find it
plugin_dir = join(appdir, Resources, sqldrivers)
os.makedirs(plugin_dir)
do([mv, join(appdir, Frameworks, libqsqlpsql.dylib),
plugin_dir])
It might be necessary to put the sqldrivers in Contents/MacOS rather
than Contents/Resources. I was doing a lot of other strange stuff
with this app because I was trying to bundle a bunch of legacy C
apps into a stand-alone application that would run on Mac OS.
I'm not familiar with using py2app with macports libraries. But it's
a red flag to me that your app is loading libraries from /opt/
local/...
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
Shouldn't those libraries be in your app bundle? I would expect to
see them loading from somewhere like /path/to/your/program.app/
Contents/MacOS/../Frameworks
This leads me to believe that you are in fact loading more than one
Qt library, which is causing the cannot move to thread error, and
is probably due to Qt using the wrong plugin(s).
One more thing: I think the plugin resolution logic in Qt changed
between Qt3 and Qt4, so the recipe I gave above might not work.
You'll need to look that up in the Qt documentation.
~ Daniel
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
