From jean_lucregnier at yahoo.fr Thu Dec 13 10:24:39 2012 From: jean_lucregnier at yahoo.fr (=?iso-8859-9?Q?Jean-Luc_R=E9gnier?=) Date: Thu, 13 Dec 2012 11:24:39 +0200 Subject: [Pythonmac-SIG] KeyError: 'CFLAGS' Message-ID: Hello All, I am trying to compile a Python27 application for mac using a simple script: from setuptools import setup setup( app=["GF-soft.pyw"], setup_requires=["py2app"], ) and ended up with this: setup.py, line 68, in main BASE_CFLAGS = cfg['CFLAGS'] KeyError: 'CFLAGS' In "setup.py" located at "C:\Python27\Lib\site-packages\py2app-0.7.1-py2.7.egg\py2app\apptemplate" cfg = distutils.sysconfig.get_config_vars() return the following configuration variable dictionary: {'EXE': '.exe', 'exec_prefix': 'C:\\Python27', 'LIBDEST': 'C:\\Python27\\Lib', 'prefix': 'C:\\Python27', 'VERSION': '27', 'SO': '.pyd', 'BINLIBDEST': 'C:\\Python27\\Lib', 'INCLUDEPY': 'C:\\Python27\\include', 'BINDIR': 'C:\\Python27'} and the keyword "CFLAGS" indeed does not exist... Should I add something in my path directory ? (I am using windows XP) Best regards, Jean-Luc -------------- next part -------------- An HTML attachment was scrubbed... URL: From kw at codebykevin.com Thu Dec 13 14:30:01 2012 From: kw at codebykevin.com (Kevin Walzer) Date: Thu, 13 Dec 2012 08:30:01 -0500 Subject: [Pythonmac-SIG] KeyError: 'CFLAGS' In-Reply-To: References: Message-ID: <50C9D859.2050100@codebykevin.com> On 12/13/12 4:24 AM, Jean-Luc R?gnier wrote: > and the keyword "CFLAGS" indeed does not exist... > Should I add something in my path directory ? (I am using windows XP) > Best regards, I think the basic problem is that you can't build a Mac app on Windows...py2app is a Mac-specific tool. You should switch to the target platform and try building there. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com From ronaldoussoren at mac.com Thu Dec 13 15:06:33 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 13 Dec 2012 14:06:33 +0000 (GMT) Subject: [Pythonmac-SIG] KeyError: 'CFLAGS' In-Reply-To: <50C9D859.2050100@codebykevin.com> Message-ID: <6a6a147a-5cb5-4f76-bbc6-5a93bec9ee99@me.com> On Dec 13, 2012, at 02:36 PM, Kevin Walzer wrote: On 12/13/12 4:24 AM, Jean-Luc R?gnier wrote: > and the keyword "CFLAGS" indeed does not exist... > Should I add something in my path directory ? (I am using windows XP) > Best regards, I think the basic problem is that you can't build a Mac app on Windows...py2app is a Mac-specific tool. You should switch to the target platform and try building there. ? That's right, py2app is not supported on Windows. I've filed in my bitbucket repository to help remind me to tweak py2app's setup.py to give a nice error message when someone tries to install on Linux or Windows. Ronald --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG -------------- next part -------------- An HTML attachment was scrubbed... URL: From jean_lucregnier at yahoo.fr Thu Dec 13 17:37:50 2012 From: jean_lucregnier at yahoo.fr (=?utf-8?Q?Jean-Luc_R=C3=A9gnier?=) Date: Thu, 13 Dec 2012 18:37:50 +0200 Subject: [Pythonmac-SIG] KeyError: 'CFLAGS' References: <6a6a147a-5cb5-4f76-bbc6-5a93bec9ee99@me.com> Message-ID: Thanks for your answers, Regards, Jean-Luc ----- Original Message ----- From: Ronald Oussoren To: kw at codebykevin.com Cc: pythonmac-sig at python.org Sent: Thursday, December 13, 2012 4:06 PM Subject: Re: [Pythonmac-SIG] KeyError: 'CFLAGS' On Dec 13, 2012, at 02:36 PM, Kevin Walzer wrote: On 12/13/12 4:24 AM, Jean-Luc R?gnier wrote: > and the keyword "CFLAGS" indeed does not exist... > Should I add something in my path directory ? (I am using windows XP) > Best regards, I think the basic problem is that you can't build a Mac app on Windows...py2app is a Mac-specific tool. You should switch to the target platform and try building there. That's right, py2app is not supported on Windows. I've filed in my bitbucket repository to help remind me to tweak py2app's setup.py to give a nice error message when someone tries to install on Linux or Windows. Ronald --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG ------------------------------------------------------------------------------ _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG -------------- next part -------------- An HTML attachment was scrubbed... URL: From rowen at uw.edu Fri Dec 14 20:37:32 2012 From: rowen at uw.edu (Russell E. Owen) Date: Fri, 14 Dec 2012 11:37:32 -0800 Subject: [Pythonmac-SIG] bdist_mpkg question: python 3 support? Message-ID: Does anyone know of a version of bdist_mpkg that works with Python 3? If not, how might one create a Mac binary installer for Python 3? -- Russell From ronaldoussoren at mac.com Mon Dec 17 09:33:27 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 17 Dec 2012 09:33:27 +0100 Subject: [Pythonmac-SIG] bdist_mpkg question: python 3 support? In-Reply-To: References: Message-ID: <0D8E0254-99B2-4D2A-B1C9-7985EF4DD9C2@mac.com> On 14 Dec, 2012, at 20:37, Russell E. Owen wrote: > Does anyone know of a version of bdist_mpkg that works with Python 3? I don't know of a py3k port of bdist_mpkg. > > If not, how might one create a Mac binary installer for Python 3? You could port bdist_mpkg yourself, doing that should be too hard. That said, bdist_mpkg creates an old package format that doesn't support some of the more recent features of Installer.app (such as signed packages). Another alternative is to use the packaging tools provided with Xcode, you will have to do more manually but will end up with a "modern" package format. What are you trying to accomplish? Depending on your usecase you might be able to get away with providing binary eggs and those don't require additional tools. Ronald > > -- Russell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From ronaldoussoren at mac.com Mon Dec 17 19:16:57 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 17 Dec 2012 19:16:57 +0100 Subject: [Pythonmac-SIG] bdist_mpkg question: python 3 support? In-Reply-To: <9166133654420786449@unknownmsgid> References: <0D8E0254-99B2-4D2A-B1C9-7985EF4DD9C2@mac.com> <2490585405998923464@unknownmsgid> <9166133654420786449@unknownmsgid> Message-ID: <8D83B8AA-C094-48E7-8A8C-A87FA90C797D@mac.com> On 17 Dec, 2012, at 19:03, Chris Barker - NOAA Federal wrote: > Oops hit send by accident . > > > On Dec 17, 2012, at 9:57 AM, Chris Barker - NOAA Federal > wrote: > >> On Dec 17, 2012, at 1:34 AM, Ronald Oussoren wrote: >> >>>> >>> >>> You could port bdist_mpkg yourself, doing that should be too hard. That said, bdist_mpkg creates an old package format that doesn't support some of the more recent features of Installer.app (such as signed packages). >>> >>> Another alternative is to use the packaging tools provided with Xcode, you will have to do more manually but will end up with a "modern" package format. >> >> Do you think it would be hard to update bdist_mpkg to support the new >> format? It is nice to have a simple, pure python, way to build a. > > Binary installer. I don't know, I haven't looked into that yet (but will likely do so for the python.org installers). I don't even know if the new format is properly documented, with some luck its a closed binary format that can only be created using Apple's tools. I don't care too much about having something like bdist_mpkg because it has only limited usefulness: installer.app has limited features (no uninstall, very limited upgrade features), and it is hard to support virtualenv using installer.app packages. > >> >>> binary eggs and those don't require additional tools. > > Binary eggs do require setup tools or distribute, though that's not > too heavy a lift. IIRC bdist_mpkg also uses setuptools, so that's not really a disadvantage here. The real problem with binary eggs is that pip doesn't install them, and pip seems to be the new hotness w.r.t. package management at the moment. There is some discussion about a new format (see , but I'm not sure why that would be better than eggs (other than that it isn't a setuptools egg). The packaging landscape for Python still sucks and that might not change anytime soon. > > But setup tools used to get all confused by Universal binaries--has > that been fixed? If not, it still may be easier to fix that than do a > bdist_mpkg update. Setuptools works just fine with universal binaries, and always has. It does treat 'universal' like any other architecture though, which means it doesn't understand that a binary egg with x86_64 only will work just fine when you are on a x86_64 machine with a python framework that supports i386 and x86_64. Whether or not that is a problem depends on your usecase. Ronald > > Chris > > > >>> Ronald >>> >>>> >>>> -- Russell >>>> >>>> _______________________________________________ >>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From chris.barker at noaa.gov Mon Dec 17 19:03:25 2012 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Mon, 17 Dec 2012 10:03:25 -0800 Subject: [Pythonmac-SIG] bdist_mpkg question: python 3 support? In-Reply-To: <2490585405998923464@unknownmsgid> References: <0D8E0254-99B2-4D2A-B1C9-7985EF4DD9C2@mac.com> <2490585405998923464@unknownmsgid> Message-ID: <9166133654420786449@unknownmsgid> Oops hit send by accident . On Dec 17, 2012, at 9:57 AM, Chris Barker - NOAA Federal wrote: > On Dec 17, 2012, at 1:34 AM, Ronald Oussoren wrote: > >>> >> >> You could port bdist_mpkg yourself, doing that should be too hard. That said, bdist_mpkg creates an old package format that doesn't support some of the more recent features of Installer.app (such as signed packages). >> >> Another alternative is to use the packaging tools provided with Xcode, you will have to do more manually but will end up with a "modern" package format. > > Do you think it would be hard to update bdist_mpkg to support the new > format? It is nice to have a simple, pure python, way to build a. Binary installer. > >> binary eggs and those don't require additional tools. Binary eggs do require setup tools or distribute, though that's not too heavy a lift. But setup tools used to get all confused by Universal binaries--has that been fixed? If not, it still may be easier to fix that than do a bdist_mpkg update. Chris >> Ronald >> >>> >>> -- Russell >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From chris.barker at noaa.gov Mon Dec 17 21:03:53 2012 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Mon, 17 Dec 2012 12:03:53 -0800 Subject: [Pythonmac-SIG] bdist_mpkg question: python 3 support? In-Reply-To: <8D83B8AA-C094-48E7-8A8C-A87FA90C797D@mac.com> References: <0D8E0254-99B2-4D2A-B1C9-7985EF4DD9C2@mac.com> <2490585405998923464@unknownmsgid> <9166133654420786449@unknownmsgid> <8D83B8AA-C094-48E7-8A8C-A87FA90C797D@mac.com> Message-ID: >>> Do you think it would be hard to update bdist_mpkg to support the new >>> format? It is nice to have a simple, pure python, way to build a. > I don't know, I haven't looked into that yet (but will likely do so for the python.org installers). I don't even know if the new format is properly documented, with some luck its a closed binary format that can only be created using Apple's tools. can those tools be called from a command-line, though? Requiring the dev tools to be installed to build a binary is not a big limitation. > I don't care too much about having something like bdist_mpkg because it has only limited usefulness: installer.app has limited features (no uninstall, very limited upgrade features), and it is hard to support virtualenv using installer.app packages. True -- but it was nice to have something folks were familiar with and could just point and click on. Ages agio we had a discussion about having a tool that could be distributed with MacPython that could be associated with *.egg files and install eggs properly -- so newbies could just point and click on an agg. That would be nice, but in the end of the day, you're going to need to learn a bit about installing packages if you're really going to use Python anyway. >> Binary eggs do require setup tools or distribute, though that's not >> too heavy a lift. > > IIRC bdist_mpkg also uses setuptools, so that's not really a disadvantage here. I meant you need setuptool sor distribute to install binary eggs -- requirements for building installers are a non-issue. > The real problem with binary eggs is that pip doesn't install them, and pip seems to be the > new hotness w.r.t. package management at the moment. Indeed it does -- I hadn't realized it didn't install binary eggs -- I guess it's been a while since I've tried that! > There is some discussion about a new format (see , but I'm not sure why that would be better than eggs (other than that it isn't a setuptools egg). It looks like it has some advantages -- but it's not there now, and who knows if it ever will be... > The packaging landscape for Python still sucks and that might not change anytime soon. :-( >> But setup tools used to get all confused by Universal binaries--has >> that been fixed? If not, it still may be easier to fix that than do a >> bdist_mpkg update. > > Setuptools works just fine with universal binaries, and always has. it build binaries fine, but easy_install got confused when you tried to install them. > It does treat 'universal' like any other architecture though, which means it doesn't understand > that a binary egg with x86_64 only will work just fine when you are on a x86_64 machine > with a python framework that supports i386 and x86_64. Whether or not that is a problem > depends on your usecase. It would be nice to suport that use-case, though it's ripe for confusion for casual users. But at least a couple years ago, if you build a binary egg with setuptools with a universal Python, you'd get an egg that setuptools would get confused trying to install -- I can't remember the details, but often when a user tried to install it, easy+install would end up downloading the source and trying to build it. IIRC, often it had, in fact, successfully installed the binary, so you could kill the process and have it work -- but that wasn't the least bit clear to the user. I also have a vague recollection that you could fix that problem simply be re-naming teh binary but my memory is hazy there. It seems binary egg installation should be pretty easy, and it doesn't look like the pip folks are opposed to the idea, so maybe we could add that to pip, if distribute builds them properly 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 nad at acm.org Mon Dec 17 23:29:07 2012 From: nad at acm.org (Ned Deily) Date: Mon, 17 Dec 2012 14:29:07 -0800 Subject: [Pythonmac-SIG] bdist_mpkg question: python 3 support? References: <0D8E0254-99B2-4D2A-B1C9-7985EF4DD9C2@mac.com> <2490585405998923464@unknownmsgid> <9166133654420786449@unknownmsgid> <8D83B8AA-C094-48E7-8A8C-A87FA90C797D@mac.com> Message-ID: In article , Chris Barker - NOAA Federal wrote: > > The real problem with binary eggs is that pip doesn't install them, and pip > > seems to be the > > new hotness w.r.t. package management at the moment. > > Indeed it does -- I hadn't realized it didn't install binary eggs -- I > guess it's been a while since I've tried that! > > > There is some discussion about a new format (see > > , but I'm not sure why that would > > be better than eggs (other than that it isn't a setuptools egg). > > It looks like it has some advantages -- but it's not there now, and > who knows if it ever will be... > > > The packaging landscape for Python still sucks and that might not change > > anytime soon. > > :-( > > >> But setup tools used to get all confused by Universal binaries--has > >> that been fixed? If not, it still may be easier to fix that than do a > >> bdist_mpkg update. > > > > Setuptools works just fine with universal binaries, and always has. > > it build binaries fine, but easy_install got confused when you tried > to install them. > > > It does treat 'universal' like any other architecture though, which means > > it doesn't understand > > that a binary egg with x86_64 only will work just fine when you are on a > > x86_64 machine > > with a python framework that supports i386 and x86_64. Whether or not that > > is a problem > > depends on your usecase. > > It would be nice to suport that use-case, though it's ripe for > confusion for casual users. > > But at least a couple years ago, if you build a binary egg with > setuptools with a universal Python, you'd get an egg that setuptools > would get confused trying to install -- I can't remember the details, > but often when a user tried to install it, easy+install would end up > downloading the source and trying to build it. IIRC, often it had, in > fact, successfully installed the binary, so you could kill the process > and have it work -- but that wasn't the least bit clear to the user. > > I also have a vague recollection that you could fix that problem > simply be re-naming teh binary but my memory is hazy there. Yes, that's what Ronald is talking about with regard to architectures. The platform architecture is encoded into the file name of the egg. For OS X universal builds, the platform names are things like "fat" (meaning the build includes "i386" and "ppc") or "intel" ("i386" 32-bit and "x86_65" 64-bit). IIRC, the problem is that setuptools/Distribute just does a simple equality compare of that platform name from the egg to that of the running Python at install time when what is needed is a set comparison, i.e. something like: is there a non-null intersection between the set of archs supported by the binaries in the egg with the set of archs supported by the Python interpreter being used for installation. (Today you can force a true comparison by changing the name of the binary egg file so that the platform strings match.) > It seems binary egg installation should be pretty easy, and it doesn't > look like the pip folks are opposed to the idea, so maybe we could add > that to pip, if distribute builds them properly anyway. It's not trivially easy or it probably would have been done before. IIRC, Setuptools/Distribute has to do some behind the scenes platform-specific tricks to ensure that dynamic loads of the extension modules work, certainly for zipped binary eggs. To a large extent, it's the tricks that setuptools uses (this and the manipulation of sys.path) to support various use cases that has given setuptools/Distribute a bad rep. pip makes some important simplifying assumptions; not supporting binary eggs is one of them. -- Ned Deily, nad at acm.org From ronaldoussoren at mac.com Tue Dec 18 09:09:58 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 18 Dec 2012 09:09:58 +0100 Subject: [Pythonmac-SIG] bdist_mpkg question: python 3 support? In-Reply-To: References: <0D8E0254-99B2-4D2A-B1C9-7985EF4DD9C2@mac.com> <2490585405998923464@unknownmsgid> <9166133654420786449@unknownmsgid> <8D83B8AA-C094-48E7-8A8C-A87FA90C797D@mac.com>

