From dhubleizh at o2.pl Tue Sep 1 17:24:52 2009 From: dhubleizh at o2.pl (=?ISO-8859-2?Q?Cezary_Krzy=BFanowski?=) Date: Tue, 1 Sep 2009 17:24:52 +0200 Subject: [Pythonmac-SIG] [PATCH] macholib better exclude Message-ID: <2B65B732-63C3-4275-BC13-E7F21B34297B@o2.pl> Hello! I've been fighting my way through py2app and trying to exclude QtSomething_debug libraries and been unable to do it via py2app -E QtCore_debug. I'm sending a patch to macholib, which makes excludes work in a sane way: 1. There was a exclude finding loop but it returned the filename when the file was found in excludes 2. Moved the checking loop at the top --- if someone want's to exclude some system or other important files --- he probably already knows their importance if he dug deep to find them 3. Make it possible to add just the name of excluded file/lib, not the whole path * make py2app understand exclude option --- now only manually supplying python setup.py py2app -E works * make excludes regexps * get py2app recipes the possibility to work in all steps of building the bundle, not only in the module resolution (for example I want to exclude a library which is found out late in py2app when calling PythonStandalone); another filter hook for let's say binary files produces while running PythonStandalone would rock my socks of!! Czarek -------------- next part -------------- A non-text attachment was scrubbed... Name: arbitrary_exclude.patch Type: application/octet-stream Size: 833 bytes Desc: not available URL: -------------- next part -------------- From ronaldoussoren at mac.com Tue Sep 1 20:47:15 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 01 Sep 2009 20:47:15 +0200 Subject: [Pythonmac-SIG] Can I set an environment variable with py2app? In-Reply-To: <4A985733.9020802@noaa.gov> References: <4A985733.9020802@noaa.gov> Message-ID: On 29 Aug, 2009, at 0:16, Christopher Barker wrote: > Hi folks, > > I was using the Peppy editor, and it's spell checker relies on > PyEnchant, which uses ctypes to use the enchant lib. I am using a > macports enchant, so I had an environment variable set so that > PyEnchant could find it: > > export PYENCHANT_LIBRARY_PATH=/opt/local/lib/libenchant.dylib > > This worked just great when I started Peppy from the command line, > but when I started it from an application bundle, it failed, which > I'm pretty sure is because apps started in bundles don't have the > shell's environment variables. That's right. > > I think there is a way to set a "global" environment variable in a > plist somewhere, but I think it might be better to set it in the App > bundle -- is there a way to do that? The easiest way to do that is: import os os.environ["PYENCHANT_LIBRARY_PATH"] = "/opt/local/lib/libenchant.dylib" If you do this before importing pyenchant it should pick up that definition. > > For the moment, I've hacked the enchant module to look in the > macports location, but I don't know if the maintainer will want to > make that a permanent change. If he does, what would be the path to > a fink enchant lib? we might as well add that too! Hardcoding the library path would imho be a bad idea. BTW. It would be much better to copy the library and its resources into the application bundle, but that requires additional support in py2app because it cannot automaticly detect the dependency to libenchant.dylib. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From rowen at uw.edu Tue Sep 1 21:19:07 2009 From: rowen at uw.edu (Russell E. Owen) Date: Tue, 01 Sep 2009 12:19:07 -0700 Subject: [Pythonmac-SIG] py2app on Snow Leopard? Message-ID: Has anyone tried py2app on Snow Leopard, and if so, how well does it work? I'm trying to release programs that are compatible at with 10.4, 10.5 and 10.6, and don't want to upgrade my own OS from 10.5 prematurely. I'm willing to do some experiments and report back, but I'd rather learn what I can first. -- Russell From rowen at uw.edu Thu Sep 3 05:01:16 2009 From: rowen at uw.edu (Russell E. Owen) Date: Wed, 02 Sep 2009 20:01:16 -0700 Subject: [Pythonmac-SIG] py2app on Snow Leopard? References: Message-ID: In article , "Russell E. Owen" wrote: > Has anyone tried py2app on Snow Leopard, and if so, how well does it > work? > > I'm trying to release programs that are compatible at with 10.4, 10.5 > and 10.6, and don't want to upgrade my own OS from 10.5 prematurely. I'm > willing to do some experiments and report back, but I'd rather learn > what I can first. To answer my own question: based on limited testing it appears to work just fine. -- Russell P.S. installing Snow Leopard left my existing Python and /usr/local alone, so I didn't have to reinstall anything. In the past I've done an Archive-and-Install, but that option is gone, so I just took the default behavior. From partha.shamim at gmail.com Sun Sep 6 22:21:18 2009 From: partha.shamim at gmail.com (Ahmed Shamim) Date: Sun, 6 Sep 2009 16:21:18 -0400 Subject: [Pythonmac-SIG] Help wanted in installing IDLE in Mac Message-ID: Hi there, I'm really in a deep shit. In my class, I am just falling behind. I am trying every way to install IDLE in my macbook (version OS X 10.5.8 and Intel core 2 duo) It gets installed, but when I double click IDLE app, it just seems like opening something, but does not open anything... pls help. Shamim -------------- next part -------------- An HTML attachment was scrubbed... URL: From kay.gottschalk at gmail.com Tue Sep 8 09:49:27 2009 From: kay.gottschalk at gmail.com (Kay Gottschalk) Date: Tue, 8 Sep 2009 09:49:27 +0200 Subject: [Pythonmac-SIG] appscript install Message-ID: Hi there, when I try to install appscript, I get the following errors: In file included from /System/Library/Frameworks/Carbon.framework/ Frameworks/HIToolbox.framework/Headers/CarbonEvents.h:40, from /System/Library/Frameworks/Carbon.framework/ Frameworks/HIToolbox.framework/Headers/HIView.h:24, from /System/Library/Frameworks/Carbon.framework/ Frameworks/HIToolbox.framework/Headers/HIToolbox.h:41, from /System/Library/Frameworks/Carbon.framework/ Headers/Carbon.h:29, from appscript_2x/ext/aetoolbox.h:19, from appscript_2x/ext/ae.c:15: /System/Library/Frameworks/Carbon.framework/Frameworks/ HIToolbox.framework/Headers/MacWindows.h:5385: error: syntax error before ?AliasHandle? /System/Library/Frameworks/Carbon.framework/Frameworks/ HIToolbox.framework/Headers/MacWindows.h:5427: error: syntax error before ?AliasHandle? lipo: can't open input file: /var/tmp//cckuHgUu.out (No such file or directory) error: Setup script exited with error: command 'gcc' failed with exit status 1 Any ideas? Thanks a lot! Kay. From ronaldoussoren at mac.com Tue Sep 8 14:11:08 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 08 Sep 2009 14:11:08 +0200 Subject: [Pythonmac-SIG] Help wanted in installing IDLE in Mac In-Reply-To: References: Message-ID: <0ECB5CFB-9DE8-4C36-A376-C1CC1D30ADD4@mac.com> On 6 Sep, 2009, at 22:21, Ahmed Shamim wrote: > > > > Hi there, > I'm really in a deep shit. > In my class, I am just falling behind. > I am trying every way to install IDLE in my macbook (version OS X > 10.5.8 and Intel core 2 duo) > > It gets installed, but when I double click IDLE app, it just seems > like opening something, but does not open anything... > pls help. How did you install IDLE? One way that should get you a working IDLE is to download the version of Python you want to use from www.python.org, there are binary installers for OSX for all current releases of Python (2.5.x, 2.6.x, 3.1.x) and all of them install IDLE into a subfolder of your Applications folder. If you already did that: you can start the IDLE application bundle in the Terminal as well: "/Applications/Python 2.6/IDLE.app/Contents/MacOS/IDLE" If that fails to launch IDLE I'd like to know the output that's printed in the Terminal window. Ronald > Shamim > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Tue Sep 8 14:12:16 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 08 Sep 2009 14:12:16 +0200 Subject: [Pythonmac-SIG] appscript install In-Reply-To: References: Message-ID: <621150C4-B83C-4588-9D0A-02DC55CECE0C@mac.com> On 8 Sep, 2009, at 9:49, Kay Gottschalk wrote: > > Hi there, > when I try to install appscript, I get the following errors: What release of OSX are you running? Do you use /usr/bin/python or some other Python installation (and if the latter, which one) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From noelrappin at gmail.com Tue Sep 8 20:43:00 2009 From: noelrappin at gmail.com (Noel Rappin) Date: Tue, 8 Sep 2009 13:43:00 -0500 Subject: [Pythonmac-SIG] Appscript and Snow Leopard Message-ID: I have a Python script that I've been using to communicate back and forth with iTunes via py-appscript -- it's worked fine for a long time. Snow Leopard seems to have broken it -- everytime I run the script, it stops, and then exits, claiming that one of the commands has timed out. It's never the same place in the process twice, so its not due to any data issue. An attempt to mimic the basic communication in rb-appscript resulted in a similar error. It's as though iTunes decides after a set period of time to stop responding to appscript requests. I'm stumped as to how to work around this issue. Anybody have any ideas? Noel -- Noel Rappin noelrappin at gmail.com From emanuelesantos at gmail.com Tue Sep 8 23:56:56 2009 From: emanuelesantos at gmail.com (Emanuele Santos) Date: Tue, 8 Sep 2009 15:56:56 -0600 Subject: [Pythonmac-SIG] macholib unknown load command: 2147483682 Message-ID: Hi, I am trying to create a bundle using py2app dev on snow leopard and python 2.6 and I am getting the following error with macholib: ValueError: Unknown load command: 2147483682 Is there anything I can do to fix it? Part of the stack trace is shown below. Thanks, ... copying /usr/local/lib/libnetcdf_c++.5.dylib -> /Volumes/home/emanuele/ code/vistrails/trunk/dist/mac/dist/VisTrails.app/Contents/Frameworks Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ python2.6/site-packages/py2app-0.4.2-py2.6.egg/py2app/build_app.py", line 589, in _run self.run_normal() File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ python2.6/site-packages/py2app-0.4.2-py2.6.egg/py2app/build_app.py", line 660, in run_normal self.create_binaries(py_files, pkgdirs, extensions, loader_files) File "/Library/Frameworks/Python.framework/Versions/2.6/lib/ python2.6/site-packages/py2app-0.4.2-py2.6.egg/py2app/build_app.py", line 777, in create_binaries platfiles = mm.run() File "build/bdist.macosx-10.3-fat/egg/macholib/MachOStandalone.py", line 102, in run mm.run_file(fn) File "build/bdist.macosx-10.3-fat/egg/macholib/MachOGraph.py", line 68, in run_file self.scan_node(m) File "build/bdist.macosx-10.3-fat/egg/macholib/MachOGraph.py", line 91, in scan_node m = self.load_file(filename, caller=node) File "build/bdist.macosx-10.3-fat/egg/macholib/MachOGraph.py", line 78, in load_file return self.load_file(newname, caller=caller) File "build/bdist.macosx-10.3-fat/egg/macholib/MachOGraph.py", line 80, in load_file m = self.createNode(MachO, name) File "build/bdist.macosx-10.3-fat/egg/macholib/MachOStandalone.py", line 23, in createNode res = super(FilteredMachOGraph, self).createNode(cls, name) File "build/bdist.macosx-10.3-fat/egg/altgraph/ObjectGraph.py", line 148, in createNode m = cls(name, *args, **kw) File "build/bdist.macosx-10.3-fat/egg/macholib/MachO.py", line 63, in __init__ self.load(file(filename, 'rb')) File "build/bdist.macosx-10.3-fat/egg/macholib/MachO.py", line 78, in load self.load_header(fh, 0, size) File "build/bdist.macosx-10.3-fat/egg/macholib/MachO.py", line 108, in load_header hdr = MachOHeader(self, fh, offset, size, magic, hdr, endian) File "build/bdist.macosx-10.3-fat/egg/macholib/MachO.py", line 148, in __init__ self.load(fh) File "build/bdist.macosx-10.3-fat/egg/macholib/MachO.py", line 180, in load raise ValueError("Unknown load command: %d" % (cmd_load.cmd,)) ValueError: Unknown load command: 2147483682 > /Volumes/home/emanuele/code/vistrails/trunk/dist/mac/build/ bdist.macosx-10.3-fat/egg/macholib/MachO.py(180)load() -> raise ValueError("Unknown load command: %d" % (cmd_load.cmd,)) -- Emanuele. From Chris.Barker at noaa.gov Wed Sep 9 01:36:19 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 08 Sep 2009 16:36:19 -0700 Subject: [Pythonmac-SIG] macholib unknown load command: 2147483682 In-Reply-To: References: Message-ID: <4AA6EA73.6080302@noaa.gov> Emanuele Santos wrote: > I am trying to create a bundle using py2app dev on snow leopard and > python 2.6 and I am getting the following error with macholib: > > ValueError: Unknown load command: 2147483682 > > Is there anything I can do to fix it? Make sure you have the latest macholib. You may want install the latest dev version: easy_install macholib==dev If that doesn't fix it, it may be that snow leopard has added a new load command that macholib doesn't know what to do with. I think this may require a patch to macholib, but I'm not an expert -- Ronald? -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 Chris.Barker at noaa.gov From emanuelesantos at gmail.com Wed Sep 9 06:29:00 2009 From: emanuelesantos at gmail.com (Emanuele Santos) Date: Tue, 8 Sep 2009 22:29:00 -0600 Subject: [Pythonmac-SIG] macholib unknown load command: 2147483682 In-Reply-To: <4AA6EA73.6080302@noaa.gov> References: <4AA6EA73.6080302@noaa.gov> Message-ID: <161AC008-97F9-44A0-B121-88E07FCB226C@gmail.com> I am already using the latest versions of both macholib and py2app. Thanks, -- Emanuele. On Sep 8, 2009, at 5:36 PM, Christopher Barker wrote: > Emanuele Santos wrote: >> I am trying to create a bundle using py2app dev on snow leopard and >> python 2.6 and I am getting the following error with macholib: >> ValueError: Unknown load command: 2147483682 >> Is there anything I can do to fix it? > > Make sure you have the latest macholib. You may want install the > latest dev version: > > easy_install macholib==dev > > If that doesn't fix it, it may be that snow leopard has added a new > load command that macholib doesn't know what to do with. I think > this may require a patch to macholib, but I'm not an expert -- Ronald? > > -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 > > Chris.Barker at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From hengist.podd at virgin.net Wed Sep 9 07:53:53 2009 From: hengist.podd at virgin.net (has) Date: Wed, 9 Sep 2009 06:53:53 +0100 Subject: [Pythonmac-SIG] Appscript and Snow Leopard In-Reply-To: References: Message-ID: Noel Rappin wrote: > I have a Python script that I've been using to communicate back and > forth with iTunes via py-appscript -- it's worked fine for a long > time. > > Snow Leopard seems to have broken it -- everytime I run the script, it > stops, and then exits, claiming that one of the commands has timed > out. It's never the same place in the process twice, so its not due to > any data issue. An attempt to mimic the basic communication in > rb-appscript resulted in a similar error. Have you tried testing in AppleScript? That'll tell you if it's an appscript or iTunes problem, which'll help narrow things down a bit. has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net From georg.seifert at gmx.de Wed Sep 9 14:10:30 2009 From: georg.seifert at gmx.de (Georg Seifert) Date: Wed, 9 Sep 2009 14:10:30 +0200 Subject: [Pythonmac-SIG] Link against Python Framework Message-ID: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> Hi, In my Cocoa app, I link agains the Python framework to be able to call "PyRun_SimpleString" and load bundles based on python. If I set the Base SDK to 10.5, it runs on 10.5 and 10.6. But if I set it to 10.6 and MACOSX_DEPLOYMENT_TARGET = 10.5 it complains in Leopard that it can?t find python 2.6. Is there a my to always use the current python version (2.5 on Leopard and 2.6 on Snow Leopard) I link against the "/System/Library/Frameworks/Python.framework" Regards Georg From ronaldoussoren at mac.com Wed Sep 9 15:45:39 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 09 Sep 2009 15:45:39 +0200 Subject: [Pythonmac-SIG] Link against Python Framework In-Reply-To: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> References: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> Message-ID: <31927653636730773104506838970680462354-Webmail@me.com> On Wednesday, 09 September, 2009, at 02:10PM, "Georg Seifert" wrote: >Hi, > >In my Cocoa app, I link agains the Python framework to be able to call >"PyRun_SimpleString" and load bundles based on python. > >If I set the Base SDK to 10.5, it runs on 10.5 and 10.6. But if I set >it to 10.6 and MACOSX_DEPLOYMENT_TARGET = 10.5 it complains in Leopard >that it can?t find python 2.6. > >Is there a my to always use the current python version (2.5 on Leopard >and 2.6 on Snow Leopard) > >I link against the "/System/Library/Frameworks/Python.framework" In short: no, that is not possible. Major Python releases (such as 2.5 and 2.6) are not necessarily binary compatibel. If you are careful you can get a single binary that works with 2.5 and 2.6, but you then have to load the framework manually and also manually resolve any python API functions you are using. The easiest way to do that is using the CFBundle APIs in CoreFoundation. It might be easier to create two plugin bundles for your application: one that links against 2.6 and one that links against 2.5. You can then load the plugin that is most appropriate for the currently running OS version. Ronald > >Regards >Georg > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG at python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > From gabriel.rossetti at arimaz.com Wed Sep 9 15:53:19 2009 From: gabriel.rossetti at arimaz.com (Gabriel Rossetti) Date: Wed, 09 Sep 2009 15:53:19 +0200 Subject: [Pythonmac-SIG] Compiling libhid with python support : configure can't link to test program Message-ID: <4AA7B34F.6080806@arimaz.com> Hello everyone, I would like to compile libhid (because I couldn't find it already compiled) on mac os x 10.5.x. When I run configure it dies saying it can't link against my python lib and that it may be installed in an alternative location or that I need to install a dev version of python. I'm using the version shipped with 10.5, does anyone know how to fix this? Thank you, Gabriel From kw at codebykevin.com Wed Sep 9 16:07:28 2009 From: kw at codebykevin.com (Kevin Walzer) Date: Wed, 09 Sep 2009 10:07:28 -0400 Subject: [Pythonmac-SIG] Link against Python Framework In-Reply-To: <31927653636730773104506838970680462354-Webmail@me.com> References: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> <31927653636730773104506838970680462354-Webmail@me.com> Message-ID: <4AA7B6A0.6050407@codebykevin.com> > > Major Python releases (such as 2.5 and 2.6) are not necessarily binary compatibel. If you are careful you can get a single binary that works with 2.5 and 2.6, but you then have to load the framework manually and also manually resolve any python API functions you are using. The easiest way to do that is using the CFBundle APIs in CoreFoundation. > Does this mean that if one builds a PyObjC application using Apple's tools--Xcode, linking against the system Python and PyObjC frameworks--then it may break in an OS upgrade if Apple has upgraded the system Python installation? I've always wondered about this. -- Kevin Walzer Code by Kevin http://www.codebykevin.com From gabriel.rossetti at arimaz.com Wed Sep 9 16:18:45 2009 From: gabriel.rossetti at arimaz.com (Gabriel Rossetti) Date: Wed, 09 Sep 2009 16:18:45 +0200 Subject: [Pythonmac-SIG] Compiling libhid with python support : configure can't link to test program In-Reply-To: <4AA7B34F.6080806@arimaz.com> References: <4AA7B34F.6080806@arimaz.com> Message-ID: <4AA7B945.6060507@arimaz.com> Gabriel Rossetti wrote: > Hello everyone, > > I would like to compile libhid (because I couldn't find it already > compiled) on mac os x 10.5.x. When I run configure it dies saying it > can't link against my python lib and that it may be installed in an > alternative location or that I need to install a dev version of > python. I'm using the version shipped with 10.5, does anyone know how > to fix this? > > Thank you, > Gabriel > Here's some more info, it does this : Compiled with g++ [i686-apple-darwin9.0] Please see http://www.swig.org for reporting bugs and further information checking for python... /usr/bin/python checking for python version... 2.5 checking for python platform... darwin checking for python script directory... /Library/Python/2.5/site-packages checking for python extension module directory... /Library/Python/2.5/site-packages checking for python2.5... (cached) /usr/bin/python checking for a version of Python >= '2.1.0'... yes checking for the distutils Python package... yes checking for Python include path... -I/System/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 checking for Python library path... /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/Python.framework/Versions/2.5/Python checking for Python site-packages path... /Library/Python/2.5/site-packages checking python extra libraries... -ldl checking python extra linking flags... -u _PyMac_Error -framework Python checking consistency of all components of python development environment... no configure: error: Could not link test program to Python. Maybe the main Python library has been installed in some non-standard library path. If so, pass it to configure, via the LDFLAGS environment variable. Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib" ============================================================================ ERROR! You probably have to install the development version of the Python package for your distribution. The exact name of this package varies among them. ============================================================================ I looked at this line : checking for Python library path... /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/Python.framework/Versions/2.5/Python and that path doesn't exist, this one does though : /System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/ and inside there is libpython2.5.a which is the static python lib, I tried doing as it said : ./configure LDFLAGS="-L/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/config/" with no luck though. Thank you, Gabriel From ronaldoussoren at mac.com Wed Sep 9 16:55:13 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 09 Sep 2009 16:55:13 +0200 Subject: [Pythonmac-SIG] Link against Python Framework In-Reply-To: <4AA7B6A0.6050407@codebykevin.com> References: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> <31927653636730773104506838970680462354-Webmail@me.com> <4AA7B6A0.6050407@codebykevin.com> Message-ID: <33397413270068300425269198628695243738-Webmail@me.com> On Wednesday, 09 September, 2009, at 04:07PM, "Kevin Walzer" wrote: >> >> Major Python releases (such as 2.5 and 2.6) are not necessarily binary compatibel. If you are careful you can get a single binary that works with 2.5 and 2.6, but you then have to load the framework manually and also manually resolve any python API functions you are using. The easiest way to do that is using the CFBundle APIs in CoreFoundation. >> > >Does this mean that if one builds a PyObjC application using Apple's >tools--Xcode, linking against the system Python and PyObjC >frameworks--then it may break in an OS upgrade if Apple has upgraded the >system Python installation? I've always wondered about this. That could in theory break applications. Luckily Apple is very reluctant about breaking applications and hence ships multiple versions of Python (/System/Library/Frameworks/Python.framework on 3 versions of python: 2.3, 2.5 and 2.6). This means that you can safely link to the system Python on a 10.5 system (or even a 10.3.9 system) and run your application on a 10.6 system. Ronald From ronaldoussoren at mac.com Wed Sep 9 20:22:02 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 09 Sep 2009 20:22:02 +0200 Subject: [Pythonmac-SIG] macholib unknown load command: 2147483682 In-Reply-To: <161AC008-97F9-44A0-B121-88E07FCB226C@gmail.com> References: <4AA6EA73.6080302@noaa.gov> <161AC008-97F9-44A0-B121-88E07FCB226C@gmail.com> Message-ID: <45936384-0CA4-4C5C-9282-6A03C0E13034@mac.com> On 9 Sep, 2009, at 6:29, Emanuele Santos wrote: > > I am already using the latest versions of both macholib and py2app. Could you try again? I've just checked in a patch for macholib that adds minimal support for some new loader commands (r28 in the macholib repository) Ronald > > Thanks, > > -- Emanuele. > > > On Sep 8, 2009, at 5:36 PM, Christopher Barker wrote: > >> Emanuele Santos wrote: >>> I am trying to create a bundle using py2app dev on snow leopard >>> and python 2.6 and I am getting the following error with macholib: >>> ValueError: Unknown load command: 2147483682 >>> Is there anything I can do to fix it? >> >> Make sure you have the latest macholib. You may want install the >> latest dev version: >> >> easy_install macholib==dev >> >> If that doesn't fix it, it may be that snow leopard has added a new >> load command that macholib doesn't know what to do with. I think >> this may require a patch to macholib, but I'm not an expert -- >> Ronald? >> >> -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 >> >> Chris.Barker at noaa.gov >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From jason at threeve.org Wed Sep 9 16:25:21 2009 From: jason at threeve.org (Jason Foreman) Date: Wed, 9 Sep 2009 09:25:21 -0500 Subject: [Pythonmac-SIG] Link against Python Framework In-Reply-To: <4AA7B6A0.6050407@codebykevin.com> References: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> <31927653636730773104506838970680462354-Webmail@me.com> <4AA7B6A0.6050407@codebykevin.com> Message-ID: <7346298F-8203-4CBC-9F1F-4D817E76C154@threeve.org> On Sep 9, 2009, at 9:07 AM, Kevin Walzer wrote: >> >> Major Python releases (such as 2.5 and 2.6) are not necessarily >> binary compatibel. If you are careful you can get a single binary >> that works with 2.5 and 2.6, but you then have to load the >> framework manually and also manually resolve any python API >> functions you are using. The easiest way to do that is using the >> CFBundle APIs in CoreFoundation. >> > > Does this mean that if one builds a PyObjC application using Apple's > tools--Xcode, linking against the system Python and PyObjC > frameworks--then it may break in an OS upgrade if Apple has upgraded > the system Python installation? I've always wondered about this. In theory, it is possible. But Apple takes care to maintain backwards compatibility. If you poke around in /System/Library/Frameworks/ Python.framework/Versions, you'll see that (on Snow Leopard) they ship 2.6, 2.5, *and* 2.3 (2.3 shipped with Tiger). So the version of Python to which your app links should be available going forward. If you want to make absolutely sure that Apple can't break you, you could bundle the version of Python.framework upon which you depend into your app. However, that's probably not necessary unless you want to use a newer version of Python than the system has (say, 3.0+, or 2.6 on Leopard). Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From emanuelesantos at gmail.com Thu Sep 10 06:25:25 2009 From: emanuelesantos at gmail.com (Emanuele Santos) Date: Wed, 9 Sep 2009 22:25:25 -0600 Subject: [Pythonmac-SIG] macholib unknown load command: 2147483682 In-Reply-To: <45936384-0CA4-4C5C-9282-6A03C0E13034@mac.com> References: <4AA6EA73.6080302@noaa.gov> <161AC008-97F9-44A0-B121-88E07FCB226C@gmail.com> <45936384-0CA4-4C5C-9282-6A03C0E13034@mac.com> Message-ID: Thanks, Ronald! It is working now. -- Emanuele. On Sep 9, 2009, at 12:22 PM, Ronald Oussoren wrote: > > On 9 Sep, 2009, at 6:29, Emanuele Santos wrote: > >> >> I am already using the latest versions of both macholib and py2app. > > Could you try again? I've just checked in a patch for macholib that > adds minimal support for some new loader commands (r28 in the > macholib repository) > > Ronald > >> >> Thanks, >> >> -- Emanuele. >> >> >> On Sep 8, 2009, at 5:36 PM, Christopher Barker wrote: >> >>> Emanuele Santos wrote: >>>> I am trying to create a bundle using py2app dev on snow leopard >>>> and python 2.6 and I am getting the following error with macholib: >>>> ValueError: Unknown load command: 2147483682 >>>> Is there anything I can do to fix it? >>> >>> Make sure you have the latest macholib. You may want install the >>> latest dev version: >>> >>> easy_install macholib==dev >>> >>> If that doesn't fix it, it may be that snow leopard has added a >>> new load command that macholib doesn't know what to do with. I >>> think this may require a patch to macholib, but I'm not an expert >>> -- Ronald? >>> >>> -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 >>> >>> Chris.Barker at noaa.gov >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> >> >> >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig From ssquery at gmail.com Thu Sep 10 06:32:45 2009 From: ssquery at gmail.com (sudhakar s) Date: Thu, 10 Sep 2009 10:02:45 +0530 Subject: [Pythonmac-SIG] python-sap webservices Message-ID: <1528d2590909092132k44a20594o7172e099edeee375@mail.gmail.com> Hi, This is sudhakar, i am using python frame work and now concentrating on working on web services in python. I installed SOAPpy-0.12.0 on mac but getting errors as below: venj:SOAPpy-0.12.0 venkata$ python setup.py build Traceback (most recent call last): File "setup.py", line 8, in from SOAPpy.version import __version__ File "/Applications/SOAPpy-0.12.0/SOAPpy/__init__.py", line 5, in from Client import * File "/Applications/SOAPpy-0.12.0/SOAPpy/Client.py", line 46 from __future__ import nested_scopes SyntaxError: from __future__ imports must occur at the beginning of the file venj:SOAPpy-0.12.0 venkata$ python setup.py install Traceback (most recent call last): File "setup.py", line 8, in from SOAPpy.version import __version__ File "/Applications/SOAPpy-0.12.0/SOAPpy/__init__.py", line 5, in from Client import * File "/Applications/SOAPpy-0.12.0/SOAPpy/Client.py", line 46 from __future__ import nested_scopes SyntaxError: from __future__ imports must occur at the beginning of the file Hey please suggest me how to solve this error. Hey actually whats my requirement is i need to gather information from SAP system and Store it in Python appliction server. For this i am thinking to construct a web service on python in order to get the data from SAP system. Is this the correct way or is there any other possibility get in formation and store it in python application and i use mysql database for python. Please give your valuable suggestion. Waiting for early reply. with regards S Sudhakar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From georg.seifert at gmx.de Thu Sep 10 12:09:36 2009 From: georg.seifert at gmx.de (Georg Seifert) Date: Thu, 10 Sep 2009 12:09:36 +0200 Subject: [Pythonmac-SIG] Link against Python Framework In-Reply-To: <7346298F-8203-4CBC-9F1F-4D817E76C154@threeve.org> References: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> <31927653636730773104506838970680462354-Webmail@me.com> <4AA7B6A0.6050407@codebykevin.com> <7346298F-8203-4CBC-9F1F-4D817E76C154@threeve.org> Message-ID: <3284BBCF-530D-470D-94FB-DFE3CD07AA24@gmx.de> > > If you want to make absolutely sure that Apple can't break you, you > could bundle the version of Python.framework upon which you depend > into your app. However, that's probably not necessary unless you > want to use a newer version of Python than the system has (say, > 3.0+, or 2.6 on Leopard). How do I specify the version to link with. The 10.5 SDK links against python 2.5 and the 10.6 SDK to 2.6. But what if I need the 10.6 SKD but want to link to python 2.5? Regards Georg From howes at ll.mit.edu Thu Sep 10 17:07:34 2009 From: howes at ll.mit.edu (Brad Howes) Date: Thu, 10 Sep 2009 11:07:34 -0400 Subject: [Pythonmac-SIG] Appscript and Snow Leopard In-Reply-To: References:

Message-ID: On Sep 9, 2009, at 1:53 AM, has wrote: > Noel Rappin wrote: > >> I have a Python script that I've been using to communicate back and >> forth with iTunes via py-appscript -- it's worked fine for a long >> time. >> >> Snow Leopard seems to have broken it -- everytime I run the script, >> it >> stops, and then exits, claiming that one of the commands has timed >> out. It's never the same place in the process twice, so its not due >> to >> any data issue. An attempt to mimic the basic communication in >> rb-appscript resulted in a similar error. Did you reinstall appscript? I did and all runs fine for Pyslimp3 (http://code.google.com/p/pyslimp3/ ) Brad -- Brad Howes Group 42 MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 From skloot at gmail.com Thu Sep 10 21:11:48 2009 From: skloot at gmail.com (david) Date: Thu, 10 Sep 2009 12:11:48 -0700 Subject: [Pythonmac-SIG] C Extension build troubles in 10.6 Message-ID: <1e7b56f10909101211t46c07360vbd6c719f52d58beb@mail.gmail.com> I'm having trouble building extensions for python packages in Snow Leopard. I'm running into this issue with mxBase and psycopg2 currently. I haven't tried any others. Here's the output, this example being from mxBase: gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -DUSE_FAST_GETCURRENTTIME -DBAD_STATIC_FORWARD=1 -UHAVE_STRPTIME -Imx/DateTime/mxDateTime -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -I/usr/local/include -I/opt/local/include -I/Library/Frameworks/Python.framework/Versions/2.5/include -c mx/DateTime/mxDateTime/mxDateTime.c -o build/temp.macosx-10.3-i386-2.5_ucs2/mx-DateTime-mxDateTime-mxDateTime/mx/DateTime/mxDateTime/mxDateTime.o cc1: error: unrecognized command line option "-Wno-long-double" cc1: error: unrecognized command line option "-Wno-long-double" lipo: can't figure out the architecture type of: /var/folders/fO/fO43i+NPFDKpf9wCgPlln++++TI/-Tmp-//ccTzrZYF.out error: command 'gcc' failed with exit status 1 This is a new machine with a build environment that should be pretty clean. Any ideas? I'm having little luck figuring this out. There doesn't seem to be much information / discussion about the lipo error. Thanks, David From norman at astro.gla.ac.uk Thu Sep 10 22:19:16 2009 From: norman at astro.gla.ac.uk (Norman Gray) Date: Thu, 10 Sep 2009 21:19:16 +0100 Subject: [Pythonmac-SIG] aemreceive/py-appscript and 64-bit Message-ID: <0D559D70-A3D7-438B-BAFF-E5AEB9597AA3@astro.gla.ac.uk> Greetings. On Sat Aug 29 00:16:19 CEST 2009, Christopher Barker said: > export PYENCHANT_LIBRARY_PATH=/opt/local/lib/libenchant.dylib > > This worked just great when I started Peppy from the command line, but > when I started it from an application bundle, it failed, which I'm > pretty sure is because apps started in bundles don't have the shell's > environment variables. That's correct. They're started as children of launchd (if I recall correctly), and so inherit that process's environment, not any shell's. > I think there is a way to set a "global" environment variable in a > plist > somewhere, That's ~/.MacOSX/environment.plist > but I think it might be better to set it in the App bundle -- > is there a way to do that? I haven't tested this, but I think that there's relevant documentation at Best wishes, Norman -- Norman Gray : http://nxg.me.uk Dept Physics and Astronomy, University of Leicester, UK From norman at astro.gla.ac.uk Thu Sep 10 22:08:50 2009 From: norman at astro.gla.ac.uk (Norman Gray) Date: Thu, 10 Sep 2009 21:08:50 +0100 Subject: [Pythonmac-SIG] Installing/upgrading py-appscript on 10.6 Message-ID: <1D5C9DF8-543F-45D8-9217-A566D0EB9103@astro.gla.ac.uk> Greetings. I'm having difficulty using py-appscript after a recent upgrade to 10.6. I had appscript installed on 10.5, and was using it successfully. With the change to 10.6, Python has changed from 2.5.? to 2.6.1. Now, when I try to import appscript, I get: % which python /usr/bin/python % python Python 2.6.1 (r261:67515, Jul 7 2009, 23:51:51) [GCC 4.2.1 (Apple Inc. build 5646)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from appscript import * Traceback (most recent call last): File "", line 1, in ImportError: No module named appscript >>> If I try to use easy_install to (re-)install appscript, I get: % sudo easy_install appscript Searching for appscript Best match: appscript 0.20.0 Processing appscript-0.20.0-py2.5-macosx-10.5-i386.egg Adding appscript 0.20.0 to easy-install.pth file Using /Library/Python/2.5/site-packages/appscript-0.20.0-py2.5- macosx-10.5-i386.egg Processing dependencies for appscript Finished processing dependencies for appscript % ...which appears to be linked to Python 2.5, not 2.6. Googling around doesn't really help very much. Advice includes "easy_install -m appscript" and "easy_install -U setuptools", and though I can read a manpage, this is clearly drifting into the realms of voodoo. I'm slightly surprised that I apparently can't _un_install appscript and start afresh. I can't see any rele I have so far managed to remain innocent of exactly how Python manages its libraries. It looks like I'm going to have to get someone to destroy that innocence: what should I be doing here, and why? I do have the Developer tools installed: % /usr/bin/gcc --version i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5646) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Thanks for any pointers. Norman -- Norman Gray : http://nxg.me.uk Dept Physics and Astronomy, University of Leicester, UK From noelrappin at gmail.com Fri Sep 11 06:03:06 2009 From: noelrappin at gmail.com (Noel Rappin) Date: Thu, 10 Sep 2009 23:03:06 -0500 Subject: [Pythonmac-SIG] Appscript and Snow Leopard In-Reply-To: References:

Message-ID: I did reinstall. I'm still having the same problem with Appscript 0.20, Snow Leopard's Python 2.6.1 The issue happens in a different place each time, but the error looks like this: File "build/bdist.macosx-10.6-universal/egg/appscript/reference.py", line 504, in __call__ appscript.reference.CommandError: Command failed: OSERROR: -1712 MESSAGE: Apple event timed out. COMMAND: app(u'/Applications/iTunes.app').sources.ID(41).library_playlists.ID(25438).file_tracks.ID(32305).played_count.get() Noel On Thu, Sep 10, 2009 at 10:07 AM, Brad Howes wrote: > On Sep 9, 2009, at 1:53 AM, has wrote: > >> Noel Rappin wrote: >> >>> I have a Python script that I've been using to communicate back and >>> forth with iTunes via py-appscript -- it's worked fine for a long >>> time. >>> >>> Snow Leopard seems to have broken it -- everytime I run the script, it >>> stops, and then exits, claiming that one of the commands has timed >>> out. It's never the same place in the process twice, so its not due to >>> any data issue. An attempt to mimic the basic communication in >>> rb-appscript resulted in a similar error. > > > Did you reinstall appscript? I did and all runs fine for Pyslimp3 > (http://code.google.com/p/pyslimp3/) > > Brad > > -- > Brad Howes > Group 42 > MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 > Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 > > > > > _______________________________________________ > Pythonmac-SIG maillist ?- ?Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Noel Rappin noelrappin at alumni.brandeis.edu From howes at ll.mit.edu Fri Sep 11 16:02:26 2009 From: howes at ll.mit.edu (Brad Howes) Date: Fri, 11 Sep 2009 10:02:26 -0400 Subject: [Pythonmac-SIG] Appscript and Snow Leopard In-Reply-To: References:

Message-ID: <4BDF0C06-8BE7-4918-9EE4-C994F9CF09A3@ll.mit.edu> On Sep 11, 2009, at 12:03 AM, Noel Rappin wrote: > I did reinstall. I'm still having the same problem with Appscript > 0.20, Snow Leopard's Python 2.6.1 > > The issue happens in a different place each time, but the error > looks like this: > > File "build/bdist.macosx-10.6-universal/egg/appscript/reference.py", > line 504, in __call__ > appscript.reference.CommandError: Command failed: > OSERROR: -1712 > MESSAGE: Apple event timed out. > COMMAND: app(u'/Applications/iTunes.app').sources.ID > (41).library_playlists.ID(25438).file_tracks.ID > (32305).played_count.get() Did you force the reinstall? It appears so, since it reached the 10.6 appscript install. Sorry. No idea what is happening there. I'm able to interact with iTunes just fine (so far) with 10.6. I have to now try and see what effect the new library layout might have on my Python code. Brad -- Brad Howes Group 42 MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 From norman at astro.gla.ac.uk Fri Sep 11 17:48:18 2009 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 11 Sep 2009 16:48:18 +0100 Subject: [Pythonmac-SIG] Appscript and Snow Leopard In-Reply-To: <4BDF0C06-8BE7-4918-9EE4-C994F9CF09A3@ll.mit.edu> References:

<4BDF0C06-8BE7-4918-9EE4-C994F9CF09A3@ll.mit.edu> Message-ID: <9153BAE4-4A20-46DD-B699-C68438B4627F@astro.gla.ac.uk> Greetings On 2009 Sep 11, at 15:02, Brad Howes 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). > Sorry. No idea what is happening there. I'm able to interact with > iTunes just fine (so far) with 10.6. That's what I'm aiming to be able to do (as worked in 10.5). All the best, Norman [1] http://mail.python.org/pipermail/pythonmac-sig/2009-September/021581.html -- Norman Gray : http://nxg.me.uk Dept Physics and Astronomy, University of Leicester, UK From howes at ll.mit.edu Fri Sep 11 18:05:11 2009 From: howes at ll.mit.edu (Brad Howes) Date: Fri, 11 Sep 2009 12:05:11 -0400 Subject: [Pythonmac-SIG] Appscript and Snow Leopard In-Reply-To: <9153BAE4-4A20-46DD-B699-C68438B4627F@astro.gla.ac.uk> References:

<4BDF0C06-8BE7-4918-9EE4- Message-ID: <9634B57C-F9E2-46B8-BD10-41EC50A8C5DB@ll.mit.edu> On Sep 11, 2009, at 11:48 AM, 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). I thought I had used the -U option with easy_install, but looking at my notes, I did the following: - Download the appscript-0.20.0.tar.gz file - Expand the tarball - Go into the appscript-0.20.0 directory - sudo python setup.py install I'm using the stock 10.6 Python (2.6.1). Brad -- Brad Howes Group 42 MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 From janssen at parc.com Fri Sep 11 19:50:59 2009 From: janssen at parc.com (Bill Janssen) Date: Fri, 11 Sep 2009 10:50:59 PDT Subject: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard Message-ID: <14881.1252691459@parc.com> I was happy to see that Python 2.5 still shipped with SL, but now I'm less happy. I can't seem to compile PIL for Python 2.5 on Snow Leopard. The problem is that when I build and install libjpeg or libpng, it builds 64-bit libraries, but Python 2.5 is 32-bit, so the libraries don't work when PIL tries to use them. You get an error message something like this: >>> import _imaging ImportError: dlopen(/Library/Python/2.5/site-packages/PIL/_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart> Referenced from: /Library/Python/2.5/site-packages/PIL/_imaging.so Expected in: dynamic lookup >>> Bill From howes at ll.mit.edu Fri Sep 11 20:31:44 2009 From: howes at ll.mit.edu (Brad Howes) Date: Fri, 11 Sep 2009 14:31:44 -0400 Subject: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard In-Reply-To: <14881.1252691459@parc.com> References: <14881.1252691459@parc.com> Message-ID: On Sep 11, 2009, at 1:50 PM, Bill Janssen wrote: > I was happy to see that Python 2.5 still shipped with SL, but now I'm > less happy. I can't seem to compile PIL for Python 2.5 on Snow > Leopard. > > The problem is that when I build and install libjpeg or libpng, it > builds 64-bit libraries, but Python 2.5 is 32-bit, so the libraries > don't work when PIL tries to use them. You get an error message > something like this: Can you try recompiling with "-arch i386 -arch x86_64" options in the CFLAGS? I think I had gotten this to work for some other libraries when I ran into the dreaded linking problem. You might instead need to do CC="gcc -arch..." if the configure tool munges the CFLAGS too much. % CFLAGS="-arch i386 -arch x86_64" ./configure ... or % CC="gcc -arch..." ./configure ... Brad -- Brad Howes Group 42 MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 From charles.hartman at conncoll.edu Fri Sep 11 21:00:42 2009 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Fri, 11 Sep 2009 15:00:42 -0400 Subject: [Pythonmac-SIG] size of py2app app Message-ID: 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 From emoy at apple.com Fri Sep 11 21:45:41 2009 From: emoy at apple.com (Edward Moy) Date: Fri, 11 Sep 2009 12:45:41 -0700 Subject: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard In-Reply-To: References: <14881.1252691459@parc.com> Message-ID: <5D0427F0-D343-4F2B-915F-369CD3FC77DB@apple.com> On Sep 11, 2009, at 11:31 AM, Brad Howes wrote: > On Sep 11, 2009, at 1:50 PM, Bill Janssen wrote: > >> I was happy to see that Python 2.5 still shipped with SL, but now I'm >> less happy. I can't seem to compile PIL for Python 2.5 on Snow >> Leopard. >> >> The problem is that when I build and install libjpeg or libpng, it >> builds 64-bit libraries, but Python 2.5 is 32-bit, so the libraries >> don't work when PIL tries to use them. You get an error message >> something like this: > > > Can you try recompiling with "-arch i386 -arch x86_64" options in > the CFLAGS? I think I had gotten this to work for some other > libraries when I ran into the dreaded linking problem. You might > instead need to do CC="gcc -arch..." if the configure tool munges > the CFLAGS too much. > > % CFLAGS="-arch i386 -arch x86_64" ./configure ... > > or > > % CC="gcc -arch..." ./configure ... > > Brad > > -- > Brad Howes > Group 42 > MIT Lincoln Laboratory ? 244 Wood St. ? Lexington, MA 02173 > Phone: 781.981.5292 ? Fax: 781.981.3495 ? Secretary: 781.981.7420 It sounds like the core issue here is that the compiler now builds x86_64 binaries by default on SL. Everything that builds directly through distutils should know to build all the correct architectures, but dependent projects that use standard Makefiles may need to be told to compile 32-bit. Though I haven't tried to build PIL myself, I have built libjpeg and libpng before, and setting CC while running configure as suggested by Brad did work for me. This is an unfortunate side-effect of the transition to full 64-bit computing in Mac OS X, and trying to maintain 32-bit compatibility at the same time. -------------------------------------------------------------------------- Edward Moy Apple Inc. emoy at apple.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From janssen at parc.com Fri Sep 11 23:41:46 2009 From: janssen at parc.com (Bill Janssen) Date: Fri, 11 Sep 2009 14:41:46 PDT Subject: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard In-Reply-To: References: <14881.1252691459@parc.com> Message-ID: <20152.1252705306@parc.com> Brad Howes wrote: > On Sep 11, 2009, at 1:50 PM, Bill Janssen wrote: > > > I was happy to see that Python 2.5 still shipped with SL, but now I'm > > less happy. I can't seem to compile PIL for Python 2.5 on Snow > > Leopard. > > > > The problem is that when I build and install libjpeg or libpng, it > > builds 64-bit libraries, but Python 2.5 is 32-bit, so the libraries > > don't work when PIL tries to use them. You get an error message > > something like this: > > > Can you try recompiling with "-arch i386 -arch x86_64" options in the > CFLAGS? I think I had gotten this to work for some other libraries > when I ran into the dreaded linking problem. You might instead need to > do CC="gcc -arch..." if the configure tool munges the CFLAGS too much. > > % CFLAGS="-arch i386 -arch x86_64" ./configure ... > > or > > % CC="gcc -arch..." ./configure ... > > Brad Thanks, Brad, I've tried this. It does build the .a files multi-platform, but not the dylib files. And some libraries, like libpng, use -M switches which conflict with multiple architecture flags on the compile line. Bill From Chris.Barker at noaa.gov Fri Sep 11 23:54:05 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 11 Sep 2009 14:54:05 -0700 Subject: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard In-Reply-To: References: <14881.1252691459@parc.com> Message-ID: <4AAAC6FD.90800@noaa.gov> Brad Howes wrote: > Can you try recompiling with "-arch i386 -arch x86_64" options in the > CFLAGS? wouldn't you want: "-arch i386 -arch PPC" To be compatible with the python2.5 build? Adding the 64 bit lib wouldn't hurt, but it wouldn't' help, either, unless you want to use it with other things that need it. You may also simply be able to use a binary of PIL. There is this one here: http://pythonmac.org/packages/py25-fat/index.html Which is for the python.org 2.5, but you may be able hand-copy some stuff over. I did set up a build to PIL, using macports to build libjpeg and libpng. They build well using the "universal" variant on a 10.5 Intel system. I'm not sure what macports is building on SL, but it's worth checking out. -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 Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Fri Sep 11 23:55:54 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 11 Sep 2009 14:55:54 -0700 Subject: [Pythonmac-SIG] size of py2app app In-Reply-To: References: Message-ID: <4AAAC76A.9070907@noaa.gov> Charles Hartman 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. Weird. Are you totally sure you're doing the same thing? same python, for instance? Can you get both versions so you can compare them? -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 Chris.Barker at noaa.gov From lists at collab.nl Fri Sep 11 21:02:10 2009 From: lists at collab.nl (Thijs Triemstra | Collab) Date: Fri, 11 Sep 2009 20:02:10 +0100 Subject: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard In-Reply-To: <14881.1252691459@parc.com> References: <14881.1252691459@parc.com> Message-ID: <347D78C2-EB7F-4FDA-BEF6-01036A0637A9@collab.nl> On 11 Sep 2009, at 18:50, Bill Janssen wrote: > I was happy to see that Python 2.5 still shipped with SL, but now I'm > less happy. I can't seem to compile PIL for Python 2.5 on Snow > Leopard. Hm, haven't upgraded to snow leopard yet but i'd expect 2.6 to be in there.. heard they also removed twisted :( Thijs -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: From emoy at apple.com Sat Sep 12 01:13:38 2009 From: emoy at apple.com (Edward Moy) Date: Fri, 11 Sep 2009 16:13:38 -0700 Subject: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard In-Reply-To: <347D78C2-EB7F-4FDA-BEF6-01036A0637A9@collab.nl> References: <14881.1252691459@parc.com> <347D78C2-EB7F-4FDA-BEF6-01036A0637A9@collab.nl> Message-ID: <587C6802-0940-4E97-8335-ED7E16C9A323@apple.com> On Sep 11, 2009, at 12:02 PM, Thijs Triemstra | Collab wrote: > On 11 Sep 2009, at 18:50, Bill Janssen wrote: > >> I was happy to see that Python 2.5 still shipped with SL, but now I'm >> less happy. I can't seem to compile PIL for Python 2.5 on Snow >> Leopard. > > Hm, haven't upgraded to snow leopard yet but i'd expect 2.6 to be in > there.. heard they also removed twisted :( > > Thijs Yes, both 2.5 and 2.6 are available on SL (as well as enough of 2.3 to provide embedded support). Twisted seems to be there: /System/Library/Frameworks/Python.framework/Versions/2.{5,6}/Extras/ lib/python/twisted --------------------------------------------------------------- Edward Moy Apple -------------- next part -------------- An HTML attachment was scrubbed... URL: From janssen at parc.com Sat Sep 12 02:32:41 2009 From: janssen at parc.com (Bill Janssen) Date: Fri, 11 Sep 2009 17:32:41 PDT Subject: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard In-Reply-To: <347D78C2-EB7F-4FDA-BEF6-01036A0637A9@collab.nl> References: <14881.1252691459@parc.com> <347D78C2-EB7F-4FDA-BEF6-01036A0637A9@collab.nl> Message-ID: <26765.1252715561@parc.com> Yes, 2.6 is there, but I thought I'd try building with 2.5. Now, given the issues with 32/64 bit, I think I'm just going to upgrade the OS X UpLib installation to 64 bits, and just use 2.6. Still haven't got the JPEG support in PIL 1.1.6 working that way, but most of the rest seems to work. Bill Thijs Triemstra | Collab wrote: > > On 11 Sep 2009, at 18:50, Bill Janssen wrote: > > > I was happy to see that Python 2.5 still shipped with SL, but now I'm > > less happy. I can't seem to compile PIL for Python 2.5 on Snow > > Leopard. > > Hm, haven't upgraded to snow leopard yet but i'd expect 2.6 to be in > there.. heard they also removed twisted :( > > Thijs > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ssquery at gmail.com Sat Sep 12 08:39:34 2009 From: ssquery at gmail.com (sudhakar s) Date: Sat, 12 Sep 2009 12:09:34 +0530 Subject: [Pythonmac-SIG] .exe r .dmg install Message-ID: <1528d2590909112339t3d45ab86j49bf14bed101d837@mail.gmail.com> Hi, Can we install a .exe or .dmg file from python program itself... -- With Regards, S Sudhakar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From half.italian at gmail.com Sat Sep 12 08:50:50 2009 From: half.italian at gmail.com (Sean DiZazzo) Date: Fri, 11 Sep 2009 23:50:50 -0700 Subject: [Pythonmac-SIG] .exe r .dmg install In-Reply-To: <1528d2590909112339t3d45ab86j49bf14bed101d837@mail.gmail.com> References: <1528d2590909112339t3d45ab86j49bf14bed101d837@mail.gmail.com> Message-ID: <7baa94f60909112350v68be56efp388fc0c182f4d9d6@mail.gmail.com> Yes. py2exe (http://www.py2exe.org/) and py2app ( http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html) These will take a Python program and create an executable file that doesn't rely on any installation of Python or the required libraries. (If the package is created correctly) Is that what you mean?!? ~Sean On Fri, Sep 11, 2009 at 11:39 PM, sudhakar s wrote: > Hi, > Can we install a .exe or .dmg file from python program itself... > > > -- > With Regards, > S Sudhakar. > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From half.italian at gmail.com Sat Sep 12 09:26:11 2009 From: half.italian at gmail.com (Sean DiZazzo) Date: Sat, 12 Sep 2009 00:26:11 -0700 Subject: [Pythonmac-SIG] .exe r .dmg install In-Reply-To: <7baa94f60909112350v68be56efp388fc0c182f4d9d6@mail.gmail.com> References: <1528d2590909112339t3d45ab86j49bf14bed101d837@mail.gmail.com> <7baa94f60909112350v68be56efp388fc0c182f4d9d6@mail.gmail.com> Message-ID: <7baa94f60909120026j6b269633n55b12618316a07e6@mail.gmail.com> >>What i actually my query is there is a .exe file exists in some directory and i need to install that .exe file from my pthon script >>itself either by execution or an by an interactive application.... >>suppose i had an application with button labeled "install" and when i press the button installation of a .exe file or .dmg file should start. ~~~~~ Are you looking for an installer?? Here's one for windows that you can easily adapt to python programs. http://www.jrsoftware.org/isinfo.php If you need a multi-platform installer, you are on your own, but it shouldn't be too difficult. hmm... Cant you do a bit of searching yourself? ~Sean On Fri, Sep 11, 2009 at 11:50 PM, Sean DiZazzo wrote: > Yes. py2exe (http://www.py2exe.org/) and py2app ( > http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html) > > These will take a Python program and create an executable file that doesn't > rely on any installation of Python or the required libraries. (If the > package is created correctly) > > Is that what you mean?!? > > ~Sean > > On Fri, Sep 11, 2009 at 11:39 PM, sudhakar s wrote: > >> Hi, >> Can we install a .exe or .dmg file from python program itself... >> >> >> -- >> With Regards, >> S Sudhakar. >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles.hartman at conncoll.edu Sat Sep 12 19:58:39 2009 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Sat, 12 Sep 2009 13:58:39 -0400 Subject: [Pythonmac-SIG] size of py2app app In-Reply-To: References: Message-ID: <1E49E7E4-615C-419C-A693-EC108C9897B5@conncoll.edu> > Date: Fri, 11 Sep 2009 14:55:54 -0700 > From: Christopher Barker > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] size of py2app app > Message-ID: <4AAAC76A.9070907 at noaa.gov> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Charles Hartman 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 about 95 MB. > > Weird. > > Are you totally sure you're doing the same thing? same python, for > instance? > > Can you get both versions so you can compare them? > > -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 > > Chris.Barker at noaa.gov Certainly the same Python, same wxPython. No different includes. I couldn't see anything except very small local edits I was making in the code that changed between a smaller and a larger build. I'm pretty sure they work the same, too (the small local edits aside), though at the moment I can't get anything but a larger build. For a while I thought deleting the previous build from disk was encouraging py2app to make the smaller version, but now that doesn't seem to have any effect either. From cmiller at securityevaluators.com Sun Sep 13 04:42:12 2009 From: cmiller at securityevaluators.com (Charles Miller) Date: Sat, 12 Sep 2009 21:42:12 -0500 Subject: [Pythonmac-SIG] Using appscript for GUI interaction, button click Message-ID: I'm trying to perform the following applescript with the appscript Python module: tell application "System Events" tell process "Preview" to click button "OK" of every window end tell Is this possible? The closest I got was import appscript appscript.app('System Events').processes['Preview'].windows[1].buttons[1].click() but I get the error: Traceback (most recent call last): File "", line 1, in ? File "build/bdist.macosx-10.3-fat/egg/appscript/reference.py", line 492, in __call__ appscript.reference.CommandError: Command failed: OSERROR: -609 MESSAGE: Connection is invalid. COMMAND: app(u'/System/Library/CoreServices/System Events.app').processes['Preview'].windows[1].buttons[1].click() Any advice or know of documentation that would help me? Thanks. Charlie From geert at nznl.com Sun Sep 13 16:58:31 2009 From: geert at nznl.com (Geert Dekkers) Date: Sun, 13 Sep 2009 16:58:31 +0200 Subject: [Pythonmac-SIG] django webapp using CoreGraphics complains about "wrong architecture" Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hengist.podd at virgin.net Sun Sep 13 18:04:18 2009 From: hengist.podd at virgin.net (has) Date: Sun, 13 Sep 2009 17:04:18 +0100 Subject: [Pythonmac-SIG] Appscript and Snow Leopard In-Reply-To: References: Message-ID: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> 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 From hengist.podd at virgin.net Sun Sep 13 19:52:05 2009 From: hengist.podd at virgin.net (has) Date: Sun, 13 Sep 2009 18:52:05 +0100 Subject: [Pythonmac-SIG] Using appscript for GUI interaction, button click In-Reply-To: References: Message-ID: Charles Miller wrote: > I'm trying to perform the following applescript with the appscript > Python module: > > tell application "System Events" > tell process "Preview" to click button "OK" of every window > end tell If you're not sure how to translate an AppleScript command to the equivalent appscript syntax, ASTranslate is your friend: app(u'System Events').processes[u'Preview'].windows.buttons[u'OK'].click() > import appscript > appscript.app('System > Events').processes['Preview'].windows[1].buttons[1].click() > > but I get the error: > > Traceback (most recent call last): > File "", line 1, in ? > File "build/bdist.macosx-10.3-fat/egg/appscript/reference.py", line > 492, in __call__ > appscript.reference.CommandError: Command failed: > OSERROR: -609 > MESSAGE: Connection is invalid. > COMMAND: app(u'/System/Library/CoreServices/System > Events.app').processes['Preview'].windows[1].buttons[1].click() Error -609 means either the target application unexpectedly quit while handling the event, or the command didn't complete within the allotted timeout period (which should be error -1712, but the Apple Event Manager sometimes returns the wrong code). So does the original AppleScript work? If not, the problem is in what you're trying to do. If it does, then see if the ASTranslate-based translation works. HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net From janssen at parc.com Sun Sep 13 19:52:55 2009 From: janssen at parc.com (Bill Janssen) Date: Sun, 13 Sep 2009 10:52:55 PDT Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> Message-ID: <35735.1252864375@parc.com> Is it possible to disentangle appscript from setuptools? I just downloaded the sources to my Snow Leopard machine, did python setup.py build python setup.py install which went just fine. But then I did % python >>> import appscript and got this big stack trace because a ~/.python-eggs subdirectory wasn't accessible. That shouldn't happen, and I'd like to remove any dependence on setuptools and eggs, if possible. Bill From ronaldoussoren at mac.com Sun Sep 13 20:09:26 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 13 Sep 2009 20:09:26 +0200 Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <35735.1252864375@parc.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> Message-ID: <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> 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. If you install appscript as an unzipped egg the problem should go away. Ronald On 13 sep 2009, at 19:52, Bill Janssen wrote: > Is it possible to disentangle appscript from setuptools? I just > downloaded the sources to my Snow Leopard machine, did > > python setup.py build > python setup.py install > > which went just fine. But then I did > > % python >>>> import appscript > > and got this big stack trace because a ~/.python-eggs subdirectory > wasn't accessible. That shouldn't happen, and I'd like to remove > any dependence on setuptools and eggs, if possible. > > Bill > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From hengist.podd at virgin.net Sun Sep 13 20:30:48 2009 From: hengist.podd at virgin.net (has) Date: Sun, 13 Sep 2009 19:30:48 +0100 Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <35735.1252864375@parc.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> Message-ID: On 13 Sep 2009, at 18:52, Bill Janssen wrote: > Is it possible to disentangle appscript from setuptools? I just > downloaded the sources to my Snow Leopard machine, did > > python setup.py build > python setup.py install > > which went just fine. But then I did > > % python >>>> import appscript > > and got this big stack trace because a ~/.python-eggs subdirectory > wasn't accessible. That shouldn't happen, and I'd like to remove > any dependence on setuptools and eggs, if possible. You can install appscript from source using plain old distutils; the setup.py script will use setuptools if it's available and distutils if not. Though if there are problems with setuptools then I'd suggest filing bug reports on that as well. HTH has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net From aahz at pythoncraft.com Sun Sep 13 21:15:27 2009 From: aahz at pythoncraft.com (Aahz) Date: Sun, 13 Sep 2009 12:15:27 -0700 Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> Message-ID: <20090913191527.GA9094@panix.com> On Sun, Sep 13, 2009, Ronald Oussoren wrote: > > 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. > > If you install appscript as an unzipped egg the problem should go away. My auto-installer for the packages needed by my company's product now includes "-Z" for everything. It also unzips setuptools if needed. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ "It's 106 miles to Chicago. We have a full tank of gas, a half-pack of cigarettes, it's dark, and we're wearing sunglasses." "Hit it." From cmiller at securityevaluators.com Mon Sep 14 04:13:17 2009 From: cmiller at securityevaluators.com (Charles Miller) Date: Sun, 13 Sep 2009 21:13:17 -0500 Subject: [Pythonmac-SIG] Using appscript for GUI interaction, button click In-Reply-To: References:

Message-ID: <4635391A-9478-492D-90B5-89C58E377E25@securityevaluators.com> Yes, that worked, thanks. Also, thanks for the advice to use ASTranslate. I've had no formal idea how to do the translation from apple script to appscript and so mostly just guess and use common sense, which obviously doesn't always work! Thanks again!!! Charlie On Sep 13, 2009, at 12:52 PM, has wrote: > Charles Miller wrote: > >> I'm trying to perform the following applescript with the appscript >> Python module: >> >> tell application "System Events" >> tell process "Preview" to click button "OK" of every window >> end tell > > If you're not sure how to translate an AppleScript command to the > equivalent appscript syntax, ASTranslate is your friend: > > app(u'System > Events').processes[u'Preview'].windows.buttons[u'OK'].click() > > >> import appscript >> appscript.app('System >> Events').processes['Preview'].windows[1].buttons[1].click() >> >> but I get the error: >> >> Traceback (most recent call last): >> File "", line 1, in ? >> File "build/bdist.macosx-10.3-fat/egg/appscript/reference.py", line >> 492, in __call__ >> appscript.reference.CommandError: Command failed: >> OSERROR: -609 >> MESSAGE: Connection is invalid. >> COMMAND: app(u'/System/Library/CoreServices/System >> Events.app').processes['Preview'].windows[1].buttons[1].click() > > > Error -609 means either the target application unexpectedly quit > while handling the event, or the command didn't complete within the > allotted timeout period (which should be error -1712, but the Apple > Event Manager sometimes returns the wrong code). So does the > original AppleScript work? If not, the problem is in what you're > trying to do. If it does, then see if the ASTranslate-based > translation works. > > HTH > > has > > -- > Control AppleScriptable applications from Python, Ruby and ObjC: > http://appscript.sourceforge.net > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From dwf at cs.toronto.edu Mon Sep 14 09:48:02 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Mon, 14 Sep 2009 03:48:02 -0400 Subject: [Pythonmac-SIG] django webapp using CoreGraphics complains about "wrong architecture" In-Reply-To: References: Message-ID: 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. > > (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??? -- 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" 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 at nznl.com Mon Sep 14 16:44:06 2009 From: geert at nznl.com (Geert Dekkers) Date: Mon, 14 Sep 2009 16:44:06 +0200 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 77, Issue 15 In-Reply-To: References: Message-ID: 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. 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 at python.org wrote: > > From: David Warde-Farley > Date: 14 September 2009 9:48:02 AM > To: Pythonmac-Sig 3 > 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 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") > > 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??? -- 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" > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geert at nznl.com Mon Sep 14 17:05:13 2009 From: geert at nznl.com (Geert Dekkers) Date: Mon, 14 Sep 2009 17:05:13 +0200 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 77, Issue 15 In-Reply-To: References: Message-ID: <0DFCCB17-BF71-452A-9686-D4ABA90C70F4@nznl.com> 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/ Python.framework/Versions/2.5/bin/python /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 at python.org wrote: > > From: David Warde-Farley > Date: 14 September 2009 9:48:02 AM > To: Pythonmac-Sig 3 > 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 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") > > 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??? -- 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" > > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janssen at parc.com Mon Sep 14 17:28:00 2009 From: janssen at parc.com (Bill Janssen) Date: Mon, 14 Sep 2009 08:28:00 PDT Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> Message-ID: <42838.1252942080@parc.com> has wrote: > On 13 Sep 2009, at 18:52, Bill Janssen wrote: > > > Is it possible to disentangle appscript from setuptools? I just > > downloaded the sources to my Snow Leopard machine, did > > > > python setup.py build > > python setup.py install > > > > which went just fine. But then I did > > > > % python > >>>> import appscript > > > > and got this big stack trace because a ~/.python-eggs subdirectory > > wasn't accessible. That shouldn't happen, and I'd like to remove > > any dependence on setuptools and eggs, if possible. > > > > You can install appscript from source using plain old distutils; the > setup.py script will use setuptools if it's available and distutils if > not. Though if there are problems with setuptools then I'd suggest > filing bug reports on that as well. I'd like to suggest an option to use distutils even if setuptools is available. Filing bug reports on setuptools seems like a losing proposition; I'd have to understand how it works first. How about *you* file the bug reports there? You're the one using it. Bill From hengist.podd at virgin.net Mon Sep 14 19:21:22 2009 From: hengist.podd at virgin.net (has) Date: Mon, 14 Sep 2009 18:21:22 +0100 Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <42838.1252942080@parc.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> <42838.1252942080@parc.com> Message-ID: <5B3DB134-F1E9-47DF-BE9F-1CCB6D8FFA5A@virgin.net> On 14 Sep 2009, at 16:28, Bill Janssen wrote: > has wrote: > >> You can install appscript from source using plain old distutils; the >> setup.py script will use setuptools if it's available and distutils >> if >> not. Though if there are problems with setuptools then I'd suggest >> filing bug reports on that as well. > > I'd like to suggest an option to use distutils even if setuptools is > available. Don't know how that could be done automatically as both use the same setup.py file. If you want to do it manually, replace the first five lines in the setup.py script with this: from distutils.core import setup, Extension > Filing bug reports on setuptools seems like a losing proposition; I'd > have to understand how it works first. How about *you* file the bug > reports there? You're the one using it. I've not had any problems using it myself. Regards, has -- Control AppleScriptable applications from Python, Ruby and ObjC: http://appscript.sourceforge.net From ronaldoussoren at mac.com Mon Sep 14 19:27:39 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 14 Sep 2009 19:27:39 +0200 Subject: [Pythonmac-SIG] Link against Python Framework In-Reply-To: <3284BBCF-530D-470D-94FB-DFE3CD07AA24@gmx.de> References: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> <31927653636730773104506838970680462354-Webmail@me.com> <4AA7B6A0.6050407@codebykevin.com> <7346298F-8203-4CBC-9F1F-4D817E76C154@threeve.org> <3284BBCF-530D-470D-94FB-DFE3CD07AA24@gmx.de> Message-ID: On 10 Sep, 2009, at 12:09, Georg Seifert wrote: >> >> If you want to make absolutely sure that Apple can't break you, you >> could bundle the version of Python.framework upon which you depend >> into your app. However, that's probably not necessary unless you >> want to use a newer version of Python than the system has (say, >> 3.0+, or 2.6 on Leopard). > > How do I specify the version to link with. > The 10.5 SDK links against python 2.5 and the 10.6 SDK to 2.6. But > what if I need the 10.6 SKD but want to link to python 2.5? Don't compile and link using the "-framework" flag, but use the 'python-config' command to get the right compiler flags for linking and compiling. The python-config command is located inside the framework (such as /System/Library/Frameworks/Python.framework/ Versions/2.5/bin/python-config). If you are using Xcode you can hardcode the output of this command into your Xcode project, you don't have to run python-config every time you compile. Ronald > > Regards > Georg > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From charles.hartman at conncoll.edu Tue Sep 15 19:25:56 2009 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Tue, 15 Sep 2009 13:25:56 -0400 Subject: [Pythonmac-SIG] Fwd: size of py2app app References: <1528d2590909122319g5037cb8bp1d8089f19c865459@mail.gmail.com> Message-ID: <0A36CC53-4D90-4E8E-AA7C-B14BB2D3C85B@conncoll.edu> 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 > Date: September 13, 2009 2:19:30 AM EDT > To: Charles Hartman > 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 > 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 at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > > > -- > With Regards, > S Sudhakar. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jerry.levan at eku.edu Wed Sep 16 15:31:15 2009 From: jerry.levan at eku.edu (Jerry LeVan) Date: Wed, 16 Sep 2009 09:31:15 -0400 Subject: [Pythonmac-SIG] Building packages under Snow Leopard and Python 2.6.x Message-ID: <7FD54A88-9D22-46C8-B25E-7D21EFCCF6A5@eku.edu> 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 From van.lindberg at gmail.com Wed Sep 16 19:54:39 2009 From: van.lindberg at gmail.com (VanL) Date: Wed, 16 Sep 2009 12:54:39 -0500 Subject: [Pythonmac-SIG] django webapp using CoreGraphics complains about "wrong architecture" In-Reply-To: References:

Message-ID: 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 From emanuelesantos at gmail.com Wed Sep 16 21:21:26 2009 From: emanuelesantos at gmail.com (Emanuele Santos) Date: Wed, 16 Sep 2009 13:21:26 -0600 Subject: [Pythonmac-SIG] Building packages under Snow Leopard and Python 2.6.x In-Reply-To: <7FD54A88-9D22-46C8-B25E-7D21EFCCF6A5@eku.edu> References: <7FD54A88-9D22-46C8-B25E-7D21EFCCF6A5@eku.edu> Message-ID: Try using gcc 4.0, Snow Leopard is using gcc-4.2 by default. export CC=/usr/bin/gcc-4.0 export CXX=/usr/bin/g++-4.0 -- Emanuele. On Sep 16, 2009, at 7:31 AM, Jerry LeVan wrote: > 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 > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From woklist at kyngchaos.com Wed Sep 16 22:38:07 2009 From: woklist at kyngchaos.com (William Kyngesburye) Date: Wed, 16 Sep 2009 15:38:07 -0500 Subject: [Pythonmac-SIG] Building packages under Snow Leopard and Python 2.6.x In-Reply-To: References: <7FD54A88-9D22-46C8-B25E-7D21EFCCF6A5@eku.edu> Message-ID: <55D81655-B9A9-436B-B3DC-675BDD44B60E@kyngchaos.com> I used this without any problems: export PATH="/usr/local/pgsql/bin:$PATH" export ARCHFLAGS="-arch i386" python setup.py build Compilation is correctly using gcc-4.2 and the 10.6 sdk. This is with the system python. Did you install Python from python.org? They probably have the distutils using the 10.4 SDK and ppc+intel. This needs gcc-4.0, but 'gcc' will run 4.2, as Emanuele pointed out. On Sep 16, 2009, at 2:21 PM, Emanuele Santos wrote: > Try using gcc 4.0, Snow Leopard is using gcc-4.2 by default. > > export CC=/usr/bin/gcc-4.0 > export CXX=/usr/bin/g++-4.0 > > -- Emanuele. > > On Sep 16, 2009, at 7:31 AM, Jerry LeVan wrote: > >> 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? ----- William Kyngesburye http://www.kyngchaos.com/ "History is an illusion caused by the passage of time, and time is an illusion caused by the passage of history." - Hitchhiker's Guide to the Galaxy From Jerry.Levan at EKU.EDU Thu Sep 17 01:27:36 2009 From: Jerry.Levan at EKU.EDU (Jerry LeVan) Date: Wed, 16 Sep 2009 19:27:36 -0400 Subject: [Pythonmac-SIG] Building packages under Snow Leopard and Python 2.6.x In-Reply-To: <55D81655-B9A9-436B-B3DC-675BDD44B60E@kyngchaos.com> References: <7FD54A88-9D22-46C8-B25E-7D21EFCCF6A5@eku.edu> <55D81655-B9A9-436B-B3DC-675BDD44B60E@kyngchaos.com> Message-ID: <4052CA6E-6828-448B-A48C-302DBC3A2A9C@EKU.EDU> On Sep 16, 2009, at 4:38 PM, William Kyngesburye wrote: > I used this without any problems: > > export PATH="/usr/local/pgsql/bin:$PATH" > export ARCHFLAGS="-arch i386" > > python setup.py build > > > Compilation is correctly using gcc-4.2 and the 10.6 sdk. This is with > the system python. > > Did you install Python from python.org? They probably have the > distutils using the 10.4 SDK and ppc+intel. This needs gcc-4.0, but > 'gcc' will run 4.2, as Emanuele pointed out. > > On Sep 16, 2009, at 2:21 PM, Emanuele Santos wrote: > >> Try using gcc 4.0, Snow Leopard is using gcc-4.2 by default. >> >> export CC=/usr/bin/gcc-4.0 >> export CXX=/usr/bin/g++-4.0 >> >> -- Emanuele. >> Thank you Emanuele and William :) I did the gcc-4.0 thingee and it appears to be working... I do have the 2.6.2 from python.org. I will try to build the psycopg for the apple 2.6 version after I run through some more tests with the python.org version. Jerry From vip at avatar.com.au Thu Sep 17 04:48:30 2009 From: vip at avatar.com.au (DavidW) Date: Thu, 17 Sep 2009 12:48:30 +1000 Subject: [Pythonmac-SIG] resuming python job Message-ID: <04E3347F-B1EA-4D5B-AFAC-BDE632E2453B@avatar.com.au> 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 From leknarf at pacbell.net Thu Sep 17 06:52:15 2009 From: leknarf at pacbell.net (Scott Frankel) Date: Wed, 16 Sep 2009 21:52:15 -0700 Subject: [Pythonmac-SIG] py2app cannot move to target thread error In-Reply-To: <48A2335B-B7DA-4EAE-8659-5EE80F8919CE@pacbell.net> References: <8ACF0495-1315-49E3-AA61-97642257A1ED@pacbell.net> <49EE8EAF-12F4-4C96-9392-AF3895D876B1@pacbell.net> <48A2335B-B7DA-4EAE-8659-5EE80F8919CE@pacbell.net> Message-ID: <8AB6F67C-ACA7-40BD-AEA8-DE69A905B992@pacbell.net> Hi all, 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. Might there be a setup.py solution? Do I need to dig back into my macports installations? How can I locate the source of the offending item? Thanks in advance for any suggestions! I'd be much obliged. Scott On Aug 24, 2009, at 9:49 PM, Scott Frankel wrote: > > If someone has any wisdom to share regarding building a PyQt app > with SQL support, I'd be grateful. > > > I've deleted and rebuilt my macports environment from scratch and > googled myself silly. In a classic snake-eating-tail moment, my > online searches are returning my own posts more often than not. > > My test apps that call for either QPSQL or QSQLITE die, while my > test app that does not include PyQt4.QtSql continues to build and > run happily. Setting the DYLD_PRINT_LIBRARIES env var, yields the > following output on app launch: > > Qt Version: 4.5.2 > PyQt Version: 4.5.4 > 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 (0x1da760) is not the object's > thread (0x1b1b10). > Cannot move to target thread (0x1b1b10) > > 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. > > > My macports environment looks like this: > > ... > postgresql83 @8.3.1_0 (active) > ... > py26-altgraph @0.6.7_0 (active) > py26-bdist_mpkg @0.4.4_0 (active) > py26-macholib @1.2_0 (active) > py26-modulegraph-devel @0.7.2_0 (active) > py26-py2app-devel @0.4.2_1 (active) > py26-pyqt4 @4.5.4_0 (active) > py26-setuptools @0.6c9_0 (active) > py26-sip @4.8.2_0 (active) > ... > qt4-mac @4.5.2_1+psql (active) > ... > > > Any thoughts or suggestions? > > Thanks! > Scott > > > > > > > On Aug 19, 2009, at 10:41 AM, Scott Frankel wrote: > >> >> Hello, >> >> I'm stuck somewhere between macports and py2app. I'm hopeful that >> someone here may be able to offer some advice on how to rectify my >> build environment. >> >> Exporting DYLD_PRINT_LIBRARIES=1 and running a test app built with >> QtSql support and another one without it, I'm pretty sure that the >> following line is the clue: >> >> dyld: loaded: /opt/local/libexec/qt4-mac/plugins/sqldrivers/ >> libqsqlpsql.bundle >> >> My question is, how do I access/get/compile the PSQL support my app >> requires? My environment's qt4-mac, python26, and py2app are from >> macports. The qt4-mac has the psql dependency: >> >> py26-py2app-devel @0.4.2_1 (active) >> py26-pyqt4 @4.5.4_0 (active) >> qt4-mac @4.5.1_0+psql (active) >> >> Thanks in advance! >> Scott >> >> >> >> >> >> On Aug 10, 2009, at 8:51 AM, Scott Frankel wrote: >> >>> >>> 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 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > From geert at nznl.com Thu Sep 17 13:07:02 2009 From: geert at nznl.com (Geert Dekkers) Date: Thu, 17 Sep 2009 13:07:02 +0200 Subject: [Pythonmac-SIG] django webapp using CoreGraphics complains about "wrong architecture" In-Reply-To: References: Message-ID: <3456CE75-1790-45E6-ADEB-25DB6C989ED9@nznl.com> Would this then mean that PIL would also fail complaining about "wrong architecture" when running under 64-bit Apache? Geert > > > From: VanL > Date: 16 September 2009 7:54:39 PM > To: pythonmac-sig at 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From p at ulmcnett.com Thu Sep 17 17:55:38 2009 From: p at ulmcnett.com (Paul McNett) Date: Thu, 17 Sep 2009 08:55:38 -0700 Subject: [Pythonmac-SIG] resuming python job In-Reply-To: <04E3347F-B1EA-4D5B-AFAC-BDE632E2453B@avatar.com.au> References: <04E3347F-B1EA-4D5B-AFAC-BDE632E2453B@avatar.com.au> Message-ID: <4AB25BFA.7040704@ulmcnett.com> 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 From Chris.Barker at noaa.gov Thu Sep 17 19:49:27 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 17 Sep 2009 10:49:27 -0700 Subject: [Pythonmac-SIG] Fwd: size of py2app app In-Reply-To: <0A36CC53-4D90-4E8E-AA7C-B14BB2D3C85B@conncoll.edu> References: <1528d2590909122319g5037cb8bp1d8089f19c865459@mail.gmail.com> <0A36CC53-4D90-4E8E-AA7C-B14BB2D3C85B@conncoll.edu> Message-ID: <4AB276A7.8040107@noaa.gov> 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/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Thu Sep 17 19:51:22 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 17 Sep 2009 10:51:22 -0700 Subject: [Pythonmac-SIG] django webapp using CoreGraphics complains about "wrong architecture" In-Reply-To: References:

Message-ID: <4AB2771A.70009@noaa.gov> 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/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From daniel at keystonewood.com Thu Sep 17 19:55:52 2009 From: daniel at keystonewood.com (Daniel Miller) Date: Thu, 17 Sep 2009 13:55:52 -0400 Subject: [Pythonmac-SIG] py2app cannot move to target thread error In-Reply-To: <8AB6F67C-ACA7-40BD-AEA8-DE69A905B992@pacbell.net> References: <8ACF0495-1315-49E3-AA61-97642257A1ED@pacbell.net> <49EE8EAF-12F4-4C96-9392-AF3895D876B1@pacbell.net> <48A2335B-B7DA-4EAE-8659-5EE80F8919CE@pacbell.net> <8AB6F67C-ACA7-40BD-AEA8-DE69A905B992@pacbell.net> Message-ID: > 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 From p at ulmcnett.com Thu Sep 17 20:23:27 2009 From: p at ulmcnett.com (Paul McNett) Date: Thu, 17 Sep 2009 11:23:27 -0700 Subject: [Pythonmac-SIG] Fwd: size of py2app app In-Reply-To: <4AB276A7.8040107@noaa.gov> References: <1528d2590909122319g5037cb8bp1d8089f19c865459@mail.gmail.com> <0A36CC53-4D90-4E8E-AA7C-B14BB2D3C85B@conncoll.edu> <4AB276A7.8040107@noaa.gov> Message-ID: <4AB27E9F.8080203@ulmcnett.com> 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 From Chris.Barker at noaa.gov Thu Sep 17 21:04:06 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 17 Sep 2009 12:04:06 -0700 Subject: [Pythonmac-SIG] Fwd: size of py2app app In-Reply-To: <4AB27E9F.8080203@ulmcnett.com> References: <1528d2590909122319g5037cb8bp1d8089f19c865459@mail.gmail.com> <0A36CC53-4D90-4E8E-AA7C-B14BB2D3C85B@conncoll.edu> <4AB276A7.8040107@noaa.gov> <4AB27E9F.8080203@ulmcnett.com> Message-ID: <4AB28826.9050208@noaa.gov> 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/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From dwf at cs.toronto.edu Thu Sep 17 21:36:58 2009 From: dwf at cs.toronto.edu (David Warde-Farley) Date: Thu, 17 Sep 2009 15:36:58 -0400 Subject: [Pythonmac-SIG] django webapp using CoreGraphics complains about "wrong architecture" In-Reply-To: <3456CE75-1790-45E6-ADEB-25DB6C989ED9@nznl.com> References: <3456CE75-1790-45E6-ADEB-25DB6C989ED9@nznl.com> Message-ID: <09035900-E0E3-4F47-BC1A-04C7405905BC@cs.toronto.edu> 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 From janssen at parc.com Thu Sep 17 23:50:45 2009 From: janssen at parc.com (Bill Janssen) Date: Thu, 17 Sep 2009 14:50:45 PDT Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> Message-ID: <1676.1253224245@parc.com> Ronald Oussoren 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 From aahz at pythoncraft.com Fri Sep 18 01:47:22 2009 From: aahz at pythoncraft.com (Aahz) Date: Thu, 17 Sep 2009 16:47:22 -0700 Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <1676.1253224245@parc.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> <1676.1253224245@parc.com> Message-ID: <20090917234722.GB26785@panix.com> On Thu, Sep 17, 2009, Bill Janssen wrote: > Ronald Oussoren 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 (aahz at 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 From nad at acm.org Fri Sep 18 03:04:56 2009 From: nad at acm.org (Ned Deily) Date: Thu, 17 Sep 2009 18:04:56 -0700 Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> <1676.1253224245@parc.com> <20090917234722.GB26785@panix.com> Message-ID: In article <20090917234722.GB26785 at panix.com>, Aahz wrote: > On Thu, Sep 17, 2009, Bill Janssen wrote: > > Ronald Oussoren 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, nad at acm.org From leknarf at pacbell.net Fri Sep 18 07:52:27 2009 From: leknarf at pacbell.net (Scott Frankel) Date: Thu, 17 Sep 2009 22:52:27 -0700 Subject: [Pythonmac-SIG] py2app cannot move to target thread error In-Reply-To: References: <8ACF0495-1315-49E3-AA61-97642257A1ED@pacbell.net> <49EE8EAF-12F4-4C96-9392-AF3895D876B1@pacbell.net> <48A2335B-B7DA-4EAE-8659-5EE80F8919CE@pacbell.net> <8AB6F67C-ACA7-40BD-AEA8-DE69A905B992@pacbell.net> Message-ID: 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 > > > From ronaldoussoren at mac.com Fri Sep 18 08:10:15 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 18 Sep 2009 08:10:15 +0200 Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <1676.1253224245@parc.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> <1676.1253224245@parc.com> Message-ID: <083B8569-2B30-4D11-AA98-2C6A535B3B91@mac.com> On 17 Sep, 2009, at 23:50, Bill Janssen wrote: > Ronald Oussoren 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? Either "python setup.py bdist_egg" and then use the right flags to easy_install; or add 'zip_safe = False' to the arguments of setup() in setup.py install install using "python setup.py install". Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From ronaldoussoren at mac.com Fri Sep 18 08:11:31 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 18 Sep 2009 08:11:31 +0200 Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <1676.1253224245@parc.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> <1676.1253224245@parc.com> Message-ID: <4D1D4CA7-55E6-4516-BA43-E51AF9DFCC8D@mac.com> On 17 Sep, 2009, at 23:50, Bill Janssen wrote: > Ronald Oussoren 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. That's news to me. I've been using zipped eggs with 2.6 without any problems. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From janssen at parc.com Fri Sep 18 17:48:34 2009 From: janssen at parc.com (Bill Janssen) Date: Fri, 18 Sep 2009 08:48:34 PDT Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <083B8569-2B30-4D11-AA98-2C6A535B3B91@mac.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> <1676.1253224245@parc.com> <083B8569-2B30-4D11-AA98-2C6A535B3B91@mac.com> Message-ID: <6942.1253288914@parc.com> Ronald Oussoren wrote: > > On 17 Sep, 2009, at 23:50, Bill Janssen wrote: > > > Ronald Oussoren 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? > > Either "python setup.py bdist_egg" and then use the right flags to > easy_install; or add 'zip_safe = False' to the arguments of setup() in > setup.py install install using "python setup.py install". Thanks, Ronald. Hmmm. Neither seems ideal. The first idea involves actually *using* setuptools (easy_install), and the second involves editing the setup.py file. I suppose I could use "python setup.py bdist_egg", then use "unzip" to unpack it in the right place, too. Bill From janssen at parc.com Fri Sep 18 17:50:57 2009 From: janssen at parc.com (Bill Janssen) Date: Fri, 18 Sep 2009 08:50:57 PDT Subject: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools... In-Reply-To: <4D1D4CA7-55E6-4516-BA43-E51AF9DFCC8D@mac.com> References: <29E5E950-722B-465A-AE84-FA18CCD99DA0@virgin.net> <35735.1252864375@parc.com> <4DBF109B-5A68-4AA4-9071-8AB72AB2800F@mac.com> <1676.1253224245@parc.com> <4D1D4CA7-55E6-4516-BA43-E51AF9DFCC8D@mac.com> Message-ID: <7020.1253289057@parc.com> Ronald Oussoren wrote: > > Yes, that's part of the problem. The other part is that .pth handling > > seems to have changed from 2.5 to 2.6. > > That's news to me. I've been using zipped eggs with 2.6 without any > problems. Don't know that it had anything to do with eggs. What I was seeing was different sys.path construction between 2.5 and 2.6, both on SL. In 2.5, it went through and added the directories specified by .pth files in /Library/Python/2.5/site-packages; in 2.6, it didn't. Perhaps I'm just misunderstanding the way the processing of .pth files works. Bill From Chris.Barker at noaa.gov Fri Sep 18 18:31:18 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 18 Sep 2009 09:31:18 -0700 Subject: [Pythonmac-SIG] py2app cannot move to target thread error In-Reply-To: References: <8ACF0495-1315-49E3-AA61-97642257A1ED@pacbell.net> <49EE8EAF-12F4-4C96-9392-AF3895D876B1@pacbell.net> <48A2335B-B7DA-4EAE-8659-5EE80F8919CE@pacbell.net> <8AB6F67C-ACA7-40BD-AEA8-DE69A905B992@pacbell.net>

Message-ID: <4AB3B5D6.9070001@noaa.gov> Scott Frankel wrote: > 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. Ideally, when you've got it figured out, it could be turned into a py2app recipe and contributed to trunk -- hint, hint! -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 Chris.Barker at noaa.gov From janssen at parc.com Sat Sep 19 00:53:57 2009 From: janssen at parc.com (Bill Janssen) Date: Fri, 18 Sep 2009 15:53:57 PDT Subject: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard? Message-ID: <17945.1253314437@parc.com> 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 From woklist at kyngchaos.com Sat Sep 19 01:28:47 2009 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri, 18 Sep 2009 18:28:47 -0500 Subject: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard? In-Reply-To: <17945.1253314437@parc.com> References: <17945.1253314437@parc.com> Message-ID: If you run the CLI 'uname -m' on any Intel Mac, it always has returned i386. So all it really means is 'Intel'. On Sep 18, 2009, at 5:53 PM, Bill Janssen wrote: > 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 > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan From janssen at parc.com Sat Sep 19 02:05:10 2009 From: janssen at parc.com (Bill Janssen) Date: Fri, 18 Sep 2009 17:05:10 PDT Subject: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard? In-Reply-To: References: <17945.1253314437@parc.com> Message-ID: <20687.1253318710@parc.com> William Kyngesburye wrote: > If you run the CLI 'uname -m' on any Intel Mac, it always has returned > i386. So all it really means is 'Intel'. > > On Sep 18, 2009, at 5:53 PM, Bill Janssen wrote: > > > 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', ''). Hmmm. So what's the pythonic way of getting i386 vs. x86_64? {'32bit': 'i386', '64bit': 'x86_64'}[platform.architecture()[0]] seems so complicated that there should be a routine for it in sys or platform. Bill From emoy at apple.com Sat Sep 19 02:15:22 2009 From: emoy at apple.com (emoy at apple.com) Date: Fri, 18 Sep 2009 17:15:22 -0700 Subject: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard? In-Reply-To: <20687.1253318710@parc.com> References: <17945.1253314437@parc.com> <20687.1253318710@parc.com> Message-ID: <2C5CF1AD-F4B1-4345-A077-84365482C432@apple.com> On Sep 18, 2009, at 5:05 PM, Bill Janssen wrote: > William Kyngesburye wrote: > >> If you run the CLI 'uname -m' on any Intel Mac, it always has >> returned >> i386. So all it really means is 'Intel'. >> >> On Sep 18, 2009, at 5:53 PM, Bill Janssen wrote: >> >>> 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', ''). > > Hmmm. So what's the pythonic way of getting i386 vs. x86_64? > > {'32bit': 'i386', '64bit': 'x86_64'}[platform.architecture()[0]] > > seems so complicated that there should be a routine for it in sys or > platform. I don't know the "official" way, but what I do is: % python -c 'import sys;print sys.maxint' 9223372036854775807 % env VERSIONER_PYTHON_PREFER_32_BIT=1 python -c 'import sys;print sys.maxint' 2147483647 So I would look at sys.maxint to determine if python is running 32 or 64-bit. Ed From janssen at parc.com Sat Sep 19 02:46:38 2009 From: janssen at parc.com (Bill Janssen) Date: Fri, 18 Sep 2009 17:46:38 PDT Subject: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard? In-Reply-To: <2C5CF1AD-F4B1-4345-A077-84365482C432@apple.com> References: <17945.1253314437@parc.com> <20687.1253318710@parc.com> <2C5CF1AD-F4B1-4345-A077-84365482C432@apple.com> Message-ID: <14963.1253321198@parc.com> I think I'm just going to put '32bit' or '64bit' in my installer name strings. Bill emoy at apple.com wrote: > On Sep 18, 2009, at 5:05 PM, Bill Janssen wrote: > > > William Kyngesburye wrote: > > > >> If you run the CLI 'uname -m' on any Intel Mac, it always has > >> returned > >> i386. So all it really means is 'Intel'. > >> > >> On Sep 18, 2009, at 5:53 PM, Bill Janssen wrote: > >> > >>> 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', ''). > > > > Hmmm. So what's the pythonic way of getting i386 vs. x86_64? > > > > {'32bit': 'i386', '64bit': 'x86_64'}[platform.architecture()[0]] > > > > seems so complicated that there should be a routine for it in sys or > > platform. > > I don't know the "official" way, but what I do is: > > % python -c 'import sys;print sys.maxint' > 9223372036854775807 > % env VERSIONER_PYTHON_PREFER_32_BIT=1 python -c 'import sys;print > sys.maxint' > 2147483647 > > So I would look at sys.maxint to determine if python is running 32 or > 64-bit. > > Ed From maparent at acm.org Sat Sep 19 15:31:53 2009 From: maparent at acm.org (Marc-Antoine Parent) Date: Sat, 19 Sep 2009 09:31:53 -0400 Subject: [Pythonmac-SIG] py2app sip recipe and Qt plugins References: <654BE7C7-F782-4FCB-8C97-EC97199DD1D0@gmail.com> Message-ID: 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//Contents/plugins b) Create a file dist//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//Contents/plugins -type f -exec install_name_tool -change QtGui.framework/Versions/4/QtGui @executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui {} ';' find dist//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 QtWebKit etc.) Cheers, Marc-Antoine Parent From ed_hartley at mac.com Sat Sep 19 18:54:57 2009 From: ed_hartley at mac.com (Edward Hartley) Date: Sat, 19 Sep 2009 17:54:57 +0100 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 77, Issue 16 In-Reply-To: References: Message-ID: <8557C82D-5166-4E4C-8962-D6929C633E5E@mac.com> On 14 Sep 2009, at 16:05, pythonmac-sig-request at python.org wrote: > Send Pythonmac-SIG mailing list submissions to > pythonmac-sig at 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 at python.org > > You can reach the person managing the list at > pythonmac-sig-owner at 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 > Date: 14 September 2009 15:44:06 BST > To: pythonmac-sig at 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 at python.org wrote: > > > From: David Warde-Farley > Date: 14 September 2009 9:48:02 AM > To: Pythonmac-Sig 3 > 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 > Date: 14 September 2009 16:05:13 BST > To: pythonmac-sig at 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 at python.org wrote: > >> >> From: David Warde-Farley >> Date: 14 September 2009 9:48:02 AM >> To: pythonmac-sig at 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 >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emoy at apple.com Sat Sep 19 21:47:43 2009 From: emoy at apple.com (Edward Moy) Date: Sat, 19 Sep 2009 12:47:43 -0700 Subject: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard? In-Reply-To: <14963.1253321198@parc.com> References: <17945.1253314437@parc.com> <20687.1253318710@parc.com> <2C5CF1AD-F4B1-4345-A077-84365482C432@apple.com> <14963.1253321198@parc.com> Message-ID: <24BD2C73-A5CE-406B-891A-78A27504D91A@apple.com> I looked into the code for platform.architecture(), and it basically runs the "file" command on /usr/bin/python. If the output contains the string "64-bit", it will return "64bit" as the first tuple. So it depends on what real question you are trying to answer, because in SnowLeopard, /usr/bin/python is a wrapper program that does all the versioning, reading preference files, etc, and is independent of the real python executable: /System/Library/Frameworks/Python.framework/ Versions/2.6/Resources/Python.app/Contents/MacOS/Python. Testing sys.maxint answers the question whether the current python in running in 32 or 64-bit mode. platform.architecture() just tells if the wrapper is "capable" of running 64-bit (it will run 64-bit by default on 64-bit architectures, but could actually be running 32-bit, either by choice or on 32-bit only hardware), and doesn't say anything about the real python executable. Ed On Sep 18, 2009, at 5:46 PM, Bill Janssen wrote: > I think I'm just going to put '32bit' or '64bit' in my installer > name strings. > > Bill > > emoy at apple.com wrote: > >> On Sep 18, 2009, at 5:05 PM, Bill Janssen wrote: >> >>> William Kyngesburye wrote: >>> >>>> If you run the CLI 'uname -m' on any Intel Mac, it always has >>>> returned >>>> i386. So all it really means is 'Intel'. >>>> >>>> On Sep 18, 2009, at 5:53 PM, Bill Janssen wrote: >>>> >>>>> 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', ''). >>> >>> Hmmm. So what's the pythonic way of getting i386 vs. x86_64? >>> >>> {'32bit': 'i386', '64bit': 'x86_64'}[platform.architecture()[0]] >>> >>> seems so complicated that there should be a routine for it in sys or >>> platform. >> >> I don't know the "official" way, but what I do is: >> >> % python -c 'import sys;print sys.maxint' >> 9223372036854775807 >> % env VERSIONER_PYTHON_PREFER_32_BIT=1 python -c 'import sys;print >> sys.maxint' >> 2147483647 >> >> So I would look at sys.maxint to determine if python is running 32 or >> 64-bit. >> >> Ed From janssen at parc.com Sat Sep 19 22:37:22 2009 From: janssen at parc.com (Bill Janssen) Date: Sat, 19 Sep 2009 13:37:22 PDT Subject: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard? In-Reply-To: <24BD2C73-A5CE-406B-891A-78A27504D91A@apple.com> References: <17945.1253314437@parc.com> <20687.1253318710@parc.com> <2C5CF1AD-F4B1-4345-A077-84365482C432@apple.com> <14963.1253321198@parc.com> <24BD2C73-A5CE-406B-891A-78A27504D91A@apple.com> Message-ID: <18114.1253392642@parc.com> You could also use other test I've seen: def arch(): import ctypes return {4: "i386", 8: "x86_64"}[ctypes.sizeof(ctypes.c_size_t)] Bill From bhaskar.jain2002 at gmail.com Thu Sep 10 06:55:07 2009 From: bhaskar.jain2002 at gmail.com (bhaskar jain) Date: Thu, 10 Sep 2009 10:25:07 +0530 Subject: [Pythonmac-SIG] [BangPypers] python-sap webservices In-Reply-To: <1528d2590909092132k44a20594o7172e099edeee375@mail.gmail.com> References: <1528d2590909092132k44a20594o7172e099edeee375@mail.gmail.com> Message-ID: <7f2cbc970909092155t29610750k31187232116b9079@mail.gmail.com> "__future__ is a special module used to change the behaviour of the parser, so it is extremely important that it occur in the beginning of your module. Just move the imports to the top of your code, and that's all there is to it." On Thu, Sep 10, 2009 at 10:02 AM, sudhakar s wrote: > Hi, This is sudhakar, i am using python frame work and now concentrating > on working on web services in python. > I installed SOAPpy-0.12.0 on mac but getting errors as below: > > venj:SOAPpy-0.12.0 venkata$ python setup.py build > > Traceback (most recent call last): > > File "setup.py", line 8, in > from SOAPpy.version import __version__ > File "/Applications/SOAPpy-0.12.0/SOAPpy/__init__.py", line 5, in > > from Client import * > File "/Applications/SOAPpy-0.12.0/SOAPpy/Client.py", line 46 > from __future__ import nested_scopes > > SyntaxError: from __future__ imports must occur at the beginning of the > file > > venj:SOAPpy-0.12.0 venkata$ python setup.py install > > Traceback (most recent call last): > File "setup.py", line 8, in > from SOAPpy.version import __version__ > File "/Applications/SOAPpy-0.12.0/SOAPpy/__init__.py", line 5, in > > from Client import * > File "/Applications/SOAPpy-0.12.0/SOAPpy/Client.py", line 46 > from __future__ import nested_scopes > SyntaxError: from __future__ imports must occur at the beginning of the > file > > Hey please suggest me how to solve this error. > > Hey actually whats my requirement is i need to gather information from SAP > system and Store it in Python appliction server. > For this i am thinking to construct a web service on python in order to get > the data from SAP system. Is this the correct way or is there > any other possibility get in formation and store it in python application > and i use mysql database for python. > > Please give your valuable suggestion. > > Waiting for early reply. > > with regards > S Sudhakar. > > _______________________________________________ > BangPypers mailing list > BangPypers at python.org > http://mail.python.org/mailman/listinfo/bangpypers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason at threeve.org Thu Sep 10 17:29:18 2009 From: jason at threeve.org (Jason Foreman) Date: Thu, 10 Sep 2009 10:29:18 -0500 Subject: [Pythonmac-SIG] Link against Python Framework In-Reply-To: <3284BBCF-530D-470D-94FB-DFE3CD07AA24@gmx.de> References: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> <31927653636730773104506838970680462354-Webmail@me.com> <4AA7B6A0.6050407@codebykevin.com> <7346298F-8203-4CBC-9F1F-4D817E76C154@threeve.org> <3284BBCF-530D-470D-94FB-DFE3CD07AA24@gmx.de> Message-ID: On Sep 10, 2009, at 5:09 AM, Georg Seifert wrote: >> >> If you want to make absolutely sure that Apple can't break you, you >> could bundle the version of Python.framework upon which you depend >> into your app. However, that's probably not necessary unless you >> want to use a newer version of Python than the system has (say, >> 3.0+, or 2.6 on Leopard). > > How do I specify the version to link with. > The 10.5 SDK links against python 2.5 and the 10.6 SDK to 2.6. But > what if I need the 10.6 SKD but want to link to python 2.5? This is a good question, and I'm sorry to say I haven't got an answer for you. I'm not sure how to specify which framework version to link when you add a framework that contains multiple versions. What I would probably do myself at that point is to compile a Python 2.5 framework of my own, and embed it into my app. I'll try to look for ways to specify a specific framework version to link against and let you know if I find anything. Jason -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From jason at threeve.org Fri Sep 11 15:50:36 2009 From: jason at threeve.org (Jason Foreman) Date: Fri, 11 Sep 2009 08:50:36 -0500 Subject: [Pythonmac-SIG] Link against Python Framework In-Reply-To: References: <6A9679BC-726D-444C-BA39-BE9EE958E880@gmx.de> <31927653636730773104506838970680462354-Webmail@me.com> <4AA7B6A0.6050407@codebykevin.com> <7346298F-8203-4CBC-9F1F-4D817E76C154@threeve.org> <3284BBCF-530D-470D-94FB-DFE3CD07AA24@gmx.de> Message-ID: <5555A210-F027-49FB-99B2-0F81780AC28A@threeve.org> On Sep 10, 2009, at 10:29 AM, Jason Foreman wrote: > On Sep 10, 2009, at 5:09 AM, Georg Seifert wrote: >> >> How do I specify the version to link with. >> The 10.5 SDK links against python 2.5 and the 10.6 SDK to 2.6. But >> what if I need the 10.6 SKD but want to link to python 2.5? > > I'll try to look for ways to specify a specific framework version to > link against and let you know if I find anything. I did find a way to use the 10.6 SDK but still link with Python 2.5. However I'd classify this as a 'dirty hack' so I'm not sure I could recommend it. When the linker is linking to a framework, it expects to find (a link to) the framework binary at Foo.framework/Foo (e.g. Python.framework/ Python). In the real framework, this is just a symlink to Python.framework/Versions/Current/Python, which is of course the 2.6 version of Python. We can exploit the fact that same-named frameworks that exist in a user-specified framework search path will be used before the ones in system search paths. What you do is create a Python.framework directory in your project (or some subdirectory of it) and link Python.framework/Python to /System/Library/Frameworks/Python.framework/ Version/2.5/Python. Then you *should* be able to add this "framework" to your project, or do as I did and add "-framework Python" to the "Other linker flags" build setting. I tried this on a little sample project and verified with otool that the binary was linked against Python 2.5. Again, I'm not sure you want to do this, but if you can't find any other way to solve your issues this may work for you. Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2417 bytes Desc: not available URL: From njriley at illinois.edu Sat Sep 12 01:17:35 2009 From: njriley at illinois.edu (Nicholas Riley) Date: Fri, 11 Sep 2009 18:17:35 -0500 Subject: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard In-Reply-To: <347D78C2-EB7F-4FDA-BEF6-01036A0637A9@collab.nl> References: <14881.1252691459@parc.com> <347D78C2-EB7F-4FDA-BEF6-01036A0637A9@collab.nl> Message-ID: <20090911231735.GA13392@illinois.edu> On Fri, Sep 11, 2009 at 08:02:10PM +0100, Thijs Triemstra | Collab wrote: > > On 11 Sep 2009, at 18:50, Bill Janssen wrote: > > >I was happy to see that Python 2.5 still shipped with SL, but now I'm > >less happy. I can't seem to compile PIL for Python 2.5 on Snow > >Leopard. > > Hm, haven't upgraded to snow leopard yet but i'd expect 2.6 to be in > there.. heard they also removed twisted :( 2.5 and 2.6 both ship with SL, just built differently - Python 2.5 is obviously there for compatibility with Leopard, which I really appreciate. % lipo -info /usr/bin/python2.[56] Architectures in the fat file: /usr/bin/python2.5 are: i386 ppc7400 Architectures in the fat file: /usr/bin/python2.6 are: x86_64 i386 ppc7400 and Twisted is there still too: % find /System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/twisted | wc -l 1675 % find /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/python/twisted | wc -l 1675 -- Nicholas Riley From humitos at gmail.com Mon Sep 14 17:27:17 2009 From: humitos at gmail.com (Manuel Kaufmann) Date: Mon, 14 Sep 2009 12:27:17 -0300 Subject: [Pythonmac-SIG] Icon in py2app Message-ID: Hello! I'm making an app with py2app[1] utility but I can't put my icon in the dock bar. When I compile my app with py2app I see the icon in my app folder when I explore it with Finder, but when I run my app the icon doesn't appear in my dock bar. I'm using "CFBundleIconFile"[2] option in my "plist" dictionary and I tried with "--iconfile" too, but both doesn't work. Can you help me? [1] http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html [2] http://developer.apple.com/mac/library/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html#//apple_ref/doc/uid/20001431-102043 -- Kaufmann Manuel Blog: http://humitos.wordpress.com/ PyAr: http://www.python.com.ar/ From saint.ezru at googlemail.com Tue Sep 15 15:20:10 2009 From: saint.ezru at googlemail.com (Saint One) Date: Tue, 15 Sep 2009 14:20:10 +0100 Subject: [Pythonmac-SIG] Using Setuptools with macPython Message-ID: Hi all, I have mac os x 10.4 which was shipped with python2.3. Now I am trying to work with eazyInstall ( http://peak.telecommunity.com/DevCenter/EasyInstall#installation-instructions) with python2.5. I have upgraded to python2.5 now, but there seems inconsistency going through my installation directories. I have /usr/lib/python2.3/ instead of /usr/lib/python2.5/ which is what I want and this is causing problems when running python from X11 terminal. How do I upgrade this folder, and most importantly, how do I do a global upgrade of python in my mac. Thank you so much in advance for any help. Cheers, Ezru. -------------- next part -------------- An HTML attachment was scrubbed... URL: From maparent at gmail.com Fri Sep 18 23:11:52 2009 From: maparent at gmail.com (Marc-Antoine Parent) Date: Fri, 18 Sep 2009 17:11:52 -0400 Subject: [Pythonmac-SIG] py2app sip recipe and Qt plugins Message-ID: <654BE7C7-F782-4FCB-8C97-EC97199DD1D0@gmail.com> 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//Contents/plugins b) Create a file dist//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//Contents/plugins -type f -exec install_name_tool -change QtGui.framework/Versions/4/QtGui @executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui {} ';' find dist//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 From leknarf at pacbell.net Mon Sep 21 06:56:17 2009 From: leknarf at pacbell.net (Scott Frankel) Date: Sun, 20 Sep 2009 21:56:17 -0700 Subject: [Pythonmac-SIG] py2app cannot move to target thread error In-Reply-To: <4AB3B5D6.9070001@noaa.gov> References: <8ACF0495-1315-49E3-AA61-97642257A1ED@pacbell.net> <49EE8EAF-12F4-4C96-9392-AF3895D876B1@pacbell.net> <48A2335B-B7DA-4EAE-8659-5EE80F8919CE@pacbell.net> <8AB6F67C-ACA7-40BD-AEA8-DE69A905B992@pacbell.net>

<4AB3B5D6.9070001@noaa.gov> Message-ID: I've just now gotten my app to launch without error. qt.conf was the key. Thanks to Daniel and Marc-Antoine for their posts! Interestingly, manipulating library names and paths with install_name_tool was not necessary in my case. Not sure why not. Creating a plugins/sqldrivers dir, copying the libqsqlpsql.bundle to it, then creating a qt.conf INI file specifying that location within the app bundle was all that was needed. I'll be happy to contribute my final setup.py file as a recipe. How would I go about that? Meanwhile, here are a couple of URLs that provided useful information: http://doc.trolltech.com/4.4/deployment-mac.html#linking-the-application-to-qt-as-frameworks http://doc.trolltech.com/4.4/qt-conf.html Thanks Scott On Sep 18, 2009, at 9:31 AM, Christopher Barker wrote: > Scott Frankel wrote: >> 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. > > Ideally, when you've got it figured out, it could be turned into a > py2app recipe and contributed to trunk -- hint, hint! > > -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 > > Chris.Barker at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Mon Sep 21 20:46:01 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 21 Sep 2009 11:46:01 -0700 Subject: [Pythonmac-SIG] py2app cannot move to target thread error In-Reply-To: References: <8ACF0495-1315-49E3-AA61-97642257A1ED@pacbell.net> <49EE8EAF-12F4-4C96-9392-AF3895D876B1@pacbell.net> <48A2335B-B7DA-4EAE-8659-5EE80F8919CE@pacbell.net> <8AB6F67C-ACA7-40BD-AEA8-DE69A905B992@pacbell.net>

<4AB3B5D6.9070001@noaa.gov> Message-ID: <4AB7C9E9.60708@noaa.gov> Scott Frankel wrote: > Creating a plugins/sqldrivers dir, copying the libqsqlpsql.bundle to it, > then creating a qt.conf INI file specifying that location within the app > bundle was all that was needed. > > I'll be happy to contribute my final setup.py file as a recipe. How > would I go about that? If nothing else, please post it here for the archives. There must be a Wiki you could post it to, but I'm not sure which is best. However, when I wrote: >> Ideally, when you've got it figured out, it could be turned into a >> py2app recipe and contributed to trunk -- hint, hint! I was referring to the "recipes" that come bundles with py2app, and are automatically invoked when a given package is used. You can find the existing ones in the py2app package: py2app/recipes Note that there is one there called "sip.py" which is used when building an app that used sip-based bindings --i.e. qt. -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 Chris.Barker at noaa.gov From nad at acm.org Tue Sep 22 03:17:31 2009 From: nad at acm.org (Ned Deily) Date: Mon, 21 Sep 2009 18:17:31 -0700 Subject: [Pythonmac-SIG] Building packages under Snow Leopard and Python 2.6.x References: <7FD54A88-9D22-46C8-B25E-7D21EFCCF6A5@eku.edu> Message-ID: In article <7FD54A88-9D22-46C8-B25E-7D21EFCCF6A5 at eku.edu>, Jerry LeVan wrote: > 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 BTW, this is an unfortunate general problem on 10.6 when building packages containing C extension modules using pythons installed by any of the more recent python.org installers. (It's not a problem if you are using one of the Apple-supplied pythons.) The workarounds are (1) if necessary install the optional 10.4 SDK from the Xcode package included with Snow Leopard, then (2) use gcc-4.0 for the build rather than gcc-4.2 by setting CC=/usr/bin/gcc-4.0. I've opened an issue on the Python bug tracker for this; there are more details there: http://bugs.python.org/issue6957 -- Ned Deily, nad at acm.org From leknarf at pacbell.net Tue Sep 22 07:26:31 2009 From: leknarf at pacbell.net (Scott Frankel) Date: Mon, 21 Sep 2009 22:26:31 -0700 Subject: [Pythonmac-SIG] py2app cannot move to target thread error In-Reply-To: <4AB7C9E9.60708@noaa.gov> References: <8ACF0495-1315-49E3-AA61-97642257A1ED@pacbell.net> <49EE8EAF-12F4-4C96-9392-AF3895D876B1@pacbell.net> <48A2335B-B7DA-4EAE-8659-5EE80F8919CE@pacbell.net> <8AB6F67C-ACA7-40BD-AEA8-DE69A905B992@pacbell.net>

<4AB3B5D6.9070001@noaa.gov> <4AB7C9E9.60708@noaa.gov> Message-ID: Hi all, In my last post I mentioned that the qt.conf INI file was key to fixing the "cannot move to target thread" problem, caused by multiple instances of Qt running in the same app. The following setup.py file is my encapsulation of the solution. This is my first brush with py2app, so there may well be some idiosyncrasies in my code. I'll look into contributing a recipe when more of the dust settles. Thanks Scott #------------------------------------------------------------------------------- # This is a py2app setup.py file, created to build a Qt4 PyQt application # that relies on the PQSQL plugin. Note that the app links to Qt as Frameworks # and references filenames and directories as installed via macports. #------------------------------------------------------------------------------- #------------------------------------------------------------------------------- # imports #------------------------------------------------------------------------------- import sys, os import subprocess from setuptools import setup #------------------------------------------------------------------------------- # names and dirs #------------------------------------------------------------------------------- name = 'Appname' APP = ['Appname.py'] appdir = os.path.abspath(os.path.join("dist", name + ".app", "Contents")) #------------------------------------------------------------------------------- # options - setup #------------------------------------------------------------------------------- OPTIONS = {'argv_emulation': True, 'includes': ['sip', 'PyQt4._qt'], 'excludes': ['PyQt4.QtDesigner', 'PyQt4.QtNetwork', 'PyQt4.QtOpenGL', 'PyQt4.QtScript', 'PyQt4.QtTest', 'PyQt4.QtWebKit', 'PyQt4.QtXml', 'PyQt4.phonon'], # qt4-mac plugins dir from macports install 'frameworks': ["/opt/local/libexec/qt4-mac/plugins/sqldrivers/ libqsqlpsql.bundle"], } setup( app=APP, options={'py2app': OPTIONS}, setup_requires=['py2app'], ) #------------------------------------------------------------------------------- # methods #------------------------------------------------------------------------------- # wrap subprocess def doSubproc(cmd): print " ".join(cmd) subprocess.call(cmd) #------------------------------------------------------------------------------- # plugin location #------------------------------------------------------------------------------- # copy plugin to the app bundle's plugins dir. According to Qt docs: # application.app/Contents/plugins/ is the default location for loading Qt plugins if "py2app" in sys.argv: # libqsqlpsql belongs in plugins/sqldrivers plugin_dir = os.path.join(appdir, "plugins", "sqldrivers") os.makedirs(plugin_dir) doSubproc(["cp", os.path.join(appdir, "Frameworks", "libqsqlpsql.bundle"), plugin_dir]) #------------------------------------------------------------------------------- # qt.conf INI file #------------------------------------------------------------------------------- # create qt.conf INI file. For more info, # http://doc.trolltech.com/4.4/qt-conf.html iniFilename = os.path.join(appdir, "Resources", "qt.conf") iniFile = open(iniFilename, 'w') try: print "writing %s" % iniFilename iniFile.write("[Paths]\nqt_plugpath=plugins") except IOError: print "ERROR: %s not written" % iniFilename iniFile.close() # for more info on building Qt apps on Mac OSX, including static linking, # linking to Qt as Frameworks, otool, install_name_tool, and dependencies: # http://doc.trolltech.com/4.4/deployment-mac.html#linking-the-application-to-qt-as-frameworks From mathew.oakes at aad.gov.au Wed Sep 23 03:56:45 2009 From: mathew.oakes at aad.gov.au (mathew oakes) Date: Wed, 23 Sep 2009 11:56:45 +1000 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] Message-ID: <1253671005.4022.21.camel@mjoakes-desktop> I'm stumped on this: When running my app that has built without errors... > ...An unexpected error has occured during installation of the main > script > > DistutilsPlatformError: invalid Python installation: unable to > open /Full/Path/To/App.app/Contents/Resources/include/python2.6/pyconfig.h (No such file or directory) but python in in the bundle at .../Resources/lib/ and it doesn't have a pyconfig header python is installed via ports at /opt/local/bin/python Alias mode and py2exe versions work. Help appreciated! cheers Mat ___________________________________________________________________________ Australian Antarctic Division - Commonwealth of Australia IMPORTANT: This transmission is intended for the addressee only. If you are not the intended recipient, you are notified that use or dissemination of this communication is strictly prohibited by Commonwealth law. If you have received this transmission in error, please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and DELETE the message. Visit our web site at http://www.antarctica.gov.au/ ___________________________________________________________________________ From arif.amirani at gmail.com Wed Sep 23 10:50:39 2009 From: arif.amirani at gmail.com (Arif Amirani) Date: Wed, 23 Sep 2009 14:20:39 +0530 Subject: [Pythonmac-SIG] Initial memory usage In-Reply-To: <5e7d03b80909210139j11546d12u5ad256b9d8462b36@mail.gmail.com> References: <5e7d03b80909210139j11546d12u5ad256b9d8462b36@mail.gmail.com> Message-ID: <5e7d03b80909230150t7251e5e6h1ebc6f405ebf00b5@mail.gmail.com> Hi all, I couldn't get any response on the PyObjC mailing list so trying here. I've recently started developing PyObjC apps and my app memory usage shot off to 75MB. So I created a small Hello World app with just one NSWindow and the initial memory was 36MB. I'd assume this would be expected since the entire Python interpreter is running within the app it might take that much. So is it safe to assume that all PyObjC apps need a minimum of 30+M to work? Versions: Mac OS X 10.5.8 >>> print objc.__version__ 2.2b2 Thanks, Arif Amirani Blog: http://blog.tripmeter.in -------------- next part -------------- An HTML attachment was scrubbed... URL: From aahz at pythoncraft.com Wed Sep 23 15:21:56 2009 From: aahz at pythoncraft.com (Aahz) Date: Wed, 23 Sep 2009 06:21:56 -0700 Subject: [Pythonmac-SIG] Initial memory usage In-Reply-To: <5e7d03b80909230150t7251e5e6h1ebc6f405ebf00b5@mail.gmail.com> References: <5e7d03b80909210139j11546d12u5ad256b9d8462b36@mail.gmail.com> <5e7d03b80909230150t7251e5e6h1ebc6f405ebf00b5@mail.gmail.com> Message-ID: <20090923132156.GA25748@panix.com> On Wed, Sep 23, 2009, Arif Amirani wrote: > > I've recently started developing PyObjC apps and my app memory usage > shot off to 75MB. So I created a small Hello World app with just one > NSWindow and the initial memory was 36MB. I'd assume this would be > expected since the entire Python interpreter is running within the app > it might take that much. So is it safe to assume that all PyObjC apps > need a minimum of 30+M to work? Dunno whether that's a safe assumption, but that certainly matches my experience. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ gfarber: Thank God, or the belief system of your choice. pddb: Does human perversity count as a belief system? From aahz at pythoncraft.com Wed Sep 23 15:22:55 2009 From: aahz at pythoncraft.com (Aahz) Date: Wed, 23 Sep 2009 06:22:55 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] In-Reply-To: <1253671005.4022.21.camel@mjoakes-desktop> References: <1253671005.4022.21.camel@mjoakes-desktop> Message-ID: <20090923132255.GB25748@panix.com> On Wed, Sep 23, 2009, mathew oakes wrote: > > I'm stumped on this: > > When running my app that has built without errors... > > > ...An unexpected error has occured during installation of the main > > script > > > > DistutilsPlatformError: invalid Python installation: unable to > > open /Full/Path/To/App.app/Contents/Resources/include/python2.6/pyconfig.h (No such file or directory) > > but python in in the bundle at .../Resources/lib/ and it doesn't have a > pyconfig header Ayup, you need to copy it from python2.5 -- pretty annoying. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ gfarber: Thank God, or the belief system of your choice. pddb: Does human perversity count as a belief system? From Chris.Barker at noaa.gov Wed Sep 23 18:21:26 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 23 Sep 2009 09:21:26 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] In-Reply-To: <20090923132255.GB25748@panix.com> References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> Message-ID: <4ABA4B06.3000609@noaa.gov> Aahz wrote: > On Wed, Sep 23, 2009, mathew oakes wrote: >>> DistutilsPlatformError: invalid Python installation: unable to >>> open /Full/Path/To/App.app/Contents/Resources/include/python2.6/pyconfig.h (No such file or directory) >> but python in in the bundle at .../Resources/lib/ and it doesn't have a >> pyconfig header > > Ayup, you need to copy it from python2.5 -- pretty annoying. Indeed. Does anyone know what pyconfig.h is used for? Is it a setuptools thing? py2app was written before setuptools, and I've found most of what I've had to do by hand was due to egg issues. Here's my code for this: def AddMacExtras(NAME): # post processing: print "Adding extra stuff" if "-A"in sys.argv: print "Building an Alias -- not copying everything" else: ## ugly hard coding of paths! print "adding the pyconfig header" shutil.copy("/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/pyconfig.h", "dist/%s.app/Contents/Resources/include/python2.5/pyconfig.h"%NAME) HTH, -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 Chris.Barker at noaa.gov From aahz at pythoncraft.com Wed Sep 23 18:36:46 2009 From: aahz at pythoncraft.com (Aahz) Date: Wed, 23 Sep 2009 09:36:46 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] In-Reply-To: <4ABA4B06.3000609@noaa.gov> References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> Message-ID: <20090923163646.GA26464@panix.com> On Wed, Sep 23, 2009, Christopher Barker wrote: > Aahz wrote: >> On Wed, Sep 23, 2009, mathew oakes wrote: > >>>> DistutilsPlatformError: invalid Python installation: unable to >>>> open /Full/Path/To/App.app/Contents/Resources/include/python2.6/pyconfig.h (No such file or directory) >>> but python in in the bundle at .../Resources/lib/ and it doesn't have a >>> pyconfig header >> >> Ayup, you need to copy it from python2.5 -- pretty annoying. > > Indeed. Does anyone know what pyconfig.h is used for? Is it a setuptools > thing? py2app was written before setuptools, and I've found most of what > I've had to do by hand was due to egg issues. It's a setuptools thing. > shutil.copy("/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/pyconfig.h", > "dist/%s.app/Contents/Resources/include/python2.5/pyconfig.h"%NAME) My solution is to just copy it once to the installed Python 2.6. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ gfarber: Thank God, or the belief system of your choice. pddb: Does human perversity count as a belief system? From gabriel.rossetti at arimaz.com Wed Sep 23 22:08:52 2009 From: gabriel.rossetti at arimaz.com (gabriel.rossetti at arimaz.com) Date: Wed, 23 Sep 2009 20:08:52 +0000 Subject: [Pythonmac-SIG] building wxPython on Mac OS X (10.5) Message-ID: Hello everyone, I am trying to build wx on Mac OS X by following this tutorial : http://www.wxpython.org/BUILD.html I did the following : cd Python-2.5.4 mkdir ../Python-Mac-Root /configure --prefix=/Users/me/Desktop/Python-Mac-Root \ --with-suffix=.mine --enable-shared --with-threads make && make install cd ../wxPython-src-2.8.10.1 /configure --prefix=/Users/me/Desktop/Python-Mac-Root \ --with-mac --enable-geometry --enable-display \ --enable-unicode --with-libjpeg=builtin \ --with-libpng=builtin --with-libtiff=builtin \ --with-zlib=builtin make && make install cd wxPython /Users/me/Desktop/Python-Mac-Root/bin/python.mine setup.py build_ext \ --inplace BUILD_GLCANVAS=0 BUILD_STC=0 BUILD_GIZMOS=0 \ WX_CONFIG=/Users/me/Desktop/Python-Mac-Root/bin/wx-config and everything goes well. My question is that I don't want to have to set PYTHONPATH and DYLD_LIBRARY_PATH because I'd like for this to be self contained and not have env. variables to set (just unzip and use, like PortablePython on windows). Also, on the wx that's installed with my real python installation I don't have those env variables defined and it still works, so could someone please help me with this? Thank you, Gabriel From nad at acm.org Thu Sep 24 06:00:42 2009 From: nad at acm.org (Ned Deily) Date: Wed, 23 Sep 2009 21:00:42 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> <20090923163646.GA26464@panix.com> Message-ID: In article <20090923163646.GA26464 at panix.com>, Aahz wrote: > On Wed, Sep 23, 2009, Christopher Barker wrote: > > Aahz wrote: > >> On Wed, Sep 23, 2009, mathew oakes wrote: > > > >>>> DistutilsPlatformError: invalid Python installation: unable to > >>>> open > >>>> /Full/Path/To/App.app/Contents/Resources/include/python2.6/pyconfig.h > >>>> (No such file or directory) > >>> but python in in the bundle at .../Resources/lib/ and it doesn't have a > >>> pyconfig header > >> > >> Ayup, you need to copy it from python2.5 -- pretty annoying. > > > > Indeed. Does anyone know what pyconfig.h is used for? Is it a setuptools > > thing? py2app was written before setuptools, and I've found most of what > > I've had to do by hand was due to egg issues. > > It's a setuptools thing. I believe pyconfig.h is created by the compiler build ./configure script to capture the relevant platform-dependent build configuration for that python instance and is used by distutils build_ext so that package C extensions can be correctly built. > > shutil.copy("/Library/Frameworks/Python.framework/Versions/2.5/include/pytho > > n2.5/pyconfig.h", > > "dist/%s.app/Contents/Resources/include/python2.5/pyconfig.h"%NAME) > > My solution is to just copy it once to the installed Python 2.6. I'm not a py2app user so I'm not sure I understand the problem you all are seeing. Is it that pyconfig.h isn't being installed in /Library/Frameworks by a Python installer? -- Ned Deily, nad at acm.org From gabriel.rossetti at arimaz.com Thu Sep 24 11:12:47 2009 From: gabriel.rossetti at arimaz.com (gabriel.rossetti at arimaz.com) Date: Thu, 24 Sep 2009 09:12:47 +0000 Subject: [Pythonmac-SIG] building wxPython on Mac OS X (10.5) In-Reply-To: Message-ID: On 23/9/2009, "gabriel.rossetti at arimaz.com" wrote: >Hello everyone, > >I am trying to build wx on Mac OS X by following this tutorial : >http://www.wxpython.org/BUILD.html > >I did the following : > >cd Python-2.5.4 >mkdir ../Python-Mac-Root >/configure --prefix=/Users/me/Desktop/Python-Mac-Root \ > --with-suffix=.mine --enable-shared --with-threads >make && make install > >cd ../wxPython-src-2.8.10.1 >/configure --prefix=/Users/me/Desktop/Python-Mac-Root \ > --with-mac --enable-geometry --enable-display \ > --enable-unicode --with-libjpeg=builtin \ > --with-libpng=builtin --with-libtiff=builtin \ > --with-zlib=builtin >make && make install > >cd wxPython >/Users/me/Desktop/Python-Mac-Root/bin/python.mine setup.py build_ext \ > --inplace BUILD_GLCANVAS=0 BUILD_STC=0 BUILD_GIZMOS=0 \ > WX_CONFIG=/Users/me/Desktop/Python-Mac-Root/bin/wx-config > >and everything goes well. My question is that I don't want to have to >set PYTHONPATH and DYLD_LIBRARY_PATH because I'd like for this to be >self contained and not have env. variables to set (just unzip and use, >like PortablePython on windows). Also, on the wx that's installed with >my real python installation I don't have those env variables defined >and it still works, so could someone please help me with this? > >Thank you, >Gabriel Ok, I'd forgotten to run the install step so it wasn't in my site-packages. : /Users/grossetti/Desktop/Python-Mac-Root/bin/python.mine setup.py install --prefix=/Users/me/Desktop/Python-Mac-Root WX_CONFIG=/Users/me/Desktop/Python-Mac-Root/bin/wx-config I tried to export DYLD_LIBRARY_PATH : export DYLD_LIBRARY_PATH=/Users/me/Desktop/Python-Mac-Root/lib to see if it at least works like that but I get the following error : $ Desktop/Python-Mac-Root/bin/python.mine Python 2.5.4 (r254:67916, Sep 23 2009, 17:37:07) [GCC 4.0.1 (Apple Inc. build 5490)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import wx Traceback (most recent call last): File "", line 1, in File "/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/__init__.py", line 45, in from wx._core import * File "/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core.py", line 4, in import _core_ ImportError: dlopen(/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so, 2): Symbol not found: __ZN12wxSizerFlags24ReserveSpaceEvenIfHiddenEv Referenced from: /Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so Expected in: dynamic lookup I don't get it, I did the following : nm /Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so | grep __ZN12wxSizerFlags24ReserveSpaceEvenIfHiddenEv U __ZN12wxSizerFlags24ReserveSpaceEvenIfHiddenEv so it's there, any ideas? From gabriel.rossetti at arimaz.com Thu Sep 24 13:28:10 2009 From: gabriel.rossetti at arimaz.com (gabriel.rossetti at arimaz.com) Date: Thu, 24 Sep 2009 11:28:10 +0000 Subject: [Pythonmac-SIG] building wxPython on Mac OS X (10.5) In-Reply-To: Message-ID: On 24/9/2009, "gabriel.rossetti at arimaz.com" wrote: >On 23/9/2009, "gabriel.rossetti at arimaz.com" > wrote: > >>Hello everyone, >> >>I am trying to build wx on Mac OS X by following this tutorial : >>http://www.wxpython.org/BUILD.html >> >>I did the following : >> >>cd Python-2.5.4 >>mkdir ../Python-Mac-Root >>/configure --prefix=/Users/me/Desktop/Python-Mac-Root \ >> --with-suffix=.mine --enable-shared --with-threads >>make && make install >> >>cd ../wxPython-src-2.8.10.1 >>/configure --prefix=/Users/me/Desktop/Python-Mac-Root \ >> --with-mac --enable-geometry --enable-display \ >> --enable-unicode --with-libjpeg=builtin \ >> --with-libpng=builtin --with-libtiff=builtin \ >> --with-zlib=builtin >>make && make install >> >>cd wxPython >>/Users/me/Desktop/Python-Mac-Root/bin/python.mine setup.py build_ext \ >> --inplace BUILD_GLCANVAS=0 BUILD_STC=0 BUILD_GIZMOS=0 \ >> WX_CONFIG=/Users/me/Desktop/Python-Mac-Root/bin/wx-config >> >>and everything goes well. My question is that I don't want to have to >>set PYTHONPATH and DYLD_LIBRARY_PATH because I'd like for this to be >>self contained and not have env. variables to set (just unzip and use, >>like PortablePython on windows). Also, on the wx that's installed with >>my real python installation I don't have those env variables defined >>and it still works, so could someone please help me with this? >> >>Thank you, >>Gabriel > > >Ok, I'd forgotten to run the install step so it wasn't in my >site-packages. : > >/Users/grossetti/Desktop/Python-Mac-Root/bin/python.mine setup.py install >--prefix=/Users/me/Desktop/Python-Mac-Root >WX_CONFIG=/Users/me/Desktop/Python-Mac-Root/bin/wx-config > >I tried to export DYLD_LIBRARY_PATH : > >export DYLD_LIBRARY_PATH=/Users/me/Desktop/Python-Mac-Root/lib to see if >it at least works like that but I get the following error : > >$ Desktop/Python-Mac-Root/bin/python.mine >Python 2.5.4 (r254:67916, Sep 23 2009, 17:37:07) >[GCC 4.0.1 (Apple Inc. build 5490)] on darwin >Type "help", "copyright", "credits" or "license" for more >information. >>>> import wx >Traceback (most recent call last): > File "", line 1, in > File >"/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/__init__.py", >line 45, in > from wx._core import * > File >"/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core.py", >line 4, in > import _core_ >ImportError: >dlopen(/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so, >2): Symbol not found: __ZN12wxSizerFlags24ReserveSpaceEvenIfHiddenEv > Referenced from: >/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so > Expected in: dynamic lookup > >I don't get it, I did the following : > >nm >/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so >| grep __ZN12wxSizerFlags24ReserveSpaceEvenIfHiddenEv > U __ZN12wxSizerFlags24ReserveSpaceEvenIfHiddenEv > >so it's there, any ideas? If I export PYTHONPATH : export PYTHONPATH=/Users/me/Desktop/python_client_deps/wxPython-src-2.8.10.1/wxPython What I don't get is why the installed version doesn't get picked up in site-packages. It has a wx.path in site-packages : $ cat /Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx.pth wx-2.8-mac-unicode so I don't get why it's not getting picked up, any ideas? From aahz at pythoncraft.com Thu Sep 24 15:13:38 2009 From: aahz at pythoncraft.com (Aahz) Date: Thu, 24 Sep 2009 06:13:38 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] In-Reply-To: References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> <20090923163646.GA26464@panix.com> Message-ID: <20090924131338.GA21078@panix.com> On Wed, Sep 23, 2009, Ned Deily wrote: > In article <20090923163646.GA26464 at panix.com>, > Aahz wrote: >> On Wed, Sep 23, 2009, Christopher Barker wrote: >> > Aahz wrote: >> >> On Wed, Sep 23, 2009, mathew oakes wrote: >> > >> >>>> DistutilsPlatformError: invalid Python installation: unable to >> >>>> open >> >>>> /Full/Path/To/App.app/Contents/Resources/include/python2.6/pyconfig.h >> >>>> (No such file or directory) >> >>> but python in in the bundle at .../Resources/lib/ and it doesn't have a >> >>> pyconfig header >> >> >> >> Ayup, you need to copy it from python2.5 -- pretty annoying. >> > >> > Indeed. Does anyone know what pyconfig.h is used for? Is it a setuptools >> > thing? py2app was written before setuptools, and I've found most of what >> > I've had to do by hand was due to egg issues. >> >> It's a setuptools thing. > > I believe pyconfig.h is created by the compiler build ./configure script > to capture the relevant platform-dependent build configuration for that > python instance and is used by distutils build_ext so that package C > extensions can be correctly built. It's not included in the .dmg for Python 2.6. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ gfarber: Thank God, or the belief system of your choice. pddb: Does human perversity count as a belief system? From gabriel.rossetti at arimaz.com Thu Sep 24 15:46:18 2009 From: gabriel.rossetti at arimaz.com (gabriel.rossetti at arimaz.com) Date: Thu, 24 Sep 2009 13:46:18 +0000 Subject: [Pythonmac-SIG] building wxPython on Mac OS X (10.5) In-Reply-To: Message-ID: On 24/9/2009, "gabriel.rossetti at arimaz.com" wrote: >On 24/9/2009, "gabriel.rossetti at arimaz.com" > wrote: > >>On 23/9/2009, "gabriel.rossetti at arimaz.com" >> wrote: >> >>>Hello everyone, >>> >>>I am trying to build wx on Mac OS X by following this tutorial : >>>http://www.wxpython.org/BUILD.html >>> >>>I did the following : >>> >>>cd Python-2.5.4 >>>mkdir ../Python-Mac-Root >>>/configure --prefix=/Users/me/Desktop/Python-Mac-Root \ >>> --with-suffix=.mine --enable-shared --with-threads >>>make && make install >>> >>>cd ../wxPython-src-2.8.10.1 >>>/configure --prefix=/Users/me/Desktop/Python-Mac-Root \ >>> --with-mac --enable-geometry --enable-display \ >>> --enable-unicode --with-libjpeg=builtin \ >>> --with-libpng=builtin --with-libtiff=builtin \ >>> --with-zlib=builtin >>>make && make install >>> >>>cd wxPython >>>/Users/me/Desktop/Python-Mac-Root/bin/python.mine setup.py build_ext \ >>> --inplace BUILD_GLCANVAS=0 BUILD_STC=0 BUILD_GIZMOS=0 \ >>> WX_CONFIG=/Users/me/Desktop/Python-Mac-Root/bin/wx-config >>> >>>and everything goes well. My question is that I don't want to have to >>>set PYTHONPATH and DYLD_LIBRARY_PATH because I'd like for this to be >>>self contained and not have env. variables to set (just unzip and use, >>>like PortablePython on windows). Also, on the wx that's installed with >>>my real python installation I don't have those env variables defined >>>and it still works, so could someone please help me with this? >>> >>>Thank you, >>>Gabriel >> >> >>Ok, I'd forgotten to run the install step so it wasn't in my >>site-packages. : >> >>/Users/me/Desktop/Python-Mac-Root/bin/python.mine setup.py install >>--prefix=/Users/me/Desktop/Python-Mac-Root >>WX_CONFIG=/Users/me/Desktop/Python-Mac-Root/bin/wx-config >> >>I tried to export DYLD_LIBRARY_PATH : >> >>export DYLD_LIBRARY_PATH=/Users/me/Desktop/Python-Mac-Root/lib to see if >>it at least works like that but I get the following error : >> >>$ Desktop/Python-Mac-Root/bin/python.mine >>Python 2.5.4 (r254:67916, Sep 23 2009, 17:37:07) >>[GCC 4.0.1 (Apple Inc. build 5490)] on darwin >>Type "help", "copyright", "credits" or "license" for more >>information. >>>>> import wx >>Traceback (most recent call last): >> File "", line 1, in >> File >>"/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/__init__.py", >>line 45, in >> from wx._core import * >> File >>"/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core.py", >>line 4, in >> import _core_ >>ImportError: >>dlopen(/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so, >>2): Symbol not found: __ZN12wxSizerFlags24ReserveSpaceEvenIfHiddenEv >> Referenced from: >>/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so >> Expected in: dynamic lookup >> >>I don't get it, I did the following : >> >>nm >>/Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so >>| grep __ZN12wxSizerFlags24ReserveSpaceEvenIfHiddenEv >> U __ZN12wxSizerFlags24ReserveSpaceEvenIfHiddenEv >> >>so it's there, any ideas? > >If I export PYTHONPATH : > >export >PYTHONPATH=/Users/me/Desktop/python_client_deps/wxPython-src-2.8.10.1/wxPython > >What I don't get is why the installed version doesn't get picked up in >site-packages. It has a wx.path in site-packages : > >$ cat /Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx.pth >wx-2.8-mac-unicode > >so I don't get why it's not getting picked up, any ideas? I tried : $ otool -L /Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so and I get : /Users/me/Desktop/Python-Mac-Root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx/_core_.so: /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libwx_macud-2.8.0.dylib (compatibility version 2.6.0, current version 2.8.4) /System/Library/Frameworks/QuickTime.framework/Versions/A/QuickTime (compatibility version 1.0.0, current version 1327.73.0) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 136.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 12.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 34.0.0) it appears linked with the wrong version of /usr/lib/libwx_macud-2.8.0.dylib, is that correct? If so, how can I fix it? Thanks From robin at alldunn.com Thu Sep 24 19:45:46 2009 From: robin at alldunn.com (Robin Dunn) Date: Thu, 24 Sep 2009 10:45:46 -0700 Subject: [Pythonmac-SIG] [wxPython-users] Re: building wxPython on Mac OS X (10.5) In-Reply-To: References: Message-ID: <4ABBB04A.4060705@alldunn.com> On 9/24/09 6:46 AM, gabriel.rossetti at arimaz.com wrote: > it appears linked with the wrong version of > /usr/lib/libwx_macud-2.8.0.dylib, is that correct? Yes. > If so, how can I fix > it? > Double check the wxWidgets build and install steps. It should have used your {prefix}/lib path for the wxMac lib but it fell back to the one distributed by Apple in /usr/lib instead. Hmm... You didn't use --enable-monolithic in your configure step, that's probably the problem. Note that the path to the dylib is embedded in the extension module .so so even when you get this working at your install locations there will still be issues with having something self contained that can be zipped up and unzipped elsewhere. To work around that you're either going to have to set DYLD_LIBRARY_PATH or you can use install_name_tool to change the embedded path name. You can make that embedded name be relative to the executable or the image loading the dylib (the .so extension modules in this case) by using "@executable_path" or "@loader_path" in the path name. -- Robin Dunn Software Craftsman http://wxPython.org From nad at acm.org Thu Sep 24 20:34:46 2009 From: nad at acm.org (Ned Deily) Date: Thu, 24 Sep 2009 11:34:46 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> <20090923163646.GA26464@panix.com> <20090924131338.GA21078@panix.com> Message-ID: In article <20090924131338.GA21078 at panix.com>, Aahz wrote: > On Wed, Sep 23, 2009, Ned Deily wrote: > > In article <20090923163646.GA26464 at panix.com>, > > Aahz wrote: > >> On Wed, Sep 23, 2009, Christopher Barker wrote: > >> > Aahz wrote: > >> >> On Wed, Sep 23, 2009, mathew oakes wrote: > >> >>>> DistutilsPlatformError: invalid Python installation: unable to > >> >>>> open > >> >>>> /Full/Path/To/App.app/Contents/Resources/include/python2.6/pyconfig.h > >> >>>> (No such file or directory) > >> >>> but python in in the bundle at .../Resources/lib/ and it doesn't have > >> >>> a > >> >>> pyconfig header > >> >> Ayup, you need to copy it from python2.5 -- pretty annoying. > >> > Indeed. Does anyone know what pyconfig.h is used for? Is it a setuptools > >> > thing? py2app was written before setuptools, and I've found most of what > >> > I've had to do by hand was due to egg issues. > >> It's a setuptools thing. > > I believe pyconfig.h is created by the compiler build ./configure script > > to capture the relevant platform-dependent build configuration for that > > python instance and is used by distutils build_ext so that package C > > extensions can be correctly built. > It's not included in the .dmg for Python 2.6. Now I'm really confused :=) I've just installed from the final python.org 2.6, 2.6.1, and 2.6.2 install.dmgs and, for me, each one installed what appears to be an appropriate file. For example: -rw-rw-r-- 1 root admin 30696 Apr 16 00:29 /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pycon fig.h Again, I'm no py2app expert but it looks like this might have been a problem that Ronald fixed in py2app svn r65 (aka 0.4.0) back in 2008-01. >From various past postings, I gather py2app hasn't been formally released in a long time and that the recommendation is to work from a recent svn checkout (currently r80 and working towards 0.4.2). -- Ned Deily, nad at acm.org From Chris.Barker at noaa.gov Thu Sep 24 21:07:45 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 24 Sep 2009 12:07:45 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] In-Reply-To: References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> <20090923163646.GA26464@panix.com> <20090924131338.GA21078@panix.com> Message-ID: <4ABBC381.4090500@noaa.gov> Ned Deily wrote: >> It's not included in the .dmg for Python 2.6. > > Now I'm really confused :=) I've just installed from the final > python.org 2.6, 2.6.1, and 2.6.2 install.dmgs and, for me, each one > installed what appears to be an appropriate file. For example: Well, I'm not using 2.6 yet, but with 2.5, my problem was that py2app didn't copy pyconfig.h into the bundle, and that I gues setuptools was looking for it. The core problem is two-fold: 1) setuptools does all sorts of nifty stuff that really make no sense in a bundled application, but I don't think there are any hooks in it to disable or grcefuly fail when bundled -- hmmm, maybe that's an idea for a patch, though honestly, I'll never get around to it! Also, I don't think a lot of this should be done at run time at all -- checking if the installed package version is correct, for instance, but that's how a lot of folks use setuptools. 2) py2app is not setuptools aware at all. Unfortunately, it seems the way to make it aware is kind of to punt: if there is an egg involved, copy the whole darn thing in, 'cause there is no way to know what's really needed! > -rw-rw-r-- 1 root admin 30696 Apr 16 00:29 > /Library/Frameworks/Python.framework/Versions/2.6/include/python2.6/pycon > fig.h By the way, I'm not using 2.6, but I have installed it, and I have pyconfig.h also, so I'm not sure what the OP's issue was. -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 Chris.Barker at noaa.gov From nad at acm.org Thu Sep 24 22:06:55 2009 From: nad at acm.org (Ned Deily) Date: Thu, 24 Sep 2009 13:06:55 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> <20090923163646.GA26464@panix.com> <20090924131338.GA21078@panix.com> <4ABBC381.4090500@noaa.gov> Message-ID: In article <4ABBC381.4090500 at noaa.gov>, Christopher Barker wrote: > Ned Deily wrote: > >> It's not included in the .dmg for Python 2.6. > > Now I'm really confused :=) I've just installed from the final > > python.org 2.6, 2.6.1, and 2.6.2 install.dmgs and, for me, each one > > installed what appears to be an appropriate file. For example: > Well, I'm not using 2.6 yet, but with 2.5, my problem was that py2app > didn't copy pyconfig.h into the bundle, and that I gues setuptools was > looking for it. Just for the record, I don't think this particular issue has anything directly to do with either setuptools or python2.6. IIUC, pyconfig.h is needed for any packages (packaged with standard *distutils*) that include any C extension modules. From a quick glance at the py2app code, it looks like, prior to r65, py2app did not copy pyconfig.h at all. That wouldn't lead to problems until you tried to install a C extension module. -- Ned Deily, nad at acm.org From aahz at pythoncraft.com Thu Sep 24 22:40:15 2009 From: aahz at pythoncraft.com (Aahz) Date: Thu, 24 Sep 2009 13:40:15 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] In-Reply-To: References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> <20090923163646.GA26464@panix.com> <20090924131338.GA21078@panix.com> <4ABBC381.4090500@noaa.gov> Message-ID: <20090924204015.GA15690@panix.com> On Thu, Sep 24, 2009, Ned Deily wrote: > > Just for the record, I don't think this particular issue has anything > directly to do with either setuptools or python2.6. IIUC, pyconfig.h is > needed for any packages (packaged with standard *distutils*) that > include any C extension modules. From a quick glance at the py2app > code, it looks like, prior to r65, py2app did not copy pyconfig.h at > all. That wouldn't lead to problems until you tried to install a C > extension module. Well, I don't have any time to track down what happened a few weeks ago, but it was definitely the case that setuptools was crashing due to a missing pyconfig.h, and the Python 2.6 installation I was using didn't have one. -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ gfarber: Thank God, or the belief system of your choice. pddb: Does human perversity count as a belief system? From Chris.Barker at noaa.gov Thu Sep 24 22:49:33 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 24 Sep 2009 13:49:33 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] In-Reply-To: References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> <20090923163646.GA26464@panix.com> <20090924131338.GA21078@panix.com> <4ABBC381.4090500@noaa.gov> Message-ID: <4ABBDB5D.7020705@noaa.gov> Ned Deily wrote: > Just for the record, I don't think this particular issue has anything > directly to do with either setuptools or python2.6. IIUC, pyconfig.h is > needed for any packages (packaged with standard *distutils*) that > include any C extension modules. They should only need it when you build the packages though, not when you run them. > From a quick glance at the py2app > code, it looks like, prior to r65, py2app did not copy pyconfig.h at > all. That wouldn't lead to problems until you tried to install a C > extension module. I built many py2app bundles with C extensions without any pyconfig.h file. I only had the issue when I packaged an app that made heavy (and I think in appropriate) use of setuptools. Granted, it's a big and complex app, so it could have been something else, but a simple C extension. -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 Chris.Barker at noaa.gov From mathew.oakes at aad.gov.au Fri Sep 25 05:04:35 2009 From: mathew.oakes at aad.gov.au (mathew oakes) Date: Fri, 25 Sep 2009 13:04:35 +1000 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] In-Reply-To: References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> <20090923163646.GA26464@panix.com> <20090924131338.GA21078@panix.com> <4ABBC381.4090500@noaa.gov> Message-ID: <1253847876.3166.3.camel@mjoakes-desktop> Working now! I upgraded py2app, macholib, modulegraph and altgraph to svn versions (although I found it hard to get the correct svn links... http://mail.python.org/pipermail/pythonmac-sig/2008-July/020251.html) pyconfig issues are then dealt with correctly. Macports py2app is 0.36, and there is a py2app-devel at 0.42 which requires svn access and I'm behind a firewall that blocks that. Cairo appears to be only available via macports on mac, and I'm not thorough enough to mix bits of different python distributions, so must do everything through one. I had a redundant import from wx.lib.cairo -- (was trying to display generated svg files in a wx window. There were no simple recipes to be found and couldn't justify the time involved when firefox or inkscape can fulfil the function.) Without that import, everything is fine. On Fri, 2009-09-25 at 06:06 +1000, Ned Deily wrote: > In article <4ABBC381.4090500 at noaa.gov>, > Christopher Barker wrote: > > Ned Deily wrote: > > >> It's not included in the .dmg for Python 2.6. > > > Now I'm really confused :=) I've just installed from the final > > > python.org 2.6, 2.6.1, and 2.6.2 install.dmgs and, for me, each one > > > installed what appears to be an appropriate file. For example: > > Well, I'm not using 2.6 yet, but with 2.5, my problem was that py2app > > didn't copy pyconfig.h into the bundle, and that I gues setuptools was > > looking for it. > > Just for the record, I don't think this particular issue has anything > directly to do with either setuptools or python2.6. IIUC, pyconfig.h is > needed for any packages (packaged with standard *distutils*) that > include any C extension modules. From a quick glance at the py2app > code, it looks like, prior to r65, py2app did not copy pyconfig.h at > all. That wouldn't lead to problems until you tried to install a C > extension module. > > -- > Ned Deily, > nad at acm.org > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig ___________________________________________________________________________ Australian Antarctic Division - Commonwealth of Australia IMPORTANT: This transmission is intended for the addressee only. If you are not the intended recipient, you are notified that use or dissemination of this communication is strictly prohibited by Commonwealth law. If you have received this transmission in error, please notify the sender immediately by e-mail or by telephoning +61 3 6232 3209 and DELETE the message. Visit our web site at http://www.antarctica.gov.au/ ___________________________________________________________________________ From gabriel.rossetti at arimaz.com Fri Sep 25 14:56:06 2009 From: gabriel.rossetti at arimaz.com (Gabriel Rossetti) Date: Fri, 25 Sep 2009 14:56:06 +0200 Subject: [Pythonmac-SIG] Lanchd + virtualenv Message-ID: <4ABCBDE6.6030403@arimaz.com> Hello everyone, I would like to create a Launchd plist entry to start a virtualenv and run a python project. I created my plist, but I'm not sure how to get it to activate the virtualenv and run the program. I thought that maybe I could create two emtries : Label com.example.virtualenv Program source ProgramArguments /path/to/myvirtualenv/bin/activate RunAtLoad Label com.example.app Program python ProgramArguments /path/to/myproj/launcher.py start RunAtLoad but I'm not sure I can do that, and I have 2 programs to run for my project, so would I create 3 entries like so : Label com.example.virtualenv Program source ProgramArguments /path/to/myvirtualenv/bin/activate RunAtLoad Label com.example.app1 Program python ProgramArguments /path/to/myproj/launcher.py app1 start RunAtLoad Label com.example.app2 Program python ProgramArguments /path/to/myproj/launcher.py app2 start RunAtLoad Or is there a better/another way to do this? From aahz at pythoncraft.com Fri Sep 25 16:01:28 2009 From: aahz at pythoncraft.com (Aahz) Date: Fri, 25 Sep 2009 07:01:28 -0700 Subject: [Pythonmac-SIG] Lanchd + virtualenv In-Reply-To: <4ABCBDE6.6030403@arimaz.com> References: <4ABCBDE6.6030403@arimaz.com> Message-ID: <20090925140128.GA20089@panix.com> On Fri, Sep 25, 2009, Gabriel Rossetti wrote: > > I would like to create a Launchd plist entry to start a virtualenv and > run a python project. I created my plist, but I'm not sure how to get it > to activate the virtualenv and run the program. I thought that maybe I > could create two emtries : Why not just write a single wrapper script that creates the virtualenv and then runs the main program? Python rocks! -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ gfarber: Thank God, or the belief system of your choice. pddb: Does human perversity count as a belief system? From orestis at orestis.gr Fri Sep 25 17:01:26 2009 From: orestis at orestis.gr (Orestis Markou) Date: Fri, 25 Sep 2009 18:01:26 +0300 Subject: [Pythonmac-SIG] Lanchd + virtualenv In-Reply-To: <4ABCBDE6.6030403@arimaz.com> References: <4ABCBDE6.6030403@arimaz.com> Message-ID: No need for a wrapper script. In recent versions of virtualenv, you can do this: activate_this = 'path/to/virtualenv/bin/activate_this.py' if os.path.exists(activate_this): execfile(activate_this, dict(__file__=activate_this)) On 25 ??? 2009, at 3:56 ?.?., Gabriel Rossetti wrote: > Hello everyone, > > I would like to create a Launchd plist entry to start a virtualenv > and run a python project. I created my plist, but I'm not sure how > to get it to activate the virtualenv and run the program. I thought > that maybe I could create two emtries : > > > "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> > > > Label > com.example.virtualenv > Program > source > ProgramArguments > > /path/to/myvirtualenv/bin/activate > > RunAtLoad > > > > Label > com.example.app > Program > python > ProgramArguments > > /path/to/myproj/launcher.py > start > > RunAtLoad > > > > > > but I'm not sure I can do that, and I have 2 programs to run for my > project, so would I create 3 entries like so : > > > "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> > > > > Label > com.example.virtualenv > Program > source > ProgramArguments > > /path/to/myvirtualenv/bin/activate > > RunAtLoad > > > > > Label > com.example.app1 > Program > python > ProgramArguments > > /path/to/myproj/launcher.py > app1 > start > > RunAtLoad > > > > > Label > com.example.app2 > Program > python > ProgramArguments > > /path/to/myproj/launcher.py > app2 > start > > RunAtLoad > > > > > Or is there a better/another way to do this? > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From gabriel.rossetti at arimaz.com Fri Sep 25 17:31:03 2009 From: gabriel.rossetti at arimaz.com (gabriel.rossetti at arimaz.com) Date: Fri, 25 Sep 2009 17:31:03 +0200 Subject: [Pythonmac-SIG] Lanchd + virtualenv Message-ID: <4308.1253892663@arimaz.com> How about running the python exec directly from the virtual env : /Users/me/Desktop/virtual_python_root/bin/python Python 2.5.1 (r251:54863, Jun 17 2009, 20:37:34) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import wx >>> wx.__path__ ['/Users/me/Desktop/virtual_python_root/lib/python2.5/site-packages/wx-2.8-mac-unicode/wx'] it seams work work correctly (correct me if I'm wrong). I the wrote my plist like so : StandardOutPath test.log StandardErrorPath test-err.log EnvironmentVariables PYTHONPATH /Users/me/Desktop/virtual_python_root/lib/python2.5/site-packages:/Users/me/Desktop/myproj DYLD_LIBRARY_PATH /Users/me/Desktop/virtual_python_root/wx/2.8/lib KeepAlive SuccessfulExit Label com.test.virtualenv Program /Users/me/Desktop/virtual_python_root/bin/python ProgramArguments python.virtualenv ./launcher.py app1 WorkingDirectory /Users/me/Desktop/Arimaz-Trunk/src and again it seams to work (correct me again if I messed up somewhere). What is the advantage of using your method? Gabriel On Fri 25/09/09 17:01 , "Orestis Markou" orestis at orestis.gr sent: No need for a wrapper script. In recent versions of virtualenv, you can do this: activate_this = 'path/to/virtualenv/bin/activate_this.py' if os.path.exists(activate_this): execfile(activate_this, dict(__file__=activate_this)) On 25 ??? 2009, at 3:56 ?.?., Gabriel Rossetti wrote: > Hello everyone, > > I would like to create a Launchd plist entry to start a virtualenv > and run a python project. I created my plist, but I'm not sure how > to get it to activate the virtualenv and run the program. I thought > that maybe I could create two emtries : > > > > "http://www.apple.com/DTDs/PropertyList-1.0.dtd">; > > > Label > com.example.virtualenv > Program > source > ProgramArguments > > /path/to/myvirtualenv/bin/activate > > RunAtLoad > > > > Label > com.example.app > Program > python > ProgramArguments > > /path/to/myproj/launcher.py > start > > RunAtLoad > > > > > > but I'm not sure I can do that, and I have 2 programs to run for my > project, so would I create 3 entries like so : > > > > "http://www.apple.com/DTDs/PropertyList-1.0.dtd">; > > > > Label > com.example.virtualenv > Program > source > ProgramArguments > > /path/to/myvirtualenv/bin/activate > > RunAtLoad > > > > > Label > com.example.app1 > Program > python > ProgramArguments > > /path/to/myproj/launcher.py > app1 > start > > RunAtLoad > > > > > Label > com.example.app2 > Program > python > ProgramArguments > > /path/to/myproj/launcher.py > app2 > start > > RunAtLoad > > > > > Or is there a better/another way to do this? > _______________________________________________ > Pythonmac-SIG maillist - > http://mail.python.org/mailman/listinfo/pythonmac-sig Links: ------ [1] http://www.apple.com/DTDs/PropertyList-1.0.dtd%26quot%3B%26gt [2] http://www.apple.com/DTDs/PropertyList-1.0.dtd%26quot%3B%26gt [4] http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: From orestis at orestis.gr Fri Sep 25 17:33:23 2009 From: orestis at orestis.gr (Orestis Markou) Date: Fri, 25 Sep 2009 18:33:23 +0300 Subject: [Pythonmac-SIG] Lanchd + virtualenv In-Reply-To: <4308.1253892663@arimaz.com> References: <4308.1253892663@arimaz.com> Message-ID: <291CEF34-35D5-4B5C-BF88-094937ACBC33@orestis.gr> On 25 ??? 2009, at 6:31 ?.?., gabriel.rossetti at arimaz.com wrote: > How about running the python exec directly from the virtual env : > > and again it seams to work (correct me again if I messed up > somewhere). > > What is the advantage of using your method? None in particular, apart from the fact that a python script can be more flexible in deciding whether to activate a virtualenv or not, or even which virtualenv. If you are certain that the virtualenv will always be at the same place, then hardcoding it into the .plist is fine. In my case, this snippet appears in a pyobjc app, where I don't have a lot of control on which python is used (it's complicated). Orestis > > Gabriel > > > On Fri 25/09/09 17:01 , "Orestis Markou" orestis at orestis.gr sent: > No need for a wrapper script. In recent versions of virtualenv, you > can do this: > > activate_this = 'path/to/virtualenv/bin/activate_this.py' > if os.path.exists(activate_this): > execfile(activate_this, dict(__file__=activate_this)) > > On 25 ??? 2009, at 3:56 ?.?., Gabriel Rossetti wrote: > > > Hello everyone, > > > > I would like to create a Launchd plist entry to start a virtualenv > > and run a python project. I created my plist, but I'm not sure how > > to get it to activate the virtualenv and run the program. I thought > > that maybe I could create two emtries : > > > > > > > > "http://www.apple.com/DTDs/PropertyList-1.0.dtd%26quot%3B > %26gt">http://www.apple.com/DTDs/PropertyList-1.0.dtd">; > > > > > > Label > > com.example.virtualenv > > Program > > source > > ProgramArguments > > > > /path/to/myvirtualenv/bin/activate > > > > RunAtLoad > > > > > > > > Label > > com.example.app > > Program > > python > > ProgramArguments > > > > /path/to/myproj/launcher.py > > start > > > > RunAtLoad > > > > > > > > > > > > but I'm not sure I can do that, and I have 2 programs to run for my > > project, so would I create 3 entries like so : > > > > > > > > "http://www.apple.com/DTDs/PropertyList-1.0.dtd%26quot%3B > %26gt">http://www.apple.com/DTDs/PropertyList-1.0.dtd">; > > > > > > > > Label > > com.example.virtualenv > > Program > > source > > ProgramArguments > > > > /path/to/myvirtualenv/bin/activate > > > > RunAtLoad > > > > > > > > > > Label > > com.example.app1 > > Program > > python > > ProgramArguments > > > > /path/to/myproj/launcher.py > > app1 > > start > > > > RunAtLoad > > > > > > > > > > Label > > com.example.app2 > > Program > > python > > ProgramArguments > > > > /path/to/myproj/launcher.py > > app2 > > start > > > > RunAtLoad > > > > > > > > > > Or is there a better/another way to do this? > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig">http:// > mail.python.org/mailman/listinfo/pythonmac-sig > > From gabriel.rossetti at arimaz.com Fri Sep 25 18:25:37 2009 From: gabriel.rossetti at arimaz.com (Gabriel Rossetti) Date: Fri, 25 Sep 2009 18:25:37 +0200 Subject: [Pythonmac-SIG] Lanchd + virtualenv In-Reply-To: <291CEF34-35D5-4B5C-BF88-094937ACBC33@orestis.gr> References: <4308.1253892663@arimaz.com> <291CEF34-35D5-4B5C-BF88-094937ACBC33@orestis.gr> Message-ID: <4ABCEF01.1050808@arimaz.com> Orestis Markou wrote: > > On 25 ??? 2009, at 6:31 ?.?., gabriel.rossetti at arimaz.com wrote: > >> How about running the python exec directly from the virtual env : >> >> and again it seams to work (correct me again if I messed up somewhere). >> >> What is the advantage of using your method? > > None in particular, apart from the fact that a python script can be > more flexible in deciding whether to activate a virtualenv or not, or > even which virtualenv. If you are certain that the virtualenv will > always be at the same place, then hardcoding it into the .plist is fine. > > In my case, this snippet appears in a pyobjc app, where I don't have a > lot of control on which python is used (it's complicated). > > Orestis Ok, in my case I control everything so I'll hardcode it. I'll keep your msg in a corner as I may one day need it, thank you for the explanation and help. > >> >> Gabriel >> >> >> On Fri 25/09/09 17:01 , "Orestis Markou" orestis at orestis.gr sent: >> No need for a wrapper script. In recent versions of virtualenv, you >> can do this: >> >> activate_this = 'path/to/virtualenv/bin/activate_this.py' >> if os.path.exists(activate_this): >> execfile(activate_this, dict(__file__=activate_this)) >> >> On 25 ??? 2009, at 3:56 ?.?., Gabriel Rossetti wrote: >> >> > Hello everyone, >> > >> > I would like to create a Launchd plist entry to start a virtualenv >> > and run a python project. I created my plist, but I'm not sure how >> > to get it to activate the virtualenv and run the program. I thought >> > that maybe I could create two emtries : >> > >> > >> > >> > >> "http://www.apple.com/DTDs/PropertyList-1.0.dtd%26quot%3B%26gt">http://www.apple.com/DTDs/PropertyList-1.0.dtd">; >> >> > >> > >> > Label >> > com.example.virtualenv >> > Program >> > source >> > ProgramArguments >> > >> > /path/to/myvirtualenv/bin/activate >> > >> > RunAtLoad >> > >> > >> > >> > Label >> > com.example.app >> > Program >> > python >> > ProgramArguments >> > >> > /path/to/myproj/launcher.py >> > start >> > >> > RunAtLoad >> > >> > >> > >> > >> > >> > but I'm not sure I can do that, and I have 2 programs to run for my >> > project, so would I create 3 entries like so : >> > >> > >> > >> > >> "http://www.apple.com/DTDs/PropertyList-1.0.dtd%26quot%3B%26gt">http://www.apple.com/DTDs/PropertyList-1.0.dtd">; >> >> > >> > >> > >> > Label >> > com.example.virtualenv >> > Program >> > source >> > ProgramArguments >> > >> > /path/to/myvirtualenv/bin/activate >> > >> > RunAtLoad >> > >> > >> > >> > >> > Label >> > com.example.app1 >> > Program >> > python >> > ProgramArguments >> > >> > /path/to/myproj/launcher.py >> > app1 >> > start >> > >> > RunAtLoad >> > >> > >> > >> > >> > Label >> > com.example.app2 >> > Program >> > python >> > ProgramArguments >> > >> > /path/to/myproj/launcher.py >> > app2 >> > start >> > >> > RunAtLoad >> > >> > >> > >> > >> > Or is there a better/another way to do this? >> > _______________________________________________ >> > Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> > >> http://mail.python.org/mailman/listinfo/pythonmac-sig">http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> >> > From Chris.Barker at noaa.gov Fri Sep 25 18:51:24 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 25 Sep 2009 09:51:24 -0700 Subject: [Pythonmac-SIG] py2app DistUtilsPlatformError[Sec=Unclassified] In-Reply-To: <1253847876.3166.3.camel@mjoakes-desktop> References: <1253671005.4022.21.camel@mjoakes-desktop> <20090923132255.GB25748@panix.com> <4ABA4B06.3000609@noaa.gov> <20090923163646.GA26464@panix.com> <20090924131338.GA21078@panix.com> <4ABBC381.4090500@noaa.gov> <1253847876.3166.3.camel@mjoakes-desktop> Message-ID: <4ABCF50C.8080408@noaa.gov> mathew oakes wrote: > Cairo appears to be only available via macports on mac, and I'm not > thorough enough to mix bits of different python distributions, so must > do everything through one. You should be able to use a macports Cairo lib with a non-macports pyCairo, but if you've got something working... > I had a redundant import from wx.lib.cairo -- (was trying to display > generated svg files in a wx window. There were no simple recipes to be > found There is this: http://code.google.com/p/wxpsvg/ It's really more of a proof of concept than production code, but it might meet your needs. You need to get the code form svn: http://code.google.com/p/wxpsvg/source/checkout -Chris (and no, I'm not the Chris that wrote that) -- 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 Chris.Barker at noaa.gov From gabriel.rossetti at arimaz.com Fri Sep 25 19:42:42 2009 From: gabriel.rossetti at arimaz.com (Gabriel Rossetti) Date: Fri, 25 Sep 2009 19:42:42 +0200 Subject: [Pythonmac-SIG] [wxPython-users] Re: building wxPython on Mac OS X (10.5) In-Reply-To: <4ABBB04A.4060705@alldunn.com> References: <4ABBB04A.4060705@alldunn.com> Message-ID: <4ABD0112.4070601@arimaz.com> Robin Dunn wrote: > On 9/24/09 6:46 AM, gabriel.rossetti at arimaz.com wrote: > > >> it appears linked with the wrong version of >> /usr/lib/libwx_macud-2.8.0.dylib, is that correct? >> > > Yes. > > >> If so, how can I fix >> it? >> >> > > Double check the wxWidgets build and install steps. It should have used > your {prefix}/lib path for the wxMac lib but it fell back to the one > distributed by Apple in /usr/lib instead. Hmm... You didn't use > --enable-monolithic in your configure step, that's probably the problem. > > Ok, I ran it again and it works now, I must have made a mistake somewhere. I didn't use --enable-monolithic though > Note that the path to the dylib is embedded in the extension module .so > so even when you get this working at your install locations there will > still be issues with having something self contained that can be zipped > up and unzipped elsewhere. To work around that you're either going to > have to set DYLD_LIBRARY_PATH or you can use install_name_tool to change > the embedded path name. You can make that embedded name be relative to > the executable or the image loading the dylib (the .so extension modules > in this case) by using "@executable_path" or "@loader_path" in the path > name. > Ok, thanks for the tip :-) From druths at ruthsresearch.org Sun Sep 27 05:32:34 2009 From: druths at ruthsresearch.org (Derek Ruths) Date: Sat, 26 Sep 2009 23:32:34 -0400 Subject: [Pythonmac-SIG] SIP 4.9 building error on Mac Message-ID: <2E2FB098-C3D4-4951-8DB3-548FE71BE6B2@ruthsresearch.org> I've just downloaded SIP 4.9 and discovered that building it fails on my Mac with the error below. I've verified that "arch" is not currently a named argument accepted by ProgramMakefile in sipconfig.py, causing the error. I'm emailing the list to notify others and in the hope that this can get quickly taken care of. Thanks! D This is SIP 4.9 for Python 2.6.2 on darwin. The SIP code generator will be installed in /Library/Frameworks/OryxPython.framework/Versions/2.6/bin. The SIP module will be installed in /Library/Frameworks/OryxPython.framework/Versions/2.6/lib/python2.6/ site-packages. The SIP header file will be installed in /Library/Frameworks/OryxPython.framework/Versions/2.6/include. The default directory to install .sip files in is /Library/Frameworks/OryxPython.framework/Versions/2.6/share/sip. The platform/compiler configuration is macx-g++. MacOS/X binaries will be created for ppc, i386, x86_64. MacOS/X universal binaries will be created using /Developer/SDKs/MacOSX10.5.sdk. Creating sipconfig.py... Creating top level Makefile... Creating sip code generator Makefile... An internal error occured. Please report all the output from the program, including the following traceback, to support at riverbankcomputing.com. Traceback (most recent call last): File "configure.py", line 459, in main(sys.argv) File "configure.py", line 450, in main create_makefiles(macros) File "configure.py", line 275, in create_makefiles arch=opts.arch TypeError: __init__() got an unexpected keyword argument 'arch' make[2]: *** No targets specified and no makefile found. Stop. make[1]: *** [all] Error 2 make[2]: *** No rule to make target `install'. Stop. make[1]: *** [install] Error 2 make: *** [build_sip] Error 2 From woklist at kyngchaos.com Sun Sep 27 21:20:38 2009 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sun, 27 Sep 2009 14:20:38 -0500 Subject: [Pythonmac-SIG] SIP 4.9 building error on Mac In-Reply-To: <2E2FB098-C3D4-4951-8DB3-548FE71BE6B2@ruthsresearch.org> References: <2E2FB098-C3D4-4951-8DB3-548FE71BE6B2@ruthsresearch.org> Message-ID: <888903F8-866C-4490-9669-09960AD0C5CA@kyngchaos.com> Works for me with system python 2.5 on Leopard and 2.6 on Snow, and python.org Python 2.6 on Leopard. Though I didn't try 64bit on Snow. Maybe somehow an old sipconfig got imported? Try removing the old installed SIP. I had this problem in the dev version right after the option was added (I'm the cause of the new options, to support differing combinations of 32/64bit Qt and 32/64bit Python :), but it eventaully fixed itself - I was trying a lot of different things at the time, but I think cleaning out old SIPs did the trick. On Sep 26, 2009, at 10:32 PM, Derek Ruths wrote: > I've just downloaded SIP 4.9 and discovered that building it fails > on my Mac with the error below. I've verified that "arch" is not > currently a named argument accepted by ProgramMakefile in > sipconfig.py, causing the error. I'm emailing the list to notify > others and in the hope that this can get quickly taken care of. > Thanks! > > D > > This is SIP 4.9 for Python 2.6.2 on darwin. > The SIP code generator will be installed in > /Library/Frameworks/OryxPython.framework/Versions/2.6/bin. > The SIP module will be installed in > /Library/Frameworks/OryxPython.framework/Versions/2.6/lib/python2.6/ > site-packages. > The SIP header file will be installed in > /Library/Frameworks/OryxPython.framework/Versions/2.6/include. > The default directory to install .sip files in is > /Library/Frameworks/OryxPython.framework/Versions/2.6/share/sip. > The platform/compiler configuration is macx-g++. > MacOS/X binaries will be created for ppc, i386, x86_64. > MacOS/X universal binaries will be created using > /Developer/SDKs/MacOSX10.5.sdk. > Creating sipconfig.py... > Creating top level Makefile... > Creating sip code generator Makefile... > An internal error occured. Please report all the output from the > program, > including the following traceback, to support at riverbankcomputing.com. > Traceback (most recent call last): > File "configure.py", line 459, in > main(sys.argv) > File "configure.py", line 450, in main > create_makefiles(macros) > File "configure.py", line 275, in create_makefiles > arch=opts.arch > TypeError: __init__() got an unexpected keyword argument 'arch' > make[2]: *** No targets specified and no makefile found. Stop. > make[1]: *** [all] Error 2 > make[2]: *** No rule to make target `install'. Stop. > make[1]: *** [install] Error 2 > make: *** [build_sip] Error 2 > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig ----- William Kyngesburye http://www.kyngchaos.com/ "Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence.... - the wisdom of Tarzan From ronaldoussoren at mac.com Tue Sep 29 12:15:55 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 29 Sep 2009 12:15:55 +0200 Subject: [Pythonmac-SIG] Lanchd + virtualenv In-Reply-To: <4ABCBDE6.6030403@arimaz.com> References: <4ABCBDE6.6030403@arimaz.com> Message-ID: <9B191D07-1AF3-4337-9652-BFA2BB694164@mac.com> On 25 Sep, 2009, at 14:56, Gabriel Rossetti wrote: > Hello everyone, > > I would like to create a Launchd plist entry to start a virtualenv > and run a python project. I created my plist, but I'm not sure how > to get it to activate the virtualenv and run the program. Unless you do something special you don't have to activate the virtualenv at all, just make sure that the '#!' line in the script you're starting refers to the python in the virtualenv (instead of having '#!/usr/bin/env python'). I have a virtualenv containing a mercurial installation and regularly use the mercurial command-line tools without activating the virtualenv. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From herzbube at herzbube.ch Wed Sep 30 11:30:06 2009 From: herzbube at herzbube.ch (Patrick =?iso-8859-1?Q?N=E4f?=) Date: Wed, 30 Sep 2009 11:30:06 +0200 (CEST) Subject: [Pythonmac-SIG] Module build fails because distutils adds "-isysroot" Message-ID: <59033abb711823e0c541205377365369.squirrel@www.herzbube.ch> Hi folks I'm currently writing a very simple Python module in C that provides an interface to libaprutil's MD5 routines. I compile my module using distutils, as per instructions in the "Building C and C++ Extensions with distutils" chapter of the official Python docs. Since Mac OS X has libaprutil pre-installed, it seems natural that I try to use the system version of the library. My Python module's .c file therefore contains the following #include directive: #include Everything works fine (module compiles and I can use it) as long as I use the system version of Python (2.5.1) to compile the module. The problem is that I *really* need to build the module with Python 2.6 or newer, and this is where my trouble starts. I have Python 3.1.1 installed in /Library/Frameworks/Python, and with this version of Python my module's build fails miserably, like this: tharbad:~ patrick$ /Library/Frameworks/Python.framework/Versions/3.1/bin/python3.1 ./setup.py build_ext --inplace running build_ext building 'aprmd5' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -I/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1 -c aprmd5.c -o build/temp.macosx-10.3-fat-3.1/aprmd5.o aprmd5.c:43:60: aprmd5.c:43:60: error: apr-1/apr_md5.h: No such file or directory [...] The problem here is that the gcc option "-isysroot" moves the root for system includes to the SDK directory (/Developer/SDKs/MacOSX10.4u.sdk), away from the normal root (/). Unfortunately, the SDK does not contain the header , which causes the build to fail. Where does "-isysroot" come from? Not from my module, it's added automatically by distutils. I believe I have correctly diagnosed the problem, and I can certainly work around it *somehow* in my module, but since I am rather new to Python I have trouble deciding on a solution that is appropriate. I am therefore writing to this list, hoping someone reading this can give me some advice. 1) Is my problem a known situation for which there is a generally accepted, best-practice solution? If so, a pointer in the right direction would be most welcome. If not, what would seem to be a good solution? Make my own build of libaprutil using the MacOSX10.4u SDK? Rely on a third-party build of libaprutil (e.g. fink)? Force the compiler to use the system's libaprutil? 2) Is this a bug in the MacOSX10.4u SDK, i.e. should the SDK contain the headers for libaprutil? This seems possible to me, because the SDK certainly contains headers for other libraries (e.g. openssl), so why not for libaprutil? 3) Is this a bug in the Python distribution, i.e. should the Python 3.1.1 distutils *not* add "-isysroot"? I think this is not the case, distutils should add the option because Python probably was built with the SDK. 4) Is my work obsolete because someone already has written a Python module that interfaces libaprutil and has solved all of my problems? If this is so, again, pointers would be very welcome. Thanks for your time Patrick System setup: - Mac OS X 10.5.8 (includes libaprutil 1.2.7) - gcc --version: powerpc-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) - Yes, I *do* have the MacOSX10.4u SDK installed :-) - Python 3.1.1, downloaded from http://www.python.org/ftp/python/3.1.1/python-3.1.1.dmg (I have also tried Python 2.6.2 and 3.0.1, with the same result) From gabriel.rossetti at arimaz.com Wed Sep 30 17:31:19 2009 From: gabriel.rossetti at arimaz.com (Gabriel Rossetti) Date: Wed, 30 Sep 2009 17:31:19 +0200 Subject: [Pythonmac-SIG] Lanchd + virtualenv In-Reply-To: <9B191D07-1AF3-4337-9652-BFA2BB694164@mac.com> References: <4ABCBDE6.6030403@arimaz.com> <9B191D07-1AF3-4337-9652-BFA2BB694164@mac.com> Message-ID: <4AC379C7.2050009@arimaz.com> Ronald Oussoren wrote: > > On 25 Sep, 2009, at 14:56, Gabriel Rossetti wrote: > >> Hello everyone, >> >> I would like to create a Launchd plist entry to start a virtualenv >> and run a python project. I created my plist, but I'm not sure how to >> get it to activate the virtualenv and run the program. > > Unless you do something special you don't have to activate the > virtualenv at all, just make sure that the '#!' line in the script > you're starting refers to the python in the virtualenv (instead of > having '#!/usr/bin/env python'). > > I have a virtualenv containing a mercurial installation and regularly > use the mercurial command-line tools without activating the virtualenv. > > Ronald > Ok, thanks, so from what I understand I only need to activate it if I have to install a package into it. Gabriel From dpeterson at enthought.com Wed Sep 30 18:17:04 2009 From: dpeterson at enthought.com (Dave Peterson) Date: Wed, 30 Sep 2009 11:17:04 -0500 Subject: [Pythonmac-SIG] Module build fails because distutils adds "-isysroot" In-Reply-To: <59033abb711823e0c541205377365369.squirrel@www.herzbube.ch> References: <59033abb711823e0c541205377365369.squirrel@www.herzbube.ch> Message-ID: <4AC38480.3010204@enthought.com> Hi Patrick, Patrick N?f wrote: > ... my module's > build fails miserably, like this: > > tharbad:~ patrick$ > /Library/Frameworks/Python.framework/Versions/3.1/bin/python3.1 ./setup.py > build_ext --inplace > running build_ext > building 'aprmd5' extension > gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk > -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 > -I/Library/Frameworks/Python.framework/Versions/3.1/include/python3.1 -c > aprmd5.c -o build/temp.macosx-10.3-fat-3.1/aprmd5.o > aprmd5.c:43:60: aprmd5.c:43:60: error: apr-1/apr_md5.h: No such file or > directory > [...] > > The problem here is that the gcc option "-isysroot" moves the root for > system includes to the SDK directory (/Developer/SDKs/MacOSX10.4u.sdk), > away from the normal root (/). Unfortunately, the SDK does not contain the > header , which causes the build to fail. Where does > "-isysroot" come from? Not from my module, it's added automatically by > distutils. > The options distutils uses come from the file at /lib/python2.5/config/Makefile. I don't think there is any distutils API provided to override/change these, just ways to append to them when specifying your extension configuration. These options are used because they are the same ones used when building that Python distribution. So my first suggestion is that you try redefining the -isysroot option in the flags you can specify in your extension's config. There is a good chance the compiler will use the last specification on the line rather than doing something else when it gets two values. If that doesn't work, the only other thing I can think of is to temporarily edit the config/Makefile to remove / change the inclusion of the -isysroot option. HTHs, -- Dave From jgarbers at roverapps.com Wed Sep 30 20:09:24 2009 From: jgarbers at roverapps.com (Jeff Garbers) Date: Wed, 30 Sep 2009 14:09:24 -0400 Subject: [Pythonmac-SIG] Problems getting started with py2app and wxPython Message-ID: Hello! I'm just getting started trying to build a standalone Mac application based on wxPython. I'm on OS X 10.6.1, using Python 2.6.1 as distributed with the OS. The app is a simple "hello world" type of thing: > import wx > > class MyApp(wx.App): > def OnInit(self): > frame = wx.Frame(None, -1, "Hello from wxPython") > frame.Show(True) > self.SetTopWindow(frame) > return True > > app = MyApp(0) > app.MainLoop() > I generate my setup.py with py2applet and build the app: > py2applet --make-setup wxtest.py > python setup.py py2app All appears to go well, but when I run the resulting app, I get an error immediately: > wxtest Error > An unexpected error has occurred during execution of the main script > > ImportError: '/usr/lib/python2.6/lib-dynload/wx/_core_.so' not found Reviewing the output from py2app, I notice that that module -- among others -- was stripped: > ... > stripping libwx_macud-2.8.0.dylib > stripping _controls_.so > stripping wxtest > stripping _core_.so > stripping _misc_.so > stripping _gdi_.so > stripping _windows_.so I've been spoiled by things "just working" in both OS X and Python, so this sort of thing throws me for a loop, especially as a rookie. Why is pyapp stripping those modules, and how can I keep it from doing so? Can anybody suggest a fix or point me in the right direction? Thanks in advance for any help you can offer. From Chris.Barker at noaa.gov Wed Sep 30 20:37:44 2009 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 30 Sep 2009 11:37:44 -0700 Subject: [Pythonmac-SIG] Problems getting started with py2app and wxPython In-Reply-To: References: Message-ID: <4AC3A578.4050906@noaa.gov> Jeff Garbers wrote: > Hello! I'm just getting started trying to build a standalone Mac > application based on wxPython. I'm on OS X 10.6.1, using Python 2.6.1 > as distributed with the OS. note that py2ap will not bundle up python itself in this case, and your app will only work on 10.6 systems. >> ImportError: '/usr/lib/python2.6/lib-dynload/wx/_core_.so' not found hmmm -- this means it's looking in your system, rather than the bundle, for the wx libs... > Reviewing the output from py2app, I notice that that module -- among > others -- was stripped: > >> ... >> stripping libwx_macud-2.8.0.dylib >> stripping _controls_.so >> stripping wxtest >> stripping _core_.so >> stripping _misc_.so >> stripping _gdi_.so >> stripping _windows_.so > Why is pyapp stripping those modules, stripping does not mean removing -- I thin it means removing debug symbols, etc, i.e. making it smaller. It should not cause this problem. Aside from putting dylibs into the bundle, py2app also re-writes the headers, so that they are linked against the copies in the bundle, rather than the system ones -- it looks like this has gone awry. Do take a look in the bundle ans see what's there. It's very helpful for debugging. I'm not running 10.6, or python2.6, so I'm not much help here, but do make sure that you are running the latest py2app -- there have been 2.6 fixes recently. You also might try installing a Python.org build, and using that instead of Apple's -- you'll need to do that if you want to support older systems 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 Chris.Barker at noaa.gov From ronaldoussoren at mac.com Wed Sep 30 21:55:30 2009 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 30 Sep 2009 21:55:30 +0200 Subject: [Pythonmac-SIG] Lanchd + virtualenv In-Reply-To: <4AC379C7.2050009@arimaz.com> References: <4ABCBDE6.6030403@arimaz.com> <9B191D07-1AF3-4337-9652-BFA2BB694164@mac.com> <4AC379C7.2050009@arimaz.com> Message-ID: <33626F8C-C81F-460F-AF0C-09886C3D2368@mac.com> On 30 Sep, 2009, at 17:31, Gabriel Rossetti wrote: > Ronald Oussoren wrote: >> >> On 25 Sep, 2009, at 14:56, Gabriel Rossetti wrote: >> >>> Hello everyone, >>> >>> I would like to create a Launchd plist entry to start a virtualenv >>> and run a python project. I created my plist, but I'm not sure how >>> to get it to activate the virtualenv and run the program. >> >> Unless you do something special you don't have to activate the >> virtualenv at all, just make sure that the '#!' line in the script >> you're starting refers to the python in the virtualenv (instead of >> having '#!/usr/bin/env python'). >> >> I have a virtualenv containing a mercurial installation and >> regularly use the mercurial command-line tools without activating >> the virtualenv. >> >> Ronald >> > Ok, thanks, so from what I understand I only need to activate it if > I have to install a package into it. You only have to activate when you need to have executables from the virtualenv on your shell's search-path (that is $PATH). Activating is handy when you are installing software, but is also needed when a script in the virtualenv executes another script in the environment and assumes that that other script is on the search-path. Ronald > > Gabriel -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2224 bytes Desc: not available URL: From harijay at gmail.com Wed Sep 30 17:42:53 2009 From: harijay at gmail.com (hari jayaram) Date: Wed, 30 Sep 2009 11:42:53 -0400 Subject: [Pythonmac-SIG] Command line imports module but built *.app complains No module yaml Message-ID: Hello, I am using the svn build of py2app. I created a test app with the following setup file ( see below). Now if I create a test app with command python setup.py py2app -A When I try to open the dist file open dist/GridZilla.app I get a popup no module found yaml I know the yaml module is present because I see it in site-packages and the script GridZilla.py starts up just fine from the shell where the py2app was run. I can also see the module in the GridZilla.app /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml Is there a reason why the GridZilla.app created cannot "see" the yaml module either in /Library/Python/2.5/site-packages or inside the *.app Bundle. How do I get around this? . I have attached a list of my site-packages. I tried to create the app with and without packages specified in the OPTIONS dict. But not matter what the app complains about "No Module yaml" I am attaching a screen dump of the build process without the -A option Thanks for your help Hari """ This is a setup.py script generated by py2applet Usage: ?? ?python setup.py py2app """ from setuptools import setup APP = ['GridZilla.py'] DATA_FILES = [] OPTIONS = {'argv_emulation': True, ?'iconfile': '/Users/hari/gzilla/src/gzilla_ico_fin.icns', ?'packages': 'yaml'} setup( ?? ?app=APP, ?? ?data_files=DATA_FILES, ?? ?options={'py2app': OPTIONS}, ?? ?setup_requires=['py2app'], ) My site-packages: hazel:yaml hari$ ls /Library/Python/2.5/site-packages/ PyYAML-3.09-py2.5.egg-info _rl_accel.so epydoc modulegraph-0.7.2.dev_r21-py2.5.egg reportlab setuptools.pth README altgraph-0.6.8.dev_r9-py2.5.egg epydoc-3.0.1-py2.5.egg-info py2app-0.4.2-py2.5.egg reportlab-2.3-py2.5.egg-info sgmlop.so _renderPM.so easy-install.pth macholib-1.2.1-py2.5.egg pyHnj.so setuptools-0.6c9-py2.5.egg yaml -------------- next part -------------- hazel:src hari$ python setup.py py2app running py2app creating /Users/hari/gzilla/src/build creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/temp creating /Users/hari/gzilla/src/dist creating build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/lib-dynload creating build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/Frameworks *** filtering dependencies *** 448 total 371 filtered 2 orphaned 77 remaining *** create binaries *** creating python loader for extension '_rl_accel' creating python loader for extension 'sgmlop' *** byte compile python files *** byte-compiling /Library/Python/2.5/site-packages/py2app-0.4.2-py2.5.egg/py2app/bootstrap/argv_emulation.py to argv_emulation.pyc byte-compiling /Library/Python/2.5/site-packages/py2app-0.4.2-py2.5.egg/py2app/bootstrap/boot_app.py to boot_app.pyc byte-compiling /Library/Python/2.5/site-packages/py2app-0.4.2-py2.5.egg/py2app/bootstrap/chdir_resource.py to chdir_resource.pyc byte-compiling /Library/Python/2.5/site-packages/py2app-0.4.2-py2.5.egg/py2app/bootstrap/disable_linecache.py to disable_linecache.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/__init__.py to reportlab/__init__.pyc creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/PyFontify.py to reportlab/lib/PyFontify.pyc creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/lib byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/__init__.py to reportlab/lib/__init__.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/abag.py to reportlab/lib/abag.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/arciv.py to reportlab/lib/arciv.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/boxstuff.py to reportlab/lib/boxstuff.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/colors.py to reportlab/lib/colors.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/enums.py to reportlab/lib/enums.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/fonts.py to reportlab/lib/fonts.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/geomutils.py to reportlab/lib/geomutils.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/logger.py to reportlab/lib/logger.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/pagesizes.py to reportlab/lib/pagesizes.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/pdfencrypt.py to reportlab/lib/pdfencrypt.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/randomtext.py to reportlab/lib/randomtext.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/rltempfile.py to reportlab/lib/rltempfile.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/sequencer.py to reportlab/lib/sequencer.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/styles.py to reportlab/lib/styles.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/textsplit.py to reportlab/lib/textsplit.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/units.py to reportlab/lib/units.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/utils.py to reportlab/lib/utils.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/lib/xmllib.py to reportlab/lib/xmllib.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfbase/__init__.py to reportlab/pdfbase/__init__.pyc creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/pdfbase byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfbase/_fontdata.py to reportlab/pdfbase/_fontdata.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfbase/pdfdoc.py to reportlab/pdfbase/pdfdoc.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfbase/pdfmetrics.py to reportlab/pdfbase/pdfmetrics.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfbase/pdfutils.py to reportlab/pdfbase/pdfutils.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfbase/rl_codecs.py to reportlab/pdfbase/rl_codecs.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfgen/__init__.py to reportlab/pdfgen/__init__.pyc creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/pdfgen byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfgen/canvas.py to reportlab/pdfgen/canvas.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfgen/pathobject.py to reportlab/pdfgen/pathobject.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfgen/pdfgeom.py to reportlab/pdfgen/pdfgeom.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfgen/pdfimages.py to reportlab/pdfgen/pdfimages.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/pdfgen/textobject.py to reportlab/pdfgen/textobject.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/platypus/__init__.py to reportlab/platypus/__init__.pyc creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/platypus byte-compiling /Library/Python/2.5/site-packages/reportlab/platypus/doctemplate.py to reportlab/platypus/doctemplate.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/platypus/flowables.py to reportlab/platypus/flowables.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/platypus/frames.py to reportlab/platypus/frames.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/platypus/paragraph.py to reportlab/platypus/paragraph.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/platypus/paraparser.py to reportlab/platypus/paraparser.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/platypus/tables.py to reportlab/platypus/tables.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/platypus/xpreformatted.py to reportlab/platypus/xpreformatted.pyc byte-compiling /Library/Python/2.5/site-packages/reportlab/rl_config.py to reportlab/rl_config.pyc byte-compiling /Users/hari/gridder/__init__.py to gridder/__init__.pyc creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder byte-compiling /Users/hari/gridder/awarepdfwriter.py to gridder/awarepdfwriter.pyc byte-compiling /Users/hari/gridder/buffercomponent.py to gridder/buffercomponent.pyc byte-compiling /Users/hari/gridder/component.py to gridder/component.pyc byte-compiling /Users/hari/gridder/componentlist.py to gridder/componentlist.pyc byte-compiling /Users/hari/gridder/masterplate.py to gridder/masterplate.pyc byte-compiling /Users/hari/gridder/pdfwriterlandscape.py to gridder/pdfwriterlandscape.pyc byte-compiling /Users/hari/gridder/plate.py to gridder/plate.pyc byte-compiling /Users/hari/gridder/plateliberror.py to gridder/plateliberror.pyc byte-compiling /Users/hari/gridder/platepdfwriter.py to gridder/platepdfwriter.pyc byte-compiling /Users/hari/gridder/well.py to gridder/well.pyc byte-compiling /Users/hari/gzilla/src/GridZilla.py to GridZilla.pyc byte-compiling /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/temp/_rl_accel.py to _rl_accel.pyc byte-compiling /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/temp/sgmlop.py to sgmlop.pyc creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/00readme.txt -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/bitstream-vera-license.txt -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/DarkGarden-copying-gpl.txt -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/DarkGarden-copying.txt -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/DarkGarden-readme.txt -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/DarkGarden.sfd -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/DarkGardenMK.afm -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/DarkGardenMK.pfb -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/Vera.ttf -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/VeraBd.ttf -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/VeraBI.ttf -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts copying /Library/Python/2.5/site-packages/reportlab/fonts/VeraIt.ttf -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/reportlab/fonts creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/branches copying /Users/hari/gridder/.git/COMMIT_EDITMSG -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git copying /Users/hari/gridder/.git/config -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git copying /Users/hari/gridder/.git/description -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git copying /Users/hari/gridder/.git/FETCH_HEAD -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git copying /Users/hari/gridder/.git/gitk.cache -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git copying /Users/hari/gridder/.git/HEAD -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/applypatch-msg.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/commit-msg.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/post-commit.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/post-receive.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/post-update.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/pre-applypatch.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/pre-commit.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/pre-rebase.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/prepare-commit-msg.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/hooks/update.sample -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/hooks copying /Users/hari/gridder/.git/index -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/info copying /Users/hari/gridder/.git/info/exclude -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/info creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/logs copying /Users/hari/gridder/.git/logs/HEAD -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/logs creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/logs/refs creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/logs/refs/heads copying /Users/hari/gridder/.git/logs/refs/heads/master -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/logs/refs/heads creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/logs/refs/remotes creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/logs/refs/remotes/origin copying /Users/hari/gridder/.git/logs/refs/remotes/origin/HEAD -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/logs/refs/remotes/origin copying /Users/hari/gridder/.git/logs/refs/remotes/origin/master -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/logs/refs/remotes/origin creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/01 copying /Users/hari/gridder/.git/objects/01/11f832ed5518b05d96d07ebc9ea1b2f4786e3b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/01 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/02 copying /Users/hari/gridder/.git/objects/02/3f84b341062578f645df27fdd75d96e177a76d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/02 copying /Users/hari/gridder/.git/objects/02/ab1d9ea774239fab03797f73c081ae7dc4155a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/02 copying /Users/hari/gridder/.git/objects/02/ffc7c990d802c94ae5f7f346fecaf7642211c6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/02 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/03 copying /Users/hari/gridder/.git/objects/03/1e52eacd7e6a694e93cbeb86b6c236af679232 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/03 copying /Users/hari/gridder/.git/objects/03/b199db8860d42e8341056db91364576ef03d26 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/03 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/04 copying /Users/hari/gridder/.git/objects/04/a4f1294807c862939c4533846ee88dbbdeebec -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/04 copying /Users/hari/gridder/.git/objects/04/d274297351f761aba94e049be373f4b0903d9d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/04 copying /Users/hari/gridder/.git/objects/04/f25bc4003dfc2fdd4df44846e11cdaf9e2c8a2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/04 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/06 copying /Users/hari/gridder/.git/objects/06/780ad541f1e2cc57e542b7ecc60c2aeb3536dd -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/06 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/07 copying /Users/hari/gridder/.git/objects/07/36fb35b033bf4e72656af6153ab7db01ba66a1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/07 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/08 copying /Users/hari/gridder/.git/objects/08/2fcb6eebff6a63ba77cefc946c24b0e5a5ee86 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/08 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/09 copying /Users/hari/gridder/.git/objects/09/51714c9ece1d5765864f784b33841024d50020 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/09 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0a copying /Users/hari/gridder/.git/objects/0a/16ccb46148a6d533f7e0ee0893eb531227481b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0a copying /Users/hari/gridder/.git/objects/0a/eb7a6502d4d408b4ed2e6226b6b279fb2de4ec -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0a creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0b copying /Users/hari/gridder/.git/objects/0b/2de95b417f2b3793e8a0e35c57c753c4f2c835 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0b copying /Users/hari/gridder/.git/objects/0b/d96d3db7e1b6d649885add3336ad8d194465dd -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0b creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0c copying /Users/hari/gridder/.git/objects/0c/3eb27a2a52151d1d3ad1cfde56d8aaf1c04de1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0c creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0d copying /Users/hari/gridder/.git/objects/0d/73b404a0f92462265a7c4c4a4d8e35812673ac -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0d copying /Users/hari/gridder/.git/objects/0d/be9950ca7bce7a3b61f6619686f04aa919217b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0d creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0e copying /Users/hari/gridder/.git/objects/0e/731315cc93a495ac31d3d821bad945d1050bf6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0e copying /Users/hari/gridder/.git/objects/0e/e2b550f42a431a896a8909d16d0fa0a2355dfe -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0e creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0f copying /Users/hari/gridder/.git/objects/0f/3eb37e557762a53079f1fd94ccf8834a023d54 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/0f creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/10 copying /Users/hari/gridder/.git/objects/10/eae34900b4c667636175b6b4b0f0bbf69754d9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/10 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/11 copying /Users/hari/gridder/.git/objects/11/6dbac2b2bde1f9346ebc23b3dff733646c143f -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/11 copying /Users/hari/gridder/.git/objects/11/6e54ec9b6fc79396c990ee81110924cc372d28 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/11 copying /Users/hari/gridder/.git/objects/11/8bd2f8670f7e19fdebd409e255fa4c23f3e118 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/11 copying /Users/hari/gridder/.git/objects/11/d6e0c1e6433e616341808d6743e2b927b8c230 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/11 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/12 copying /Users/hari/gridder/.git/objects/12/0704b68551fd00e8a8250bec140512efe9b95d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/12 copying /Users/hari/gridder/.git/objects/12/69944e1af936238073bfbe03cbc995187c82e1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/12 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/14 copying /Users/hari/gridder/.git/objects/14/e20f45025f1df4037553e9f09ced19901c916a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/14 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/15 copying /Users/hari/gridder/.git/objects/15/5ec2066500b9076c5274e30c3ab4a2ea93930a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/15 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/16 copying /Users/hari/gridder/.git/objects/16/25b39663f449f6ac09d04981ef77133247414f -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/16 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/17 copying /Users/hari/gridder/.git/objects/17/af8f27d2d75362ee75fad5760237667572c032 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/17 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/18 copying /Users/hari/gridder/.git/objects/18/069e95d158f08e0c7cd5a31bb5e0f8210f4646 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/18 copying /Users/hari/gridder/.git/objects/18/3eec8ea6bac6e8904e18f6f596bdc087caeeb1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/18 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/19 copying /Users/hari/gridder/.git/objects/19/731c06ff1c3cfb1cf983b8ce9a74ffad80fc1d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/19 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1a copying /Users/hari/gridder/.git/objects/1a/06c757c5fa04c3a3e37f1993a391dffeb4ad93 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1a copying /Users/hari/gridder/.git/objects/1a/ad33eb1ec404cffc95e90ec1761cdd9f7e46ee -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1a copying /Users/hari/gridder/.git/objects/1a/d2fff187dba233ca621108f26fa2df7d5ab040 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1a copying /Users/hari/gridder/.git/objects/1a/d8a838085266209e35430e7be78782d56e2bee -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1a copying /Users/hari/gridder/.git/objects/1a/f81c438a2da3aaef9aebdd61e96f65145307fc -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1a creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1b copying /Users/hari/gridder/.git/objects/1b/b8de9881fa3b62a6456852874b9ebead94568a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1b copying /Users/hari/gridder/.git/objects/1b/ba75a01fe8054e5960fab30355e95ddac78cf2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1b creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1c copying /Users/hari/gridder/.git/objects/1c/a03fd8aa85cd18b93ac63ff6447199d9799dcb -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1c copying /Users/hari/gridder/.git/objects/1c/b588a1c45e8f3a0e4508b0f1dd1a161ab83f42 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1c creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1d copying /Users/hari/gridder/.git/objects/1d/a7a63be550610d842185830cca4730bf465dc3 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1d creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1e copying /Users/hari/gridder/.git/objects/1e/51a28d32f08d7a79c8bc59a3f7c5bd123d3a7a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1e copying /Users/hari/gridder/.git/objects/1e/beb6f6e93bc5e5e94bd1e86ec5c5146c760ca4 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1e creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1f copying /Users/hari/gridder/.git/objects/1f/1b7a7a81a1dbbc364074b060f8d7d9bf811e90 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/1f creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/21 copying /Users/hari/gridder/.git/objects/21/0db79f94696ed3c35a97da443765082c82f609 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/21 copying /Users/hari/gridder/.git/objects/21/d00e0abbe9114b99bd8bb232328cafb0f52741 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/21 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/24 copying /Users/hari/gridder/.git/objects/24/5795c93961506bd42b735e9086783bef4c6d9c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/24 copying /Users/hari/gridder/.git/objects/24/edf52adb237fe4071b7af2b181a07e1db301df -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/24 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/26 copying /Users/hari/gridder/.git/objects/26/387e25374f02171f00b3d01519596e25efab65 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/26 copying /Users/hari/gridder/.git/objects/26/cb61f7c8e88150bea7b951354e7bb0a83769e0 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/26 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/28 copying /Users/hari/gridder/.git/objects/28/28f3f1cc3987a9206badaf415b7615b1df2e65 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/28 copying /Users/hari/gridder/.git/objects/28/3913a29f940e377c1c8266c89767d537f5a404 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/28 copying /Users/hari/gridder/.git/objects/28/e9164273f3753daf9c3ee9f315638a1752b8a6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/28 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/29 copying /Users/hari/gridder/.git/objects/29/e7a37ad2bc8898f8dc37108ed946d12f0c31a4 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/29 copying /Users/hari/gridder/.git/objects/29/f20af3c07b7b0eeb68456c5e57b46c6f9779f8 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/29 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2a copying /Users/hari/gridder/.git/objects/2a/260482368b8b927befedc8502293e35a2739b9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2a creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2b copying /Users/hari/gridder/.git/objects/2b/5b2456e65aeb1c6b25a8ba50341b12b16bfcbc -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2b copying /Users/hari/gridder/.git/objects/2b/617043dfbd83634c30b45b1810a739c89d56cb -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2b copying /Users/hari/gridder/.git/objects/2b/d3c5463801cbf87d281d5bee99f5ea1c26210c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2b creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2c copying /Users/hari/gridder/.git/objects/2c/03468a79cd22e4d9f0c340d9b23466003fe1b2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2c copying /Users/hari/gridder/.git/objects/2c/47bb60de0a3cf49bb4adcb786d54c71e8567a3 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2c creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2d copying /Users/hari/gridder/.git/objects/2d/361a91c5caa1e8220ddd35bfc9373e22423f01 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2d creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2f copying /Users/hari/gridder/.git/objects/2f/2ba09c1f640291d54088c4e89a5db5aeb303b4 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2f copying /Users/hari/gridder/.git/objects/2f/78cf5b66514f2506d9af5f3dadf3dee7aa6d9f -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/2f creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/30 copying /Users/hari/gridder/.git/objects/30/4e7b19fe346735edb128ecc24d97b3a1fb110c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/30 copying /Users/hari/gridder/.git/objects/30/999546bd11045b549057d31a365ee2f50a9243 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/30 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/31 copying /Users/hari/gridder/.git/objects/31/5e315fe75c5f22cd21e55359bbcf2ca7ce3f5c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/31 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/33 copying /Users/hari/gridder/.git/objects/33/1c7fcefae6410dda12e023eac885f3f1905aef -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/33 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/34 copying /Users/hari/gridder/.git/objects/34/c5c3d785bae9bee55e7246e0a93af0ac8f1839 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/34 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/36 copying /Users/hari/gridder/.git/objects/36/7542daf1e7ff2a4e0d00bbfae22786051caecb -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/36 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/38 copying /Users/hari/gridder/.git/objects/38/29108008d851aab0fca24734251f712efee1db -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/38 copying /Users/hari/gridder/.git/objects/38/9a6e8a888bc4da465d68bb379d629e89625ddc -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/38 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/39 copying /Users/hari/gridder/.git/objects/39/f7cdb2cd18da976feddf9a0b0a1bacada18371 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/39 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/3a copying /Users/hari/gridder/.git/objects/3a/dab07085dacc7fba1c1f5371cd24850e61f76e -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/3a copying /Users/hari/gridder/.git/objects/3a/e30754ee9db1637fa0bc5f6751f0614a0e8aa3 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/3a creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/3b copying /Users/hari/gridder/.git/objects/3b/14dbad32bce58c9cafec0b1abce8b4afc478fa -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/3b creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/3d copying /Users/hari/gridder/.git/objects/3d/65a0c2bf5edc09ffa9d4ad6b918710071e1ca9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/3d creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/3e copying /Users/hari/gridder/.git/objects/3e/ef094fa27784359cddd93d99e5c75baa004b2b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/3e creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/40 copying /Users/hari/gridder/.git/objects/40/e2ce3e176917d501c616741f2ba4863a23b56b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/40 copying /Users/hari/gridder/.git/objects/40/fd98facdaa89ff264c0bc88eff152ec8a8c037 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/40 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/41 copying /Users/hari/gridder/.git/objects/41/489ebd365ae27629a5c470fe9de72fd39be30d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/41 copying /Users/hari/gridder/.git/objects/41/4c1c2ecfdbbd98d28d981e4be13aa8d6e9c770 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/41 copying /Users/hari/gridder/.git/objects/41/9f6cd84568d1dd4f84e2dfe124acff2650fef7 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/41 copying /Users/hari/gridder/.git/objects/41/ba2ffd67684e6cdbb2b5844a6fe113c22954d1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/41 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/45 copying /Users/hari/gridder/.git/objects/45/f5656dfcc52bd2bd27adfa89e47084978534ce -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/45 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/46 copying /Users/hari/gridder/.git/objects/46/4857e1d17dd6685e262cb0af5fa4f18fd8542c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/46 copying /Users/hari/gridder/.git/objects/46/82d05ead66b9457442a48750a8254a3b252fd0 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/46 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/48 copying /Users/hari/gridder/.git/objects/48/39ccf6b02983da22ec83351402b13655200dcb -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/48 copying /Users/hari/gridder/.git/objects/48/c6e9869bd0eff92dfe2df6b0b2877b0de9e482 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/48 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/49 copying /Users/hari/gridder/.git/objects/49/67d8af95ff313458acafce5f73a7463e31b03f -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/49 copying /Users/hari/gridder/.git/objects/49/81e803db1c12da66612eae2c01d6c6c3b0aa29 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/49 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/4c copying /Users/hari/gridder/.git/objects/4c/126294628d6e25307b167f55e6c98aef886961 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/4c copying /Users/hari/gridder/.git/objects/4c/ff3363cc0840e7005868afb77292f0a93f6b0f -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/4c creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/51 copying /Users/hari/gridder/.git/objects/51/8e18503ae3858eefc853eb0bee20d7eceb42de -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/51 copying /Users/hari/gridder/.git/objects/51/c3d6cf3b73fc272c5f2ead811b522477a942f2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/51 copying /Users/hari/gridder/.git/objects/51/ee31bf1e0ecd1ed98979fbd4833e344d96a9a7 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/51 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/53 copying /Users/hari/gridder/.git/objects/53/80b2fc6a8903bfae4e98db0a7ca95d7fdc9fe9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/53 copying /Users/hari/gridder/.git/objects/53/eb94eaf7995b7f3fa38050f17d36f6802e9f10 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/53 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/54 copying /Users/hari/gridder/.git/objects/54/9bbe32bc7ea402b97c76069a1e14b7f2d1ce3a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/54 copying /Users/hari/gridder/.git/objects/54/c25852f539a1feecba2b596ecbb416abbb4e37 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/54 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/56 copying /Users/hari/gridder/.git/objects/56/389f8ba1f8fdb049bd39ae043414942a3858a7 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/56 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/57 copying /Users/hari/gridder/.git/objects/57/0433d564ca539f345a656677451168c53eba91 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/57 copying /Users/hari/gridder/.git/objects/57/594a1d0d3cb184c75ca3c891e2ef6a31c44f0e -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/57 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/59 copying /Users/hari/gridder/.git/objects/59/09f6d92b58ca593b4a804746c10ed1e1a8dbdc -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/59 copying /Users/hari/gridder/.git/objects/59/5cc8d3ee7e157f233b75d88d084fd1274748a8 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/59 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/5b copying /Users/hari/gridder/.git/objects/5b/3368be86ef8a9b11dcbf9df14b00d52da3bca6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/5b creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/5e copying /Users/hari/gridder/.git/objects/5e/24f8e0b1512ab64b872d34c6b267e9b5098cd3 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/5e copying /Users/hari/gridder/.git/objects/5e/2cda48f825ab4175258a0c5e661e24e7059b68 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/5e copying /Users/hari/gridder/.git/objects/5e/3b0f868b76c5283aee5d3dfcc71c00afa4d627 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/5e copying /Users/hari/gridder/.git/objects/5e/b1e58f6e1f10fe9983cad0f8af7aa873e66e5e -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/5e creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/5f copying /Users/hari/gridder/.git/objects/5f/d836e4b492609a5608231b7a7b24e490e0e513 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/5f creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/60 copying /Users/hari/gridder/.git/objects/60/22e9a3ba2acbe6adcc00219b6e2fb58b7d95b7 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/60 copying /Users/hari/gridder/.git/objects/60/38c34f39c7ae576f3a86833c2861545ef64fb2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/60 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/61 copying /Users/hari/gridder/.git/objects/61/0141a700aab22b008dd53436741dcbdf78131a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/61 copying /Users/hari/gridder/.git/objects/61/6a4165fed5811359f1f42fd6e07ae4dc2565e2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/61 copying /Users/hari/gridder/.git/objects/61/e44d0e30893a39763e5d27c5e064e27bc66ecf -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/61 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/62 copying /Users/hari/gridder/.git/objects/62/ba5801211099e9adca463312b28bc2cd3e13d1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/62 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/63 copying /Users/hari/gridder/.git/objects/63/450d3808bfd66298f935bbecd61101e42a4c65 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/63 copying /Users/hari/gridder/.git/objects/63/abed741a25f1e0684a2c8da0a5f24855c52366 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/63 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/64 copying /Users/hari/gridder/.git/objects/64/38032b5f4dfffe97a2013cc592466bd5ee9f9b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/64 copying /Users/hari/gridder/.git/objects/64/9e122769e95b841492a4e4e98f95c572cb8004 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/64 copying /Users/hari/gridder/.git/objects/64/cd64240027bd3392b6b6196323fcf9e8cfba70 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/64 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/65 copying /Users/hari/gridder/.git/objects/65/87fd2c938ba1526f30cbdcc0eace16788f3555 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/65 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/66 copying /Users/hari/gridder/.git/objects/66/20df4e7bd848179253bbe37c715babd0d894b4 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/66 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/68 copying /Users/hari/gridder/.git/objects/68/6ce2bf4243f5a61255168e9ff2e01a003f2b12 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/68 copying /Users/hari/gridder/.git/objects/68/aaa50011bbdb6f92b006ae11dc6610e10905a9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/68 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/69 copying /Users/hari/gridder/.git/objects/69/cb5ec6b4a8705aae0ee7da5bdeeee5e21213f3 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/69 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6a copying /Users/hari/gridder/.git/objects/6a/654870ac60c6b49f2281875cd54ffd7b2f0346 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6a copying /Users/hari/gridder/.git/objects/6a/926acdc46f1284617c4c687e3f881f9bb2be73 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6a creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6c copying /Users/hari/gridder/.git/objects/6c/af37b3a36081933b61e03435229e02fa6149a4 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6c creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6d copying /Users/hari/gridder/.git/objects/6d/77e608f95fc4e3076baf6440b946dfef16b4b6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6d creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6e copying /Users/hari/gridder/.git/objects/6e/e111562aa5ec2867afa3c4aa04506e19a8571d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6e creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6f copying /Users/hari/gridder/.git/objects/6f/38ea32164efce6f5501b95a781cc3c244a2adc -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/6f creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/70 copying /Users/hari/gridder/.git/objects/70/d7a82af33d9a0b081cadf621ba2b1dd3fb7c78 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/70 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/73 copying /Users/hari/gridder/.git/objects/73/1d416dd2206c239b96b7cd7c262cabae82056c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/73 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/75 copying /Users/hari/gridder/.git/objects/75/55280b0ceaaca5aeb6c57a8ebd9eb4b2e124ea -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/75 copying /Users/hari/gridder/.git/objects/75/6ee012c2ecbaf344ed61d19ff28e7e2efa76a9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/75 copying /Users/hari/gridder/.git/objects/75/73a0d859a97e2c314ac5086153275b1fc1fe81 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/75 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/79 copying /Users/hari/gridder/.git/objects/79/41295c3c7bac93f93c1b7205e202fe412eb952 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/79 copying /Users/hari/gridder/.git/objects/79/f43915ceffa13678aacb7856805fb4fa19996b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/79 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7a copying /Users/hari/gridder/.git/objects/7a/b387d1010ef0fe18776cf32defc09537ea597d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7a creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7b copying /Users/hari/gridder/.git/objects/7b/6c649c769803169dd3982dc1ad2316534d8d50 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7b creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7c copying /Users/hari/gridder/.git/objects/7c/cd51b10b1686a9fdc9e920ec96ae1343550738 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7c creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7d copying /Users/hari/gridder/.git/objects/7d/2d4c5b5a62c74ad153317139f54583d6be2952 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7d creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7f copying /Users/hari/gridder/.git/objects/7f/69850931330e46ebdfafae1c006bc2db7ab5f2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/7f creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/80 copying /Users/hari/gridder/.git/objects/80/598780a931fa16f0e9e21fff30fb741e5f1ee6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/80 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/81 copying /Users/hari/gridder/.git/objects/81/1fbc850c499c8078ba1b2c3ada340db63892d8 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/81 copying /Users/hari/gridder/.git/objects/81/89dc558f6814cc3de3646ab6ace09ee924612a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/81 copying /Users/hari/gridder/.git/objects/81/e836f40c32895e62e06298d25c0ff9b008b414 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/81 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/82 copying /Users/hari/gridder/.git/objects/82/578c8bc4184ccf12ec520557c13b729b19844d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/82 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/85 copying /Users/hari/gridder/.git/objects/85/59f39d62a1cc9fe5a5648a8d06428dfd9ace8e -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/85 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/86 copying /Users/hari/gridder/.git/objects/86/ace4709e97be0979140654b54ef6bfcd8970a8 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/86 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/88 copying /Users/hari/gridder/.git/objects/88/c4c8798410c82445e5ce80a67f6b15cdd6acf5 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/88 copying /Users/hari/gridder/.git/objects/88/e6479407d451ff0571805877fe127c0a0fc75d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/88 copying /Users/hari/gridder/.git/objects/88/fc41ff0084fe7ada81caecd25d3e474df93d53 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/88 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/89 copying /Users/hari/gridder/.git/objects/89/4632fdae670c7856218c9f43e7b6059a329ee2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/89 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/8a copying /Users/hari/gridder/.git/objects/8a/87bfb26553fd878c9041dc1186f61b725179dd -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/8a creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/8b copying /Users/hari/gridder/.git/objects/8b/8333407684741543634e4b761a75a9153859ee -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/8b creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/8d copying /Users/hari/gridder/.git/objects/8d/3ea38a9bacc06bd9a47877469f5229feba2f74 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/8d copying /Users/hari/gridder/.git/objects/8d/c34c9f90fb3b92699e847b1cb5ba3fe1230936 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/8d creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/8e copying /Users/hari/gridder/.git/objects/8e/08745c3c16132bf8a377cb3f114cbc2220731d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/8e creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/90 copying /Users/hari/gridder/.git/objects/90/82c75abf32cd735f95055981fdc080ec6bd2ac -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/90 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/93 copying /Users/hari/gridder/.git/objects/93/45e17d9d3bbfaf0ca052757a2822b587b385e1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/93 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/94 copying /Users/hari/gridder/.git/objects/94/43d11dd0fe2fd9ef83ea24899676134bd57822 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/94 copying /Users/hari/gridder/.git/objects/94/5cefcf7b49d3877f32903d3549cd1a65ba5040 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/94 copying /Users/hari/gridder/.git/objects/94/b19b56056822fed5e00cd216e4e54b25787287 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/94 copying /Users/hari/gridder/.git/objects/94/d5c0d769d5a4a276140640d1c9ee0c5c87cfb2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/94 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/95 copying /Users/hari/gridder/.git/objects/95/f2d04e55da2d5f1b79eb949cd43657299acbbb -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/95 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/97 copying /Users/hari/gridder/.git/objects/97/3b91c1b64fc0267604f6a5b37c8b1f42c744ff -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/97 copying /Users/hari/gridder/.git/objects/97/495251be01f59f1e4fc88777ad4c983b795ca1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/97 copying /Users/hari/gridder/.git/objects/97/9acd83f22c8576636f948017301e9f510adb07 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/97 copying /Users/hari/gridder/.git/objects/97/b0d6d63dc749b0d62095c4d2daff267c008fbf -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/97 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/98 copying /Users/hari/gridder/.git/objects/98/dac07646b905af2441002f3c90448e67915480 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/98 copying /Users/hari/gridder/.git/objects/98/dd6655f27d74ce0d22df93d63ea5a55edf010d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/98 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/99 copying /Users/hari/gridder/.git/objects/99/d0d291e5654aecd6081b57e6d2d7cc7400b538 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/99 copying /Users/hari/gridder/.git/objects/99/de063d196a900797cc3e696f7a4c9d1bbed972 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/99 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/9a copying /Users/hari/gridder/.git/objects/9a/3e9fa8c615e83078c6aa426af487678661251b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/9a creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/9b copying /Users/hari/gridder/.git/objects/9b/6105ec7951fa8c1cca0a265e81e421ea53ca67 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/9b creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a1 copying /Users/hari/gridder/.git/objects/a1/5a9d398575cab38b994f4eea26be101d1f2856 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a1 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a4 copying /Users/hari/gridder/.git/objects/a4/3340dad571433b20ce889b73fd035d004f4c9d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a4 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a5 copying /Users/hari/gridder/.git/objects/a5/ca51d9a0a8ebc2d9b5c90d1fded992cefbeeaf -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a5 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a7 copying /Users/hari/gridder/.git/objects/a7/6af9764e4d7e790fc8eb087509c14ea184ba17 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a7 copying /Users/hari/gridder/.git/objects/a7/af4006ecb7f4332ef6257d50f8010c67973c69 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a7 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a8 copying /Users/hari/gridder/.git/objects/a8/a4cbd3e31b674fe8d6654d570c466f7e7c5d6b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a8 copying /Users/hari/gridder/.git/objects/a8/dd3b16f2e9c22205f30c421c320e21d021f2b7 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a8 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a9 copying /Users/hari/gridder/.git/objects/a9/6e9ef7d075280b6edf0e40166b5f9505b5ed70 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/a9 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ab copying /Users/hari/gridder/.git/objects/ab/e11d05796019940cf5ed634251077fbeee0dd5 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ab creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ae copying /Users/hari/gridder/.git/objects/ae/b8c808493e981140deca1cc87883fd4b4d82e6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ae creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b0 copying /Users/hari/gridder/.git/objects/b0/775379eabe7b90e688197d8083cb23a7514aaa -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b0 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b1 copying /Users/hari/gridder/.git/objects/b1/c061210e1b9bbf0b07573ad8c0e63ebd3f488d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b1 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b2 copying /Users/hari/gridder/.git/objects/b2/1e2d337d13d9e2d55738b39aea9bb08524c947 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b2 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b3 copying /Users/hari/gridder/.git/objects/b3/5a723ab4bbc4689efd7f02f1e850c35b6e5f2b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b3 copying /Users/hari/gridder/.git/objects/b3/b274e442b4f5a3a902f069410be27132b39442 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b3 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b8 copying /Users/hari/gridder/.git/objects/b8/4b49f7ad8c3fdc87f556984fcc62c5ef670a2a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b8 copying /Users/hari/gridder/.git/objects/b8/678d6573025b6b7502243aa76e4bc6336fd15f -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b8 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b9 copying /Users/hari/gridder/.git/objects/b9/30fbb4bb41dfb6a40206a3b8a58aae8af35b97 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b9 copying /Users/hari/gridder/.git/objects/b9/80ce2c9ef927c27aad677c4781dc474c6fd901 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/b9 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ba copying /Users/hari/gridder/.git/objects/ba/ab26e6f734663edbd847f8143ab24914afcb0d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ba copying /Users/hari/gridder/.git/objects/ba/d2b2a77f741d464d0d270b7556e42d316d217b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ba creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/bb copying /Users/hari/gridder/.git/objects/bb/15d66f51d336d4d87783ed9cd61828d1d6324b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/bb copying /Users/hari/gridder/.git/objects/bb/efe60e770eb6e9ca25d2885bbf41b1bb763c15 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/bb creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c0 copying /Users/hari/gridder/.git/objects/c0/9a472a0a834f7cb84b5550a9b202e1ea0ac378 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c0 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c1 copying /Users/hari/gridder/.git/objects/c1/30c291cc511cae322093b690734d670e1286e9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c1 copying /Users/hari/gridder/.git/objects/c1/ff665ed21b86ed0749a6f2832b370aff0bcfde -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c1 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c2 copying /Users/hari/gridder/.git/objects/c2/4e0925b005dd5728e8f23d9864bafe262565f6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c2 copying /Users/hari/gridder/.git/objects/c2/d9f862fac3bf08dc80413866bbc35eeb981265 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c2 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c3 copying /Users/hari/gridder/.git/objects/c3/9c1a9469ec2f99ca5284c0b0f4f2dc743e91cf -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c3 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c4 copying /Users/hari/gridder/.git/objects/c4/032338daf56b05739e8c1ea49174663c936020 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c4 copying /Users/hari/gridder/.git/objects/c4/40004c412e513dc8005a06a977a7c1da07e579 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c4 copying /Users/hari/gridder/.git/objects/c4/bf3d5bb19060b44c6ed5671b6ad330ccc81410 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c4 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c5 copying /Users/hari/gridder/.git/objects/c5/a08551331536a3ddf46fb9db9a9e9278085b9b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c5 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c7 copying /Users/hari/gridder/.git/objects/c7/60787bfe1925455b3096ccef5210259864681f -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c7 copying /Users/hari/gridder/.git/objects/c7/d448fa5cb2548a06514db4c5e875c9dd4c2e81 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c7 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c9 copying /Users/hari/gridder/.git/objects/c9/25b56d228c691e49a411af83de4eb87242b63d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c9 copying /Users/hari/gridder/.git/objects/c9/e8b088964dea629a0454963b419242d6376dde -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/c9 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cc copying /Users/hari/gridder/.git/objects/cc/52cd28b58fdb77b41356d85355d1d7c8487052 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cc copying /Users/hari/gridder/.git/objects/cc/8e327f8310a90503025f736cc2b1653046c6c5 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cc creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cd copying /Users/hari/gridder/.git/objects/cd/1b07ac8320c9f8c3a0886ddea14f4a6cc003f3 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cd copying /Users/hari/gridder/.git/objects/cd/3b0ea5c83f0cab92188bb3d41e4cd8385da507 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cd copying /Users/hari/gridder/.git/objects/cd/8d99e2f48bac5d021913b55ccf872cbaf14d8a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cd creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ce copying /Users/hari/gridder/.git/objects/ce/de0e533dd1648e5f8b20e1cac6404f81efe202 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ce copying /Users/hari/gridder/.git/objects/ce/ecf254fbfb2a762a8fb1ea4385426e69173bfa -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ce creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cf copying /Users/hari/gridder/.git/objects/cf/32e5083555fb8a3436fb98f1855e37529d9f89 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cf copying /Users/hari/gridder/.git/objects/cf/544faddbcdf7fae16ad4de243e6435e4cc1987 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cf copying /Users/hari/gridder/.git/objects/cf/b6ac2600c12f9d209bba5e4128719443150412 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/cf creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d0 copying /Users/hari/gridder/.git/objects/d0/59094f3cde6692f1939a32b42addb0a70ed435 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d0 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d1 copying /Users/hari/gridder/.git/objects/d1/9d9edd46f0b12ad71a4bc8691cdaa87429da54 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d1 copying /Users/hari/gridder/.git/objects/d1/e498f15428284d0f2ac756b7862857bf8f0dd6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d1 copying /Users/hari/gridder/.git/objects/d1/ff18bef15ec7966c56121369847043762ec33b -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d1 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d2 copying /Users/hari/gridder/.git/objects/d2/3139bbd7a417affb08fc0e1d3d41e4257e0db7 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d2 copying /Users/hari/gridder/.git/objects/d2/d5f57e76ec04e853ab7b5d63a5fa3c804c57e2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d2 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d5 copying /Users/hari/gridder/.git/objects/d5/8a5939f7376664b8f15c1f342bb29fb29b65d9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d5 copying /Users/hari/gridder/.git/objects/d5/a45131e7e4a7c3262ed2f4575335cc9a1f91a6 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d5 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d6 copying /Users/hari/gridder/.git/objects/d6/6a3ff298f6ef3216947f9e661ca115e0cf80f4 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d6 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d8 copying /Users/hari/gridder/.git/objects/d8/c327622f243b01de31f9955da4449cf42b6de7 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d8 copying /Users/hari/gridder/.git/objects/d8/c7af309e2beaa33550bcd3bab6def62fbd3146 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d8 copying /Users/hari/gridder/.git/objects/d8/f1cf4a646251611db1cccbc675b25c86075747 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/d8 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/db copying /Users/hari/gridder/.git/objects/db/1c15874ec2e4f13b5c27a38f3b57117d3b8481 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/db copying /Users/hari/gridder/.git/objects/db/3882bc6ce15e64e07ad3b77cee6fcbed3cf75d -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/db creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/de copying /Users/hari/gridder/.git/objects/de/c06ecc27a2e21beb2d8d978e408e18bf76a866 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/de creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/df copying /Users/hari/gridder/.git/objects/df/1b60e81e76af6b73184795dadf9731df01aceb -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/df creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e1 copying /Users/hari/gridder/.git/objects/e1/952fab50d5d2c077161be8c005b69f88ea14a1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e1 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e2 copying /Users/hari/gridder/.git/objects/e2/890717877547489936d3a4d22ad10f147cfde0 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e2 copying /Users/hari/gridder/.git/objects/e2/f173bfaee416ce68408aa9b48303cdd5778b08 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e2 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e5 copying /Users/hari/gridder/.git/objects/e5/17649215122c05627fed0d17ff622bdf67d26c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e5 copying /Users/hari/gridder/.git/objects/e5/45595f2e29bc78572422c40c5ea6c303419373 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e5 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e6 copying /Users/hari/gridder/.git/objects/e6/648d974affddb2d9e47df01a6ba607fe9323e9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e6 copying /Users/hari/gridder/.git/objects/e6/9de29bb2d1d6434b8b29ae775ad8c2e48c5391 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e6 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e7 copying /Users/hari/gridder/.git/objects/e7/d310fe02fbb782a6a670109a7819c2acb9065e -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e7 copying /Users/hari/gridder/.git/objects/e7/ea0b135d162d1cdeab155df3b887883d62e7e4 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e7 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e8 copying /Users/hari/gridder/.git/objects/e8/648bf3722ef7c9cbb8c9c8023a795c5037b4b2 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e8 copying /Users/hari/gridder/.git/objects/e8/7498e4784317e15cad18d8fedfa061ba02b375 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e8 copying /Users/hari/gridder/.git/objects/e8/e5842e7501737f90bffbcb93c76b3bcd0dfb59 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/e8 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ea copying /Users/hari/gridder/.git/objects/ea/dd6d656b4b493e98d22e7bd07a9ff7bc7a0057 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ea copying /Users/hari/gridder/.git/objects/ea/f3d0065400056239228ce856cb676d143333f5 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ea creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/eb copying /Users/hari/gridder/.git/objects/eb/c0d36342315f1d0bc611af2c28cf0b8f026fd3 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/eb creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ee copying /Users/hari/gridder/.git/objects/ee/0b90588707dbf4be0c6df97dcf8b4234dfcfb7 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ee creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ef copying /Users/hari/gridder/.git/objects/ef/3d00130f239cfdb7b6f2c44d065a8c015eade1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ef copying /Users/hari/gridder/.git/objects/ef/82c6b8a4dd0537578ee24108fe23aa2f3cf374 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ef copying /Users/hari/gridder/.git/objects/ef/9b3dbcc3250d54db07994e6a5ae5d157eb9b70 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ef creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f2 copying /Users/hari/gridder/.git/objects/f2/19abd39555f8f1b5840e9e8b9bb18e86ad5af0 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f2 copying /Users/hari/gridder/.git/objects/f2/6d7114d1315669ca10798d9f278d741e10bf0f -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f2 copying /Users/hari/gridder/.git/objects/f2/d8509709b906adee7db08344b586c21d4530fe -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f2 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f3 copying /Users/hari/gridder/.git/objects/f3/41e583f1e910776b5642071e164d422c97c1ca -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f3 copying /Users/hari/gridder/.git/objects/f3/6cbf0e492cb381f5203a3d2c7bf0fe965dd354 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f3 copying /Users/hari/gridder/.git/objects/f3/b529e5a60be8f9588cf8fc86cca061fd16acb1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f3 copying /Users/hari/gridder/.git/objects/f3/f18a415cd3a07d120fedd825d30d981362f898 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f3 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f4 copying /Users/hari/gridder/.git/objects/f4/b29172fbe55da1d70604ac832c7ed49efb80f4 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f4 copying /Users/hari/gridder/.git/objects/f4/c67c45ffc32020f7163a43adca3d31a5e43cf1 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f4 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f5 copying /Users/hari/gridder/.git/objects/f5/108e98d5587710104b1c0bb06e110df32ce66a -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f5 copying /Users/hari/gridder/.git/objects/f5/f0cd83647d74b28b70561c66b0fb9493831a07 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f5 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f6 copying /Users/hari/gridder/.git/objects/f6/ec1013a647b36f9891841e84d5ee17a9a06f1e -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f6 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f7 copying /Users/hari/gridder/.git/objects/f7/2113585564010abf9dce1db7f23f27b805868c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f7 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f9 copying /Users/hari/gridder/.git/objects/f9/9ad1a3f8c0885f51b99351ce260489f054bd53 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/f9 creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/fa copying /Users/hari/gridder/.git/objects/fa/33816fd23bcd4f3da45a7cee319cd625e32777 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/fa creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/fb copying /Users/hari/gridder/.git/objects/fb/686a365fa7a88d1d2534ff3b09f5f0d0249c7c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/fb creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/fc copying /Users/hari/gridder/.git/objects/fc/1d4ad97f2c5f8e9964e77c50c17c2a0a00ebf0 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/fc copying /Users/hari/gridder/.git/objects/fc/e92d254808b707d8fd09d187caf6af38701bf9 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/fc creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/fe copying /Users/hari/gridder/.git/objects/fe/82a6b8b8f773d58f6bf06124b1b12777835ced -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/fe creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ff copying /Users/hari/gridder/.git/objects/ff/7180a4d0a111a5e642a31af635a38423fe779c -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ff copying /Users/hari/gridder/.git/objects/ff/e1df722af87eaff9fce3c34185ad607cef6d73 -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/ff creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/info creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/pack copying /Users/hari/gridder/.git/objects/pack/pack-3c08e0b085bf7235ff2f8248313d9d7cd1722c24.idx -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/pack copying /Users/hari/gridder/.git/objects/pack/pack-3c08e0b085bf7235ff2f8248313d9d7cd1722c24.pack -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/objects/pack copying /Users/hari/gridder/.git/ORIG_HEAD -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git copying /Users/hari/gridder/.git/packed-refs -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/refs creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/refs/heads copying /Users/hari/gridder/.git/refs/heads/master -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/refs/heads creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/refs/remotes creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/refs/remotes/origin copying /Users/hari/gridder/.git/refs/remotes/origin/HEAD -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/refs/remotes/origin copying /Users/hari/gridder/.git/refs/remotes/origin/master -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/refs/remotes/origin creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/.git/refs/tags creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/nbproject creating /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/nbproject/private copying /Users/hari/gridder/nbproject/private/private.xml -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/nbproject/private copying /Users/hari/gridder/nbproject/project.properties -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/nbproject copying /Users/hari/gridder/nbproject/project.xml -> /Users/hari/gzilla/src/build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/collect/gridder/nbproject *** creating application bundle: GridZilla *** copying GridZilla.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources creating /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib creating /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5 copying build/bdist.macosx-10.5-i386/python2.5-semi_standalone/app/site-packages.zip -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5 creating /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/lib-dynload creating /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Frameworks creating /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/__init__.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/__init__.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/composer.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/composer.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/constructor.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/constructor.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/cyaml.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/cyaml.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/dumper.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/dumper.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/emitter.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/emitter.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/error.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/error.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/events.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/events.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/loader.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/loader.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/nodes.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/nodes.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/parser.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/parser.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/reader.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/reader.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/representer.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/representer.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/resolver.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/resolver.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/scanner.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/scanner.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/serializer.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/serializer.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/tokens.py -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml copying /Library/Python/2.5/site-packages/yaml/tokens.pyc -> /Users/hari/gzilla/src/dist/GridZilla.app/Contents/Resources/lib/python2.5/yaml stripping GridZilla stripping sgmlop.so stripping _rl_accel.so stripping saved 33324 bytes (234360 / 267684)