Message-ID: <11AA3E24-315A-46E1-8BD4-6265D80CF1A6@mac.com> On 17 Dec, 2012, at 23:29, Ned Deily wrote: > In article > , > Chris Barker - NOAA Federal wrote: >>> > >> It seems binary egg installation should be pretty easy, and it doesn't >> look like the pip folks are opposed to the idea, so maybe we could add >> that to pip, if distribute builds them properly anyway. > > It's not trivially easy or it probably would have been done before. > IIRC, Setuptools/Distribute has to do some behind the scenes > platform-specific tricks to ensure that dynamic loads of the extension > modules work, certainly for zipped binary eggs. AFAIK It doesn't use platform-specific tricks, but always the same one: a binary egg with an extension contains both the C shared library for the extension ("sqlite.so") and a python loader with the same name ("sqlite.py"). The loader will extract the extension from the binary egg into a temporary directory (using the pkg_resources API) and then uses the imp module to actually load the extension. Py2exe contains a DLL loader that can load extensions directly from a zipfile, but as far as I know setuptools doesn't do that. > To a large extent, it's > the tricks that setuptools uses (this and the manipulation of sys.path) > to support various use cases that has given setuptools/Distribute a bad > rep. pip makes some important simplifying assumptions; not supporting > binary eggs is one of them. Supporting binary eggs for installation should be fairly easy, as you basicly just have to unzip them and move the the EGG-INFO to the right location. You'd end up with a directory that contains both .so files for extensions and .py files for the loader that's needed to load the extension from an egg file but that additional python file is harmless due to the search order of __import__: when a directory contains both an extension and a python file for the same module __import__ uses the extension. Ronald > > -- > Ned Deily, > nad at acm.org > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From chris.barker at noaa.gov Thu Dec 20 21:15:33 2012 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Thu, 20 Dec 2012 12:15:33 -0800 Subject: [Pythonmac-SIG] 32+64 bit Intel PIL binary? Message-ID: Hi folks, Has anyone built a 32+64 bit Intel binary for PIl? (to match the Python 2.7 Intel build on python.org). Russell Owen has a PIL-1.1.7-py2.7-python.org-macosx10.6.dmg (http://www.astro.washington.edu/users/rowen/python/) But it appears to only work right in 64 bit mode. I suspect the dependencies are not all universal -- though I haven't dug into it. This does remind me that it would be nice to have a home for binary mac python packages somewhere (like Bob Ippolito's old repository) Anyone have a good idea where to host such a thing? -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 Dec 21 01:08:24 2012 From: chris.barker at noaa.gov (Chris Barker - NOAA Federal) Date: Thu, 20 Dec 2012 16:08:24 -0800 Subject: [Pythonmac-SIG] 32+64 bit Intel PIL binary? In-Reply-To: References: Message-ID: added note: I found a universal jpeg binary here: http://ethan.tira-thompson.com/Mac_OS_X_Ports.html after installing that: pip install pillow seemed to work -- it's still missing CMS support, though -- which i can live with. It's still be nice to provide full-featured binaries for folks. -Chris On Thu, Dec 20, 2012 at 12:15 PM, Chris Barker - NOAA Federal wrote: > Hi folks, > > Has anyone built a 32+64 bit Intel binary for PIl? (to match the > Python 2.7 Intel build on python.org). > > Russell Owen has a PIL-1.1.7-py2.7-python.org-macosx10.6.dmg > > (http://www.astro.washington.edu/users/rowen/python/) > > But it appears to only work right in 64 bit mode. I suspect the > dependencies are not all universal -- though I haven't dug into it. > > This does remind me that it would be nice to have a home for binary > mac python packages somewhere (like Bob Ippolito's old repository) > Anyone have a good idea where to host such a thing? > > -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 -- 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 Mon Dec 24 09:53:37 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 24 Dec 2012 09:53:37 +0100 Subject: [Pythonmac-SIG] py2app error when launching built app In-Reply-To: References: Message-ID: <8ACE35B2-C58B-4B08-8BFD-D053B725BD26@mac.com> On 11 Nov, 2012, at 23:26, Alex Honeywell wrote: > I've got my app successfully bundled and built, but when I try to launch it from Finder I get "snakewatch: Error" and nothing else except "exited with error: 255" in Console. > > When I run the binary from Terminal instead, I get > > Traceback (most recent call last): > File "/Volumes/Data/Development/snakewatch/dist/snakewatch.app/Contents/Resources/__boot__.py", line 7, in > _reset_sys_path() > File "/Volumes/Data/Development/snakewatch/dist/snakewatch.app/Contents/Resources/__boot__.py", line 4, in _reset_sys_path > resources = os.environ['RESOURCEPATH'] > File "UserDict.pyc", line 23, in __getitem__ > KeyError: 'RESOURCEPATH' > 2012-11-11 17:18:07.567 snakewatch[92013:707] snakewatch Error > > If I run "RESOURCEPATH=$(pwd)/Resources MacOS/snakewatch" I get > > Traceback (most recent call last): > File "/Volumes/Data/Development/snakewatch/dist/snakewatch.app/Contents/Resources/__boot__.py", line 316, in > _run() > File "/Volumes/Data/Development/snakewatch/dist/snakewatch.app/Contents/Resources/__boot__.py", line 304, in _run > argv0 = os.path.basename(os.environ['ARGVZERO']) > File "UserDict.pyc", line 23, in __getitem__ > KeyError: 'ARGVZERO' > > and if I run "RESOURCEPATH=$(pwd)/Resources ARGVZERO='' MacOS/snakewatch" it launches fine. This appears to be the same problem as . Do you use a framework build of python or a basic shared library build ("--enable-shared")? Ronald From bergs at janelia.hhmi.org Wed Dec 26 05:33:03 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 26 Dec 2012 04:33:03 +0000 Subject: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7 Message-ID: Greetings, I'm new to PyObjC, but it looks great. I can run basic examples, but the ScreenSaver example in the docs doesn't seem to work on 10.7: http://packages.python.org/pyobjc/examples/ScreenSaver/SillyBallsSaver/index.html Someone on stack overflow seems to be having the same trouble as me: http://stackoverflow.com/questions/7821589/compile-64-bit-mac-app-with-py2app But I don't think that 32-bit vs. 64-bit is the issue. (I'm able to run non-screensaver examples?) Does anyone know if the ScreenSaver framework pyobjc wrappers are still supported for OS 10.7? By the way, I'm using Xcode 4.5.2. I know that Xcode 4 threw a wrench in some aspects of pyobjc. Is this an example of that? Thanks, Stuart From ronaldoussoren at mac.com Wed Dec 26 09:55:31 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 26 Dec 2012 09:55:31 +0100 Subject: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7 In-Reply-To: References: Message-ID: On 26 Dec, 2012, at 5:33, "Berg, Stuart" wrote: > Greetings, > > I'm new to PyObjC, but it looks great. I can run basic examples, but the ScreenSaver example in the docs doesn't seem to work on 10.7: > http://packages.python.org/pyobjc/examples/ScreenSaver/SillyBallsSaver/index.html > > Someone on stack overflow seems to be having the same trouble as me: > http://stackoverflow.com/questions/7821589/compile-64-bit-mac-app-with-py2app > > But I don't think that 32-bit vs. 64-bit is the issue. (I'm able to run non-screensaver examples?) > > Does anyone know if the ScreenSaver framework pyobjc wrappers are still supported for OS 10.7? The screensaver framework should work just fine, but only if the bundle contains 64-bit code. What is the output of 'file SillyBalls.saver/Contents/MacOS/SillyBalls' ? On my (OSX 10.8) machine this says: $ file dist/SillyBalls.saver/Contents/MacOS/SillyBalls dist/SillyBalls.saver/Contents/MacOS/SillyBalls: Mach-O universal binary with 2 architectures dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture i386): Mach-O bundle i386 dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture x86_64): Mach-O 64-bit bundle x86_64 This binary also works when I load it in System Preferences (at least, the preview does, I haven't waited long enough yet to check if it also works when the screensaver kicks in). > > By the way, I'm using Xcode 4.5.2. I know that Xcode 4 threw a wrench in some aspects of pyobjc. Is this an example of that? I don't think so. This is most likely a 32-bit vs. 64-bit issue. I'm using a custom 32-bit/64-bit build of Python 2.7 (from the python.org repository), pyobjc from the pyobjc repository and the most recent release of py2app, all of this running on OSX 10.8. Which versions of python, pyobjc, and py2app do you use (and for the python versions, is this the apple provided one or some other install)? Ronald > > Thanks, > Stuart > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG From ronaldoussoren at mac.com Wed Dec 26 14:32:15 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 26 Dec 2012 14:32:15 +0100 Subject: [Pythonmac-SIG] pyobjc status and future Message-ID: <2DB10E1E-D2BD-4057-BC7B-7D8A2FA7D80E@mac.com> Hi, Early november I finally got a new release of PyObjC out (version 2.4), and unless an unexpected problem crops up there will be another release (2.5) next Sunday. Version 2.5 will re-add some functionality that accidently got dropped in the 2.4 release (in particular the support for BridgeSupport files), and improves testing (which led to a number of bugfixes). I've also migrated the website to http://packages.python.org/pyobjc, the old URL (http://pyobjc.sf.net/) is now just a redirect to the new location. The website is once again generated from the PyObjC source tree, the old one hadn't been updated in a long while because the scripts generating that site didn't work anymore due to restructuring of the pyobjc repository and documentation files. I'd like to replace the current sphinx theme by something less generic, and that should happen sometime next year. The same is true for the examples: that code needs to be cleaned up and updated. I'll try to get on a more regular release pattern next year, with some luck leading up to a 3.0 release during the summer. That release would then feature a cleaned up core bridge, removing some cruft that was needed to support Python release before 2.6 and that cleanup should improve the performance of all of PyObjC. The major stumbling block w.r.t. getting to 3.0 is time: I know what I want to do and how to get there, but expect to need a couple of days to work on this; my regular development pattern of doing a couple of hours development during the evening or in the weekend will probably be too inefficient to make serious progres. Before 3.0 is out there should be at least a 2.6 release, and possibly other point releases, with improved framework coverage (not all system frameworks are available through PyObjC at the moment), other minor feature updates and bugfixes. One thing I'm not sure about is Xcode support, in particular support for designing GUI using the Interface Builder tool embedded in Xcode. I don't like Xcode as a Python editor (which is why the xcode templates are basicly dead at the moment), and haven't made my mind up on how to proceed here. Two major options are to either generate an Xcode project when needed (just to enough to let Xcode know where to find resource files and source code), and to just ignore Xcode completely but design the UI in Xcode. That last option should be a lot easier with autolayout (introduced in OSX 10.7), but might need a helper library to keep code readable (I've noticed with other toolkits that it is very easy to end up with long blocks of code that create UI elements and have no useful structure). Happy holidays, Ronald From bergs at janelia.hhmi.org Wed Dec 26 18:08:34 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 26 Dec 2012 17:08:34 +0000 Subject: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7 In-Reply-To: References:

Message-ID: <92425FEB-FB9D-44B2-96B7-CECCCDE94114@janelia.hhmi.org> Hi Ronald, > The screensaver framework should work just fine, but only if the bundle contains 64-bit code. > > What is the output of 'file SillyBalls.saver/Contents/MacOS/SillyBalls' ? I have two versions of python, so I'll try this twice. First with the built-in version: $ which python /usr/local/bin/python $ python --version Python 2.7.2 $ python setup.py py2app ??.. $ file dist/SillyBalls.saver/Contents/MacOS/SillyBalls dist/SillyBalls.saver/Contents/MacOS/SillyBalls: Mach-O universal binary with 2 architectures dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture i386): Mach-O bundle i386 dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture x86_64): Mach-O 64-bit bundle x86_64 $ file dist/SillyBalls.saver/Contents/MacOS/python dist/SillyBalls.saver/Contents/MacOS/python: Mach-O universal binary with 2 architectures dist/SillyBalls.saver/Contents/MacOS/python (for architecture i386): Mach-O executable i386 dist/SillyBalls.saver/Contents/MacOS/python (for architecture x86_64): Mach-O 64-bit executable x86_64 And with my own build of python: $ rm -rf build dist $ which python /Users/bergs/special-build/Frameworks/Python.framework/Versions/2.7/bin/python $ python --version Python 2.7.3rc2 $ python setup.py py2app ??. $ file dist/SillyBalls.saver/Contents/MacOS/SillyBalls dist/SillyBalls.saver/Contents/MacOS/SillyBalls: Mach-O 64-bit bundle x86_64 $ file dist/SillyBalls.saver/Contents/MacOS/python dist/SillyBalls.saver/Contents/MacOS/python: Mach-O 64-bit executable x86_64 > Which versions of python, pyobjc, and py2app do you use (and for the python versions, is this the apple provided one or some other install)? I installed the same version of pyobjc to each python install: $ python -c "import objc; print objc.__version__" 2.4 $ python -c "import py2app; print py2app.__version__" 0.7.2 The System Preferences app doesn't give a very useful error message ("Contact the developer of this screen saver for a newer version."). Do you know if there's any way to get a better idea of what's going wrong? As far as I can tell, Console.app doesn't have any useful output on this problem. Thanks, Stuart From bergs at janelia.hhmi.org Wed Dec 26 21:01:51 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 26 Dec 2012 20:01:51 +0000 Subject: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7 In-Reply-To: <92425FEB-FB9D-44B2-96B7-CECCCDE94114@janelia.hhmi.org> References:

<92425FEB-FB9D-44B2-96B7-CECCCDE94114@janelia.hhmi.org> Message-ID: <6E0E7F80-2987-45CB-B81D-DEB707507DB2@janelia.hhmi.org> One more note. I came across this link yesterday: http://developer.apple.com/library/mac/#qa/qa1666/_index.html How do I make sure that the ScreenSaver bundle I've created with py2app uses the correct garbage collection setting? Is there a way to specify GCC_ENABLE_OBJC_GC=required from setup.py? Also, is there a way to inspect a binary to see if this setting was used to build it? Sorry for my ignorance?. Thanks again, Stuart On Dec 26, 2012, at 12:08 PM, Stuart Berg wrote: > Hi Ronald, > >> The screensaver framework should work just fine, but only if the bundle contains 64-bit code. >> >> What is the output of 'file SillyBalls.saver/Contents/MacOS/SillyBalls' ? > > I have two versions of python, so I'll try this twice. First with the built-in version: > $ which python > /usr/local/bin/python > > $ python --version > Python 2.7.2 > > $ python setup.py py2app > ??.. > > $ file dist/SillyBalls.saver/Contents/MacOS/SillyBalls > dist/SillyBalls.saver/Contents/MacOS/SillyBalls: Mach-O universal binary with 2 architectures > dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture i386): Mach-O bundle i386 > dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture x86_64): Mach-O 64-bit bundle x86_64 > > $ file dist/SillyBalls.saver/Contents/MacOS/python > dist/SillyBalls.saver/Contents/MacOS/python: Mach-O universal binary with 2 architectures > dist/SillyBalls.saver/Contents/MacOS/python (for architecture i386): Mach-O executable i386 > dist/SillyBalls.saver/Contents/MacOS/python (for architecture x86_64): Mach-O 64-bit executable x86_64 > > And with my own build of python: > > $ rm -rf build dist > > $ which python > /Users/bergs/special-build/Frameworks/Python.framework/Versions/2.7/bin/python > > $ python --version > Python 2.7.3rc2 > > $ python setup.py py2app > ??. > > $ file dist/SillyBalls.saver/Contents/MacOS/SillyBalls > dist/SillyBalls.saver/Contents/MacOS/SillyBalls: Mach-O 64-bit bundle x86_64 > > $ file dist/SillyBalls.saver/Contents/MacOS/python > dist/SillyBalls.saver/Contents/MacOS/python: Mach-O 64-bit executable x86_64 > > >> Which versions of python, pyobjc, and py2app do you use (and for the python versions, is this the apple provided one or some other install)? > > > I installed the same version of pyobjc to each python install: > > $ python -c "import objc; print objc.__version__" > 2.4 > > $ python -c "import py2app; print py2app.__version__" > 0.7.2 > > The System Preferences app doesn't give a very useful error message ("Contact the developer of this screen saver for a newer version."). Do you know if there's any way to get a better idea of what's going wrong? As far as I can tell, Console.app doesn't have any useful output on this problem. > > Thanks, > Stuart > > > From bergs at janelia.hhmi.org Wed Dec 26 22:35:28 2012 From: bergs at janelia.hhmi.org (Berg, Stuart) Date: Wed, 26 Dec 2012 21:35:28 +0000 Subject: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7 In-Reply-To: <6E0E7F80-2987-45CB-B81D-DEB707507DB2@janelia.hhmi.org> References:

<92425FEB-FB9D-44B2-96B7-CECCCDE94114@janelia.hhmi.org> <6E0E7F80-2987-45CB-B81D-DEB707507DB2@janelia.hhmi.org> Message-ID: <7707795A-4631-4859-AE75-A5DDAA6C9A69@janelia.hhmi.org> Hi Ronald, Still trying to crack this nut?. If I open the screensaver from the command line using the System Preferences app, I get this error. It doesn't seem to happen with other screensavers (e.g. if I build the original (objective-c) SillyBalls screensaver, there are no errors. $ /Applications/System\ Preferences.app/Contents/MacOS/System\ Preferences dist/SillyBalls.saver System Preferences(7983,0x7fff7e816960) malloc: reference count underflow for 0x4003b38e0, break on auto_refcount_underflow_error to debug. System Preferences(7983,0x7fff7e816960) malloc: reference count underflow for 0x400352b80, break on auto_refcount_underflow_error to debug. Unfortunately, I'm a little out of my comfort-zone here. Could this error be causing my problem? Here's a log of a gdb session showing the backtrace at the site of the refcount error. (Note the "br" command before the "run" command.) (By the way, if you try this yourself, ignore any "invalid frame buffer operation" errors you may see, which are probably coming from the built-in "Flurry" screensaver.) Thanks again for any ideas you've got? Stuart $ gdb --args /Applications/System\ Preferences.app/Contents/MacOS/System\ Preferences dist/SillyBalls.saver GNU gdb 6.3.50-20050815 (Apple version gdb-1822) (Sun Aug 5 03:00:42 UTC 2012) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ............. done (gdb) br auto_refcount_underflow_error Function "auto_refcount_underflow_error" not defined. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (auto_refcount_underflow_error) pending. (gdb) run Starting program: /Applications/System Preferences.app/Contents/MacOS/System Preferences dist/SillyBalls.saver Reading symbols for shared libraries ++++++++++++.................................................................................................................................... done Breakpoint 1 at 0x7fff9766d0c4 Pending breakpoint 1 - "auto_refcount_underflow_error" resolved Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries ......... done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries .. done Reading symbols for shared libraries .............................. done Reading symbols for shared libraries ............... done Reading symbols for shared libraries . done Reading symbols for shared libraries . done Reading symbols for shared libraries . done System Preferences(8058,0x7fff7e816960) malloc: reference count underflow for 0x4003b8a20, break on auto_refcount_underflow_error to debug. Breakpoint 1, 0x00007fff9766d0c4 in auto_refcount_underflow_error () (gdb) backtrace #0 0x00007fff9766d0c4 in auto_refcount_underflow_error () #1 0x00007fff976a19c7 in Auto::SubzoneBlockRef::dec_refcount_no_lock () #2 0x00007fff976a19fa in Auto::SubzoneBlockRef::dec_refcount () #3 0x00007fff9766821e in Auto::sieve_base::sieve_base_pointer > () #4 0x00007fff9766474c in auto_zone_release () #5 0x00007fff8d86ea9a in CFRelease () #6 0x00007fff8ffd91c7 in -[NSWindow _cancelPerformSelectors] () #7 0x00007fff9043e716 in -[NSWindow finalize] () #8 0x00007fff9464c57c in finalizeOneObject () #9 0x00007fff9767a07e in Auto::foreach_block_do () #10 0x00007fff9464c4ac in batchFinalize () #11 0x00007fff9464b219 in batchFinalizeOnMainThread () #12 0x00007fff9464afdc in objc_collect () #13 0x00007fff8d901d65 in __NSArrayEnumerate () #14 0x00007fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #15 0x00007fff8d901cee in __NSArrayEnumerate () #16 0x00007fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #17 0x00007fff8d901cee in __NSArrayEnumerate () #18 0x00007fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #19 0x00007fff8d901cee in __NSArrayEnumerate () #20 0x00007fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #21 0x00007fff8d901cee in __NSArrayEnumerate () #22 0x00007fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #23 0x00007fff8d901cee in __NSArrayEnumerate () #24 0x00007fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #25 0x00007fff8d901cee in __NSArrayEnumerate () #26 0x00007fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #27 0x00007fff8d901cee in __NSArrayEnumerate () #28 0x00007fff8fe67aeb in -[NSView(NSInternal) _updateTrackingAreas] () #29 0x00007fff8fe67444 in __-[NSWindow _postInvalidCursorRects]_block_invoke_1 () #30 0x00007fff8d8c98e7 in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ () #31 0x00007fff8d8c9846 in __CFRunLoopDoObservers () #32 0x00007fff8d89eaf9 in __CFRunLoopRun () #33 0x00007fff8d89e486 in CFRunLoopRunSpecific () #34 0x00007fff909a22bf in RunCurrentEventLoopInMode () #35 0x00007fff909a956d in ReceiveNextEventCommon () #36 0x00007fff909a93fa in BlockUntilNextEventMatchingListInMode () #37 0x00007fff8fda1779 in _DPSNextEvent () #38 0x00007fff8fda107d in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #39 0x00007fff8fd9d9b9 in -[NSApplication run] () #40 0x00007fff90019eac in NSApplicationMain () #41 0x0000000100001b30 in ?? () From ronaldoussoren at mac.com Thu Dec 27 07:57:03 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 27 Dec 2012 07:57:03 +0100 Subject: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7 In-Reply-To: <6E0E7F80-2987-45CB-B81D-DEB707507DB2@janelia.hhmi.org> References:

<92425FEB-FB9D-44B2-96B7-CECCCDE94114@janelia.hhmi.org> <6E0E7F80-2987-45CB-B81D-DEB707507DB2@janelia.hhmi.org> Message-ID: <24CC4907-602B-4D06-B904-E16905AEE01D@mac.com> On 26 Dec, 2012, at 21:01, "Berg, Stuart" wrote: > One more note. I came across this link yesterday: > http://developer.apple.com/library/mac/#qa/qa1666/_index.html > > How do I make sure that the ScreenSaver bundle I've created with py2app uses the correct garbage collection setting? Is there a way to specify GCC_ENABLE_OBJC_GC=required from setup.py? Also, is there a way to inspect a binary to see if this setting was used to build it? You would have to enable GC for PyObjC, but that will likely cause problems. The codebase of PyObjC currently uses the CoreFoundation refcount APIs to ensure that Python has strong references to objects even when GC is enabled, but the code likely isn't completely GC-safe yet (I've never audited it for GC-safeness and know that a number of classes have a dealloc method but not finalize method). You can check the GC awareness of binaries with: $ otool -vo /Applications/Xcode.app/Contents/MacOS/Xcode ... Contents of (__DATA,__objc_imageinfo) section version 0 flags 0x6 OBJC_IMAGE_SUPPORTS_GC I don't know the path to the screen saver engine (the binary that will actually load the screensaver). BTW. This might explain why the Screen Saver example works for me, but not for you: Apple is clearly moving away from GC and I'm running a newer OS release where Apple might have migrated the Screen Saver engine back to manual reference counting. It is extermely annoying that the need for GC is buried in a technote and isn't mentioned in the Screen Saver framework documentation at all. Ronald > > Sorry for my ignorance?. > > Thanks again, > Stuart > > On Dec 26, 2012, at 12:08 PM, Stuart Berg wrote: > >> Hi Ronald, >> >>> The screensaver framework should work just fine, but only if the bundle contains 64-bit code. >>> >>> What is the output of 'file SillyBalls.saver/Contents/MacOS/SillyBalls' ? >> >> I have two versions of python, so I'll try this twice. First with the built-in version: >> $ which python >> /usr/local/bin/python >> >> $ python --version >> Python 2.7.2 >> >> $ python setup.py py2app >> ??.. >> >> $ file dist/SillyBalls.saver/Contents/MacOS/SillyBalls >> dist/SillyBalls.saver/Contents/MacOS/SillyBalls: Mach-O universal binary with 2 architectures >> dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture i386): Mach-O bundle i386 >> dist/SillyBalls.saver/Contents/MacOS/SillyBalls (for architecture x86_64): Mach-O 64-bit bundle x86_64 >> >> $ file dist/SillyBalls.saver/Contents/MacOS/python >> dist/SillyBalls.saver/Contents/MacOS/python: Mach-O universal binary with 2 architectures >> dist/SillyBalls.saver/Contents/MacOS/python (for architecture i386): Mach-O executable i386 >> dist/SillyBalls.saver/Contents/MacOS/python (for architecture x86_64): Mach-O 64-bit executable x86_64 >> >> And with my own build of python: >> >> $ rm -rf build dist >> >> $ which python >> /Users/bergs/special-build/Frameworks/Python.framework/Versions/2.7/bin/python >> >> $ python --version >> Python 2.7.3rc2 >> >> $ python setup.py py2app >> ??. >> >> $ file dist/SillyBalls.saver/Contents/MacOS/SillyBalls >> dist/SillyBalls.saver/Contents/MacOS/SillyBalls: Mach-O 64-bit bundle x86_64 >> >> $ file dist/SillyBalls.saver/Contents/MacOS/python >> dist/SillyBalls.saver/Contents/MacOS/python: Mach-O 64-bit executable x86_64 >> >> >>> Which versions of python, pyobjc, and py2app do you use (and for the python versions, is this the apple provided one or some other install)? >> >> >> I installed the same version of pyobjc to each python install: >> >> $ python -c "import objc; print objc.__version__" >> 2.4 >> >> $ python -c "import py2app; print py2app.__version__" >> 0.7.2 >> >> The System Preferences app doesn't give a very useful error message ("Contact the developer of this screen saver for a newer version."). Do you know if there's any way to get a better idea of what's going wrong? As far as I can tell, Console.app doesn't have any useful output on this problem. >> >> Thanks, >> Stuart >> >> >> > From ronaldoussoren at mac.com Thu Dec 27 10:17:24 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 27 Dec 2012 10:17:24 +0100 Subject: [Pythonmac-SIG] PyObjC ScreenSaver on 10.7 In-Reply-To: <24CC4907-602B-4D06-B904-E16905AEE01D@mac.com> References:

<92425FEB-FB9D-44B2-96B7-CECCCDE94114@janelia.hhmi.org> <6E0E7F80-2987-45CB-B81D-DEB707507DB2@janelia.hhmi.org> <24CC4907-602B-4D06-B904-E16905AEE01D@mac.com> Message-ID: <686AB146-8C1E-4B2D-9950-370277840465@mac.com> On 27 Dec, 2012, at 7:57, Ronald Oussoren wrote: > > BTW. This might explain why the Screen Saver example works for me, but not for you: Apple is clearly moving away from GC and I'm running a newer OS release where Apple might have migrated the Screen Saver engine back to manual reference counting. This forum post also seems to indicate that GC is needed for screen savers on OSX 10.6 and 10.7, but not 10.8: This means you cannot use PyObjC to build screen savers for OSX 10.6 or 10.7, I'll update the documentation. While it is technically possible to make PyObjC GC-safe I don't think it is worth the effort because GC is on the way out. Ronald From nadavh at gmail.com Thu Dec 27 12:28:58 2012 From: nadavh at gmail.com (Nadav Hashimshony) Date: Thu, 27 Dec 2012 13:28:58 +0200 Subject: [Pythonmac-SIG] py2app issue, app crashes on 10.7.5 Message-ID: <73EC2F17018E4027AA502B4B46BAF9EC@gmail.com> Hi All i build a Python app using py2app on OSX 10.8.2 and it work fine. when trying to run the app on OSX 10.7.5 the app crashes and doesn't start. when cd'ing to the app directory and running the pyx from cli it work fine. it look like something is happening when i double click the app file? any suggestions how to investigate this issue? regards, Nadav. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nadavh at gmail.com Thu Dec 27 14:00:58 2012 From: nadavh at gmail.com (Nadav Hashimshony) Date: Thu, 27 Dec 2012 15:00:58 +0200 Subject: [Pythonmac-SIG] py2app issue, app crashes on 10.7.5 In-Reply-To: <8E6C840C-F9E3-4578-95AF-5A528C41BC2C@mac.com> References: <73EC2F17018E4027AA502B4B46BAF9EC@gmail.com> <8E6C840C-F9E3-4578-95AF-5A528C41BC2C@mac.com> Message-ID: <361FF7FE930940C7B6D30F0EC07F95F1@gmail.com> Thanks, if i run from command line it works great. the crash report is: Process: installer [14433] Path: /Users/USER/Desktop/installer.app/Contents/MacOS/installer Identifier: org.pythonmac.unspecified.installer Version: 0.0.0 (0.0.0) Code Type: X86-64 (Native) Parent Process: launchd [109] Date/Time: 2012-12-27 14:58:10.799 +0200 OS Version: Mac OS X 10.7.5 (11G63) Report Version: 9 Interval Since Last Report: 673388 sec Crashes Since Last Report: 14 Per-App Crashes Since Last Report: 10 Anonymous UUID: CD94B359-4A6C-4F0E-8F52-04CC264F32B1 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000000 VM Regions Near 0: --> __TEXT 0000000100000000-0000000100006000 [ 24K] r-x/rwx SM=COW /Users/USER/Desktop/installer.app/Contents/MacOS/installer Application Specific Information: objc[14433]: garbage collection is OFF Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.CoreFoundation 0x00007fff931c716c CFStringGetCString + 44 1 org.pythonmac.unspecified.installer 0x0000000100003f61 py2app_main + 1984 2 org.pythonmac.unspecified.installer 0x00000001000049c8 main + 1496 3 org.pythonmac.unspecified.installer 0x0000000100000fb4 start + 52 Thread 1:: Dispatch queue: com.apple.libdispatch-manager 0 libsystem_kernel.dylib 0x00007fff8e7777e6 kevent + 10 1 libdispatch.dylib 0x00007fff8fff1786 _dispatch_mgr_invoke + 923 2 libdispatch.dylib 0x00007fff8fff0316 _dispatch_mgr_thread + 54 Thread 2: 0 libsystem_kernel.dylib 0x00007fff8e777192 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff8e830594 _pthread_wqthread + 758 2 libsystem_c.dylib 0x00007fff8e831b85 start_wqthread + 13 Thread 3: 0 libsystem_kernel.dylib 0x00007fff8e777192 __workq_kernreturn + 10 1 libsystem_c.dylib 0x00007fff8e830594 _pthread_wqthread + 758 2 libsystem_c.dylib 0x00007fff8e831b85 start_wqthread + 13 Thread 0 crashed with X86 Thread State (64-bit): rax: 0x0000000000000000 rbx: 0x0000000008000100 rcx: 0x0000000008000100 rdx: 0x0000000000000400 rdi: 0x0000000000000000 rsi: 0x00007fff5fbff460 rbp: 0x00007fff5fbfdb20 rsp: 0x00007fff5fbfdac0 r8: 0x0000000000000000 r9: 0x0000000100400190 r10: 0x00000000bc6a3b1f r11: 0x00000000901bcad0 r12: 0x0000000000000000 r13: 0x0000000000000000 r14: 0x00007fff5fbff460 r15: 0x0000000000000000 rip: 0x00007fff931c716c rfl: 0x0000000000010246 cr2: 0x0000000000000000 Logical CPU: 1 Binary Images: 0x100000000 - 0x100005ff7 +org.pythonmac.unspecified.installer (0.0.0 - 0.0.0) <8C77F687-4C7C-5570-85C8-D6BC781276B1> /Users/USER/Desktop/installer.app/Contents/MacOS/installer 0x7fff6c0ef000 - 0x7fff6c123baf dyld (195.6 - ???) /usr/lib/dyld 0x7fff8ab98000 - 0x7fff8ac0eff7 libc++.1.dylib (28.4.0 - compatibility 1.0.0) /usr/lib/libc++.1.dylib 0x7fff8b9e0000 - 0x7fff8b9e2fff libquarantine.dylib (36.7.0 - compatibility 1.0.0) <8D9832F9-E4A9-38C3-B880-E5210B2353C7> /usr/lib/system/libquarantine.dylib 0x7fff8c58f000 - 0x7fff8c593fff libmathCommon.A.dylib (2026.0.0 - compatibility 1.0.0) /usr/lib/system/libmathCommon.A.dylib 0x7fff8c912000 - 0x7fff8c985fff libstdc++.6.dylib (52.0.0 - compatibility 7.0.0) <6BDD43E4-A4B1-379E-9ED5-8C713653DFF2> /usr/lib/libstdc++.6.dylib 0x7fff8e711000 - 0x7fff8e75ffff libauto.dylib (??? - ???) /usr/lib/libauto.dylib 0x7fff8e760000 - 0x7fff8e780fff libsystem_kernel.dylib (1699.32.7 - compatibility 1.0.0) <66C9F9BD-C7B3-30D4-B1A0-03C8A6392351> /usr/lib/system/libsystem_kernel.dylib 0x7fff8e7e0000 - 0x7fff8e8bdfef libsystem_c.dylib (763.13.0 - compatibility 1.0.0) <41B43515-2806-3FBC-ACF1-A16F35B7E290> /usr/lib/system/libsystem_c.dylib 0x7fff8ea9d000 - 0x7fff8ea9eff7 libsystem_blocks.dylib (53.0.0 - compatibility 1.0.0) <8BCA214A-8992-34B2-A8B9-B74DEACA1869> /usr/lib/system/libsystem_blocks.dylib 0x7fff8ec8f000 - 0x7fff8ec94fff libcompiler_rt.dylib (6.0.0 - compatibility 1.0.0) <98ECD5F6-E85C-32A5-98CD-8911230CB66A> /usr/lib/system/libcompiler_rt.dylib 0x7fff8ec95000 - 0x7fff8ec9afff libcache.dylib (47.0.0 - compatibility 1.0.0) /usr/lib/system/libcache.dylib 0x7fff8ed07000 - 0x7fff8ed49ff7 libcommonCrypto.dylib (55010.0.0 - compatibility 1.0.0) /usr/lib/system/libcommonCrypto.dylib 0x7fff8eef4000 - 0x7fff8efd8e5f libobjc.A.dylib (228.0.0 - compatibility 1.0.0) <871E688B-CF57-3BC7-80D6-F6476DFF109B> /usr/lib/libobjc.A.dylib 0x7fff8f005000 - 0x7fff8f006fff libDiagnosticMessagesClient.dylib (??? - ???) <3DCF577B-F126-302B-BCE2-4DB9A95B8598> /usr/lib/libDiagnosticMessagesClient.dylib 0x7fff8f22f000 - 0x7fff8f230ff7 libremovefile.dylib (21.1.0 - compatibility 1.0.0) <739E6C83-AA52-3C6C-A680-B37FE2888A04> /usr/lib/system/libremovefile.dylib 0x7fff8ffee000 - 0x7fff8fffcfff libdispatch.dylib (187.10.0 - compatibility 1.0.0) <8E03C652-922A-3399-93DE-9EA0CBFA0039> /usr/lib/system/libdispatch.dylib 0x7fff9007e000 - 0x7fff9007ffff libunc.dylib (24.0.0 - compatibility 1.0.0) /usr/lib/system/libunc.dylib 0x7fff90082000 - 0x7fff90088ff7 libunwind.dylib (30.0.0 - compatibility 1.0.0) <1E9C6C8C-CBE8-3F4B-A5B5-E03E3AB53231> /usr/lib/system/libunwind.dylib 0x7fff90956000 - 0x7fff90957ff7 libsystem_sandbox.dylib (??? - ???) <2A09E4DA-F47C-35CB-B70C-E0492BA9F20E> /usr/lib/system/libsystem_sandbox.dylib 0x7fff90958000 - 0x7fff90962ff7 liblaunch.dylib (392.39.0 - compatibility 1.0.0) <8C235D13-2928-30E5-9E12-2CC3D6324AE2> /usr/lib/system/liblaunch.dylib 0x7fff90963000 - 0x7fff90963fff libkeymgr.dylib (23.0.0 - compatibility 1.0.0) <61EFED6A-A407-301E-B454-CD18314F0075> /usr/lib/system/libkeymgr.dylib 0x7fff90e02000 - 0x7fff90e14ff7 libz.1.dylib (1.2.5 - compatibility 1.0.0) <30CBEF15-4978-3DED-8629-7109880A19D4> /usr/lib/libz.1.dylib 0x7fff90fda000 - 0x7fff90fdbfff libdnsinfo.dylib (395.11.0 - compatibility 1.0.0) <853BAAA5-270F-3FDC-B025-D448DB72E1C3> /usr/lib/system/libdnsinfo.dylib 0x7fff91b26000 - 0x7fff91b2dfff libcopyfile.dylib (85.1.0 - compatibility 1.0.0) <172B1985-F24A-34E9-8D8B-A2403C9A0399> /usr/lib/system/libcopyfile.dylib 0x7fff92a26000 - 0x7fff92a2cfff libmacho.dylib (800.0.0 - compatibility 1.0.0) /usr/lib/system/libmacho.dylib 0x7fff9318a000 - 0x7fff9335eff7 com.apple.CoreFoundation (6.7.2 - 635.21) <62A3402E-A4E7-391F-AD20-1EF20236CE1B> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation 0x7fff934f9000 - 0x7fff936fbfff libicucore.A.dylib (46.1.0 - compatibility 1.0.0) <0176782F-9526-3905-813A-7A5676EC2C86> /usr/lib/libicucore.A.dylib 0x7fff94699000 - 0x7fff946a1fff libsystem_dnssd.dylib (??? - ???) <584B321E-5159-37CD-B2E7-82E069C70AFB> /usr/lib/system/libsystem_dnssd.dylib 0x7fff94bcb000 - 0x7fff94bcffff libdyld.dylib (195.5.0 - compatibility 1.0.0) /usr/lib/system/libdyld.dylib 0x7fff951b0000 - 0x7fff951ebfff libsystem_info.dylib (??? - ???) <35F90252-2AE1-32C5-8D34-782C614D9639> /usr/lib/system/libsystem_info.dylib 0x7fff951ec000 - 0x7fff95219fe7 libSystem.B.dylib (159.1.0 - compatibility 1.0.0) <6E5C8AC3-DBB7-31CB-BEB7-D6ED8E6DE0CE> /usr/lib/libSystem.B.dylib 0x7fff962be000 - 0x7fff962c9ff7 libc++abi.dylib (14.0.0 - compatibility 1.0.0) <8FF3D766-D678-36F6-84AC-423C878E6D14> /usr/lib/libc++abi.dylib 0x7fff96ca8000 - 0x7fff96cb1ff7 libsystem_notify.dylib (80.1.0 - compatibility 1.0.0) /usr/lib/system/libsystem_notify.dylib 0x7fff9705d000 - 0x7fff9707afff libxpc.dylib (77.19.0 - compatibility 1.0.0) <9F57891B-D7EF-3050-BEDD-21E7C6668248> /usr/lib/system/libxpc.dylib 0x7fff9746d000 - 0x7fff97472ff7 libsystem_network.dylib (??? - ???) <5DE7024E-1D2D-34A2-80F4-08326331A75B> /usr/lib/system/libsystem_network.dylib External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 2 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 305961 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=57.6M resident=41.8M(73%) swapped_out_or_unallocated=15.8M(27%) Writable regions: Total=30.3M written=208K(1%) resident=436K(1%) swapped_out=0K(0%) unallocated=29.9M(99%) REGION TYPE VIRTUAL =========== ======= MALLOC 20.5M MALLOC guard page 48K STACK GUARD 56.0M Stack 9752K VM_ALLOCATE 36K __DATA 1240K __LINKEDIT 49.1M __TEXT 8744K __UNICODE 544K shared memory 16K =========== ======= TOTAL 145.5M Model: MacBookPro5,1, BootROM MBP51.007E.B06, 2 processors, Intel Core 2 Duo, 2.8 GHz, 4 GB, SMC 1.33f8 Graphics: NVIDIA GeForce 9600M GT, NVIDIA GeForce 9600M GT, PCIe, 512 MB Graphics: NVIDIA GeForce 9400M, NVIDIA GeForce 9400M, PCI, 256 MB Memory Module: BANK 0/DIMM1, 4 GB, DDR3, 1067 MHz, 0x0198, 0x393955353432382D3034312E4130314C4620 AirPort: spairport_wireless_card_type_airport_extreme (0x14E4, 0x8D), Broadcom BCM43xx 1.0 (5.106.198.19.22) Bluetooth: Version 4.0.8f17, 2 service, 18 devices, 1 incoming serial ports Network Service: Wi-Fi, AirPort, en1 Serial ATA Device: Hitachi HTS543232L9SA02, 320.07 GB Serial ATA Device: MATSHITADVD-R UJ-868 USB Device: Cruzer Edge, 0x0781 (SanDisk Corporation), 0x556b, 0x24100000 / 3 USB Device: Built-in iSight, apple_vendor_id, 0x8507, 0x24400000 / 2 USB Device: Apple Internal Keyboard / Trackpad, apple_vendor_id, 0x0237, 0x04600000 / 3 USB Device: IR Receiver, apple_vendor_id, 0x8242, 0x04500000 / 2 USB Device: BRCM2046 Hub, 0x0a5c (Broadcom Corp.), 0x4500, 0x06100000 / 2 USB Device: Bluetooth USB Host Controller, apple_vendor_id, 0x8213, 0x06110000 / 3 On Thursday, December 27, 2012 at 2:56 PM, Ronald Oussoren wrote: > > On 27 Dec, 2012, at 12:28, Nadav Hashimshony wrote: > > > Hi All > > > > i build a Python app using py2app on OSX 10.8.2 and it work fine. > > > > when trying to run the app on OSX 10.7.5 the app crashes and doesn't start. > > What do you mean by crashes? Is there a crash reporter screen or some other error dialog? > > > > when cd'ing to the app directory and running the pyx from cli it work fine. > > What happens when you start the application from the command line? > > For application "MyApp.app" you do this by running "MyApp.app/Contents/MacOS/MyApp". > > Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Thu Dec 27 13:56:01 2012 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 27 Dec 2012 13:56:01 +0100 Subject: [Pythonmac-SIG] py2app issue, app crashes on 10.7.5 In-Reply-To: <73EC2F17018E4027AA502B4B46BAF9EC@gmail.com> References: <73EC2F17018E4027AA502B4B46BAF9EC@gmail.com> Message-ID: <8E6C840C-F9E3-4578-95AF-5A528C41BC2C@mac.com> On 27 Dec, 2012, at 12:28, Nadav Hashimshony wrote: > Hi All > > i build a Python app using py2app on OSX 10.8.2 and it work fine. > > when trying to run the app on OSX 10.7.5 the app crashes and doesn't start. What do you mean by crashes? Is there a crash reporter screen or some other error dialog? > > when cd'ing to the app directory and running the pyx from cli it work fine. What happens when you start the application from the command line? For application "MyApp.app" you do this by running "MyApp.app/Contents/MacOS/MyApp". Ronald From alex.honeywell at gmail.com Mon Dec 24 19:11:40 2012 From: alex.honeywell at gmail.com (Alex Honeywell) Date: Mon, 24 Dec 2012 18:11:40 -0000 Subject: [Pythonmac-SIG] py2app error when launching built app In-Reply-To: <8ACE35B2-C58B-4B08-8BFD-D053B725BD26@mac.com> References: <8ACE35B2-C58B-4B08-8BFD-D053B725BD26@mac.com> Message-ID: Framework build. I believe it had something to do with a bad environment (I was using virtualenv when I was getting this error and there were a few pathing conflicts). I deleted everything and made a more isolated Python environment with homebrew in /usr/local and it works fine now. On Mon, Dec 24, 2012 at 3:53 AM, Ronald Oussoren wrote: > > On 11 Nov, 2012, at 23:26, Alex Honeywell > wrote: > > > I've got my app successfully bundled and built, but when I try to launch > it from Finder I get "snakewatch: Error" and nothing else except "exited > with error: 255" in Console. > > > > When I run the binary from Terminal instead, I get > > > > Traceback (most recent call last): > > File > "/Volumes/Data/Development/snakewatch/dist/snakewatch.app/Contents/Resources/__boot__.py", > line 7, in > > _reset_sys_path() > > File > "/Volumes/Data/Development/snakewatch/dist/snakewatch.app/Contents/Resources/__boot__.py", > line 4, in _reset_sys_path > > resources = os.environ['RESOURCEPATH'] > > File "UserDict.pyc", line 23, in __getitem__ > > KeyError: 'RESOURCEPATH' > > 2012-11-11 17:18:07.567 snakewatch[92013:707] snakewatch Error > > > > If I run "RESOURCEPATH=$(pwd)/Resources MacOS/snakewatch" I get > > > > Traceback (most recent call last): > > File > "/Volumes/Data/Development/snakewatch/dist/snakewatch.app/Contents/Resources/__boot__.py", > line 316, in > > _run() > > File > "/Volumes/Data/Development/snakewatch/dist/snakewatch.app/Contents/Resources/__boot__.py", > line 304, in _run > > argv0 = os.path.basename(os.environ['ARGVZERO']) > > File "UserDict.pyc", line 23, in __getitem__ > > KeyError: 'ARGVZERO' > > > > and if I run "RESOURCEPATH=$(pwd)/Resources ARGVZERO='' > MacOS/snakewatch" it launches fine. > > This appears to be the same problem as < > https://bitbucket.org/ronaldoussoren/py2app/issue/81/env-var-argvzero-resourcepath-not-defined > >. > > Do you use a framework build of python or a basic shared library build > ("--enable-shared")? > > Ronald > -------------- next part -------------- An HTML attachment was scrubbed... URL: