From ronaldoussoren at mac.com Thu Jun 1 07:27:39 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 1 Jun 2006 07:27:39 +0200 Subject: [Pythonmac-SIG] Pythonmac facelift In-Reply-To: <09EA3E09-8A29-42E9-BB3D-F44215AD1744@redivi.com> References: <447DFA9D.6020802@macosx.com> <09EA3E09-8A29-42E9-BB3D-F44215AD1744@redivi.com> Message-ID: On 31-mei-2006, at 22:30, Bob Ippolito wrote: > > On May 31, 2006, at 1:20 PM, kevin parks wrote: > >> there was all this talk here and the display of lovely new icons for >> months... looked great... but i downloaded and installed the >> universal >> installer of the latest greatest python and i just have the >> craptacular >> old icons... so, was this idea dropped & the icons scrapped or... >> does >> the lack of zexy new icons mean i have an old installer somehow? > > It means the installer hasn't been updated. I'm pretty sure the new > icons are in svn, but we haven't made a release since that happened. The new icons are in the 2.5 SVN. I haven't had time yet to update the 2.4 installer, but might do so next weekend. Ronald From glassfordm at hotmail.com Thu Jun 1 18:32:45 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Thu, 01 Jun 2006 12:32:45 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem Message-ID: To try building a universal binary version of an application I'm working on, I'm trying to get and build a new version of PyObjC and Py2App. I've successfully installed the correct version of Python from http://pythonmac.org/packages/py24-fat/ and have gotten the latest PyObjC from http://svn.red-bean.com/pyobjc/trunk. It seemed to build OK with "python setup.py build" (at least, I didn't see any errors). Running "python setup.py test" got 5 errors (the expected failure of dejagnu.libffi.call.cls_1_1byte and dejagnu.libffi.call.cls_2byte and three others--I'll paste them at the end of this message in case they're important, though they don't look like they have anything to do with my problem). My main problem is that when I run "setup.py bdist_mpkg --open", after building for a while, I get this error: running build_html - Doc/api-notes-macosx.txt (skipped: up to date) - Doc/C-API.txt (skipped: up to date) - Doc/coding-style.txt (skipped: up to date) - Doc/gnustep.txt (skipped: up to date) - Doc/index.txt (skipped: up to date) - Doc/intro.txt (skipped: up to date) - Doc/protocols.txt (skipped: up to date) - Doc/PyObjCTools.txt (skipped: up to date) - Doc/release-process.txt (skipped: up to date) - Doc/structure.txt (skipped: up to date) - Doc/TODO.txt (skipped: up to date) - Doc/tutorial_reading.txt (skipped: up to date) - Doc/wrapping.txt (skipped: up to date) - Doc/tutorial/tutorial.txt (skipped: up to date) - Doc/tutorial_embed/extending_objc_with_python.txt (skipped: up to date) - ./NEWS.txt (skipped: up to date) - ./Install.txt (skipped: up to date) - ./ReadMe.txt (skipped: up to date) - ./Examples/00ReadMe.txt (skipped: up to date) - ./Installer Package/10.2/ReadMe.txt (skipped: up to date) - ./Installer Package/10.3/ReadMe.txt (skipped: up to date) - ./Installer Package/10.4/ReadMe.txt (skipped: up to date) - ./Xcode/Project Templates/00README.txt error: /Users/Bob/cvsroot/pyobjc/trunk/pyobjc/source-deps/py2app: No such file or directory If I look in /Users/Bob/cvsroot/pyobjc/trunk/pyobjc/source-deps/, there is no py2app directory; there is a py2app-source directory, but that's not what it's looking for (for fun, I tried renaming py2app-source to py2app, but that didn't make it happy). Is this an error in the build script? Do I need to get something that I haven't gotten from svn or build something else first? Thanks for any help, Mike Failing unit tests: ====================================================================== ERROR: testImageData (AppKit.test.test_nsbitmapimagerep.TestNSBitmapImageRep) ---------------------------------------------------------------------- Traceback (most recent call last): File "build/lib.macosx-10.4-fat-2.4/AppKit/test/test_nsbitmapimagerep.py", line 42, in testImageData singlePlane = objc.allocateBuffer(width*height*3) TypeError: argument 1 must be impossible, not int ====================================================================== ERROR: testBadLengths (objc.test.test_allocatebuffer.TestAllocateBuffer) ---------------------------------------------------------------------- Traceback (most recent call last): File "build/lib.macosx-10.4-fat-2.4/objc/test/test_allocatebuffer.py", line 7, in testBadLengths self.assertRaises(ValueError, objc.allocateBuffer, 0) File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/unittest.py", line 320, in failUnlessRaises callableObj(*args, **kwargs) TypeError: argument 1 must be impossible, not int ====================================================================== ERROR: testBuffer (objc.test.test_allocatebuffer.TestAllocateBuffer) ---------------------------------------------------------------------- Traceback (most recent call last): File "build/lib.macosx-10.4-fat-2.4/objc/test/test_allocatebuffer.py", line 11, in testBuffer b = objc.allocateBuffer(10000) TypeError: argument 1 must be impossible, not int From shane.holloway at ieee.org Thu Jun 1 19:20:50 2006 From: shane.holloway at ieee.org (Shane Holloway (IEEE)) Date: Thu, 1 Jun 2006 11:20:50 -0600 Subject: [Pythonmac-SIG] Build configuration for 2.5svn Message-ID: <80F228CC-0761-4BD0-96C1-C026077F22DB@ieee.org> Hey all, I've been wanting to test the latest python 2.5 features out of SVN. I can make a framework build of python, but it doesn't have readline support and seems to be about 10% slower than just a local build. I was wondering if you could point me to any information about making "good builds" of the bleeding-edge svn for our mac developers? Thanks, -Shane From ronaldoussoren at mac.com Fri Jun 2 00:16:32 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 2 Jun 2006 00:16:32 +0200 Subject: [Pythonmac-SIG] Build configuration for 2.5svn In-Reply-To: <80F228CC-0761-4BD0-96C1-C026077F22DB@ieee.org> References: <80F228CC-0761-4BD0-96C1-C026077F22DB@ieee.org> Message-ID: <308DB429-632C-4219-A96B-54B777936302@mac.com> On 1-jun-2006, at 19:20, Shane Holloway (IEEE) wrote: > Hey all, > > I've been wanting to test the latest python 2.5 features out of SVN. > I can make a framework build of python, but it doesn't have readline > support and seems to be about 10% slower than just a local build. I > was wondering if you could point me to any information about making > "good builds" of the bleeding-edge svn for our mac developers? There is a build script in Mac/OSX/BuildScript. That should result in a package that contains a universal binary including support for readline, sqlite and bsddb. I must admit that I haven't tested the output of the script yet beyond checking that the expected extentions are present but the script is based on the one that is used to build the 2.4.3 universal installer. Ronald > > Thanks, > -Shane > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Fri Jun 2 00:19:25 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 2 Jun 2006 00:19:25 +0200 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: References: Message-ID: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> On 1-jun-2006, at 18:32, Michael Glassford wrote: > To try building a universal binary version of an application I'm > working > on, I'm trying to get and build a new version of PyObjC and Py2App. > I've > successfully installed the correct version of Python from > http://pythonmac.org/packages/py24-fat/ and have gotten the latest > PyObjC from http://svn.red-bean.com/pyobjc/trunk. It seemed to > build OK > with "python setup.py build" (at least, I didn't see any errors). > Running "python setup.py test" got 5 errors (the expected failure of > dejagnu.libffi.call.cls_1_1byte and dejagnu.libffi.call.cls_2byte and > three others--I'll paste them at the end of this message in case > they're > important, though they don't look like they have anything to do > with my > problem). > > My main problem is that when I run "setup.py bdist_mpkg --open", after > building for a while, I get this error: That's my bad. I've renamed subdirectories in source-deps due to a new warning in python2.5, but haven't updated the mpkg builder yet. The 3 test failures are odd, I haven't seen those yet on my systems (10.4.6 on intel and ppc). Ronald From glassfordm at gmail.com Fri Jun 2 02:21:56 2006 From: glassfordm at gmail.com (Michael Glassford) Date: Thu, 01 Jun 2006 20:21:56 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> Message-ID: <447F84A4.6050106@hotmail.com> Ronald Oussoren wrote: > On 1-jun-2006, at 18:32, Michael Glassford wrote: > >> My main problem is that when I run "setup.py bdist_mpkg --open", after >> building for a while, I get this error: > > That's my bad. I've renamed subdirectories in source-deps due to a > new warning in python2.5, but haven't updated the mpkg builder yet. Is there any way to work around it until you make the further changes? I tried just renaming the directory from "py2app-source" to "py2app" and running "setup.py bdist_mpkg --open" again, but it wasn't happy. Mike From glassfordm at hotmail.com Fri Jun 2 02:21:56 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Thu, 01 Jun 2006 20:21:56 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> Message-ID: <447F84A4.6050106@hotmail.com> Ronald Oussoren wrote: > On 1-jun-2006, at 18:32, Michael Glassford wrote: > >> My main problem is that when I run "setup.py bdist_mpkg --open", after >> building for a while, I get this error: > > That's my bad. I've renamed subdirectories in source-deps due to a > new warning in python2.5, but haven't updated the mpkg builder yet. Is there any way to work around it until you make the further changes? I tried just renaming the directory from "py2app-source" to "py2app" and running "setup.py bdist_mpkg --open" again, but it wasn't happy. Mike From ronaldoussoren at mac.com Fri Jun 2 08:35:05 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 02 Jun 2006 08:35:05 +0200 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <447F84A4.6050106@hotmail.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> Message-ID: <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> On Friday, June 02, 2006, at 02:22AM, Michael Glassford wrote: >Ronald Oussoren wrote: >> On 1-jun-2006, at 18:32, Michael Glassford wrote: >> >>> My main problem is that when I run "setup.py bdist_mpkg --open", after >>> building for a while, I get this error: >> >> That's my bad. I've renamed subdirectories in source-deps due to a >> new warning in python2.5, but haven't updated the mpkg builder yet. > >Is there any way to work around it until you make the further changes? I >tried just renaming the directory from "py2app-source" to "py2app" and >running "setup.py bdist_mpkg --open" again, but it wasn't happy. > >Mike > > This should do it: $ svn diff Index: setup-lib/pyobjc_mpkg.py =================================================================== --- setup-lib/pyobjc_mpkg.py (revision 1842) +++ setup-lib/pyobjc_mpkg.py (working copy) @@ -53,7 +53,7 @@ ) SUBPROJECT_SCHEMES = dict( - py2app='source-deps/py2app/setup.py', + py2app='source-deps/py2app-source/setup.py', ) I'm not at a location where I can perform the checking at the moment, I'll do that this weekend. Ronald From glassfordm at gmail.com Fri Jun 2 22:39:12 2006 From: glassfordm at gmail.com (Michael Glassford) Date: Fri, 02 Jun 2006 16:39:12 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> Message-ID: <4480A1F0.3070800@hotmail.com> This seems to have worked for me. I'm now getting another error (at the end of this message). I haven't had time to look at it yet because of other things that came up today, so it may be something simple. Thanks for the help, Mike ImportError: dlopen(/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyObjC/objc/_objc.so, 2): no suitable image found. Did find: /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyObjC/objc/_objc.so: mach-o, but wrong architecture Ronald Oussoren wrote: > > On Friday, June 02, 2006, at 02:22AM, Michael Glassford wrote: > >> Ronald Oussoren wrote: >>> On 1-jun-2006, at 18:32, Michael Glassford wrote: >>> >>>> My main problem is that when I run "setup.py bdist_mpkg --open", after >>>> building for a while, I get this error: >>> That's my bad. I've renamed subdirectories in source-deps due to a >>> new warning in python2.5, but haven't updated the mpkg builder yet. >> Is there any way to work around it until you make the further changes? I >> tried just renaming the directory from "py2app-source" to "py2app" and >> running "setup.py bdist_mpkg --open" again, but it wasn't happy. >> >> Mike >> >> > > This should do it: > > $ svn diff > Index: setup-lib/pyobjc_mpkg.py > =================================================================== > --- setup-lib/pyobjc_mpkg.py (revision 1842) > +++ setup-lib/pyobjc_mpkg.py (working copy) > @@ -53,7 +53,7 @@ > ) > > SUBPROJECT_SCHEMES = dict( > - py2app='source-deps/py2app/setup.py', > + py2app='source-deps/py2app-source/setup.py', > ) > > > I'm not at a location where I can perform the checking at the moment, I'll do that this weekend. > > Ronald > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From glassfordm at hotmail.com Fri Jun 2 22:39:12 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Fri, 02 Jun 2006 16:39:12 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> Message-ID: <4480A1F0.3070800@hotmail.com> This seems to have worked for me. I'm now getting another error (at the end of this message). I haven't had time to look at it yet because of other things that came up today, so it may be something simple. Thanks for the help, Mike ImportError: dlopen(/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyObjC/objc/_objc.so, 2): no suitable image found. Did find: /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PyObjC/objc/_objc.so: mach-o, but wrong architecture Ronald Oussoren wrote: > > On Friday, June 02, 2006, at 02:22AM, Michael Glassford wrote: > >> Ronald Oussoren wrote: >>> On 1-jun-2006, at 18:32, Michael Glassford wrote: >>> >>>> My main problem is that when I run "setup.py bdist_mpkg --open", after >>>> building for a while, I get this error: >>> That's my bad. I've renamed subdirectories in source-deps due to a >>> new warning in python2.5, but haven't updated the mpkg builder yet. >> Is there any way to work around it until you make the further changes? I >> tried just renaming the directory from "py2app-source" to "py2app" and >> running "setup.py bdist_mpkg --open" again, but it wasn't happy. >> >> Mike >> >> > > This should do it: > > $ svn diff > Index: setup-lib/pyobjc_mpkg.py > =================================================================== > --- setup-lib/pyobjc_mpkg.py (revision 1842) > +++ setup-lib/pyobjc_mpkg.py (working copy) > @@ -53,7 +53,7 @@ > ) > > SUBPROJECT_SCHEMES = dict( > - py2app='source-deps/py2app/setup.py', > + py2app='source-deps/py2app-source/setup.py', > ) > > > I'm not at a location where I can perform the checking at the moment, I'll do that this weekend. > > Ronald > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From ronaldoussoren at mac.com Sun Jun 4 10:49:52 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 4 Jun 2006 10:49:52 +0200 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <4480A1F0.3070800@hotmail.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> Message-ID: <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> On 2-jun-2006, at 22:39, Michael Glassford wrote: > This seems to have worked for me. I'm now getting another error (at > the end of this message). I haven't had time to look at it yet > because of other things that came up today, so it may be something > simple. This looks like PyObjC being build for PPC being used on Intel, that is the architecture for which PyObjC is build doesn't match the architecture of the currently running interpreter. The easiest way to fix this is probably to build a universal binary of PyObjC, there's an AUTO_UNIVERSAL option at the top of setup.py that enables building a universal binary with Apple's distribution of Python 2.3. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060604/2285e622/attachment.bin From h.goebel at goebel-consult.de Sun Jun 4 17:50:36 2006 From: h.goebel at goebel-consult.de (Hartmut Goebel) Date: Sun, 04 Jun 2006 17:50:36 +0200 Subject: [Pythonmac-SIG] Converting a PICT in PIL? Message-ID: <4483014C.4020803@goebel-consult.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, being new to Mac OSX, I wonder how to use all the magic stuff described in Apples docs. After scouting through the MacPathon documentation jungle I installed Python 2.4.1 (plus Tiger-fix) on OSX 10.4. May aim is to convert in-memory PICT images (fetched from Quark using AppleScript/appscript) into PIL images. I searched the web (and usenet), but dit not find a solution. After long search I've found some snippets in "Quartz Programming Guide for QuickDraw Developers". I managed converting the PICT into a PNG which can be read by PIL. But this requires a) Apples CoreGraphics SWIG-interface b) writing both the PICT anf the PNG into a file. Can anyony please point me to some snippets. Since what I have build now is not even "reinventing the wheel", but "reinventing the sledge" :-\ - -- Sch?nen Gru? - Regards Hartmut Goebel | Hartmut Goebel | IT-Security -- effizient | | h.goebel at goebel-consult.de | www.goebel-consult.de | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iQEVAwUBRIMBTMzajR0mSa83AQKvlQf7BWOdSmstiuAfAmNt+jZCpCw+7PzVYMbz UQuZLcDE85Lsah4bSE9yskcQZAI8J88u7ue+yr9falJjzCMadQ4ltneLTqj/TlV9 DQ6KbvZ0WxZYj81LTFdOky+NIRdGhKoKAY76cYKJ4yTI35gEYdWj2CHM31ZJKrxW RZy2R5GQvdyGyOCq4jnUA0UgQjbooDhXlZ5QkrSfay/mGearBTE9ijFc9WLQNg+G fLw+ygamZciQpntmX/Kfu5x9BXajoK5os5wnO/Q49cii6euKI15fu6E2LSGizxLp k1tP+vCLcmWhgcCZUiPCHGhbQ0PYTRJtUZZiBb6Lf5uLwegAaBPM6A== =ESPV -----END PGP SIGNATURE----- From h.goebel at goebel-consult.de Mon Jun 5 11:47:30 2006 From: h.goebel at goebel-consult.de (Hartmut Goebel) Date: Mon, 05 Jun 2006 11:47:30 +0200 Subject: [Pythonmac-SIG] Best way to use CoreGraphics Message-ID: <4483FDB2.7030003@goebel-consult.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, I wunder what's the best way for accessing CoreGraphics with Python 2.4, since Carbon.CG is nearly empty. * port Appley CoreGraphics module to 2.4 (but where is the source)? * using PYObjC? * something completly different? Any tipps? - -- Sch?nen Gru? - Regards Hartmut Goebel | Hartmut Goebel | IT-Security -- effizient | | h.goebel at goebel-consult.de | www.goebel-consult.de | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iQEVAwUBRIP9sszajR0mSa83AQIPHQf/Vg1Uz4/XFc7onbb6+ZivD55lXcE8xLI5 kasT8cxAiVQMA+nqejoKWdW6DHfSwSuH+BFqJum76Y1wzUiGBdDd5YOOgVHC82j5 qMw2e00hA/UNeIOj1A8FXRBF2GFjy5j9wovpWziiPNF64OJ5OXNx7dPajG9Ut5cb Ul98PW/zJ7Msd2KuT9XipJiTS+V/FNJ9PA/fJZPurFqmSCxo0wqv5ufp33N0sbMe IOgGGyUQNeuD7A5bpjCnyC8xSFp+U7DFd5cc/H2TeX9GWILStGhX8EGAv7sCey27 wnzyHjwrQbcucHFsBupPhvLNN7x1k+jb/NMouZZALdqVou0SBwHl0w== =D8O7 -----END PGP SIGNATURE----- From ronaldoussoren at mac.com Mon Jun 5 14:30:56 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 5 Jun 2006 14:30:56 +0200 Subject: [Pythonmac-SIG] Best way to use CoreGraphics In-Reply-To: <4483FDB2.7030003@goebel-consult.de> References: <4483FDB2.7030003@goebel-consult.de> Message-ID: <4E95D230-CF0A-4B9B-B56F-DC7C594F4F28@mac.com> On 5-jun-2006, at 11:47, Hartmut Goebel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello, > > I wunder what's the best way for accessing CoreGraphics with Python > 2.4, > since Carbon.CG is nearly empty. That's definetly the one you shouldn't be using ;-) > > * port Appley CoreGraphics module to 2.4 (but where is the source)? That's not an open-source library, hence porting is not possible. > * using PYObjC? That doesn't work either, CoreGraphics isn't an ObjC library. I'm thinking about extending PyObjC enough to be able to wrap the Core* libraries, but that hasn't happened yet. > * something completly different? Someone posted a message about bindings using Pyrex a while back. You should be able to find information about it in the list archives. Ronald > > Any tipps? > > - -- > Sch?nen Gru? - Regards > Hartmut Goebel > > | Hartmut Goebel | IT-Security -- effizient | > | h.goebel at goebel-consult.de | www.goebel-consult.de | > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2 (GNU/Linux) > Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org > > iQEVAwUBRIP9sszajR0mSa83AQIPHQf/Vg1Uz4/XFc7onbb6+ZivD55lXcE8xLI5 > kasT8cxAiVQMA+nqejoKWdW6DHfSwSuH+BFqJum76Y1wzUiGBdDd5YOOgVHC82j5 > qMw2e00hA/UNeIOj1A8FXRBF2GFjy5j9wovpWziiPNF64OJ5OXNx7dPajG9Ut5cb > Ul98PW/zJ7Msd2KuT9XipJiTS+V/FNJ9PA/fJZPurFqmSCxo0wqv5ufp33N0sbMe > IOgGGyUQNeuD7A5bpjCnyC8xSFp+U7DFd5cc/H2TeX9GWILStGhX8EGAv7sCey27 > wnzyHjwrQbcucHFsBupPhvLNN7x1k+jb/NMouZZALdqVou0SBwHl0w== > =D8O7 > -----END PGP SIGNATURE----- > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From daniellord at mac.com Mon Jun 5 16:13:14 2006 From: daniellord at mac.com (Daniel Lord) Date: Mon, 5 Jun 2006 07:13:14 -0700 Subject: [Pythonmac-SIG] FYI: Trouble with Xcode 2.3 is not localized... References: <1D4501A0.12954E41.00014E4A@netscape.net> Message-ID: Begin forwarded message: > From: pbmcl at netscape.net > Date: June 4, 2006 22:53:29 PDT > To: gmp-discuss at swox.com > Subject: Bad GMP build using Xcode 2.3 on Apple PowerMac G5 > > Apple Power Mac G5 users should be aware that the version of the > gcc compiler (gcc 4.0.1 Build 5341) included with Apple's recent > developer tools release (Xcode 2.3) fails 'make check' when > building GMP 4.2.1. Specifically, the mpz test 'reuse' fails. > > GMP 4.2.1 passes all 'make check' tests when built with gcc 4.0.1 > Build 5247, which is included with Xcode 2.2. > > The Xcode disk includes an uninstall script in the 'Utilities' > folder if you have already loaded version 2.3. > > Phil McLaughlin > > > > __________________________________________________________________ > Switch to Netscape Internet Service. > As low as $9.95 a month -- Sign up today at http://isp.netscape.com/ > register > > Netscape. Just the Net You Need. > > New! Netscape Toolbar for Internet Explorer > Search from anywhere on the Web and block those annoying pop-ups. > Download now at http://channels.netscape.com/ns/search/install.jsp > _______________________________________________ > gmp-discuss mailing list > gmp-discuss at swox.com > http://swox.com/mailman/listinfo/gmp-discuss Daniel Lord daniellord at mac.com --- "You will never regret getting up too early, and you'll always regret getting up too late, but sometimes you may regret giving up too late." -- Mountaineer's Adage -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060605/cacc2328/attachment.htm From glassfordm at gmail.com Mon Jun 5 20:42:17 2006 From: glassfordm at gmail.com (Michael Glassford) Date: Mon, 05 Jun 2006 14:42:17 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> Message-ID: <44847B09.9070504@hotmail.com> Ronald Oussoren wrote: > > On 2-jun-2006, at 22:39, Michael Glassford wrote: > >> This seems to have worked for me. I'm now getting another error (at >> the end of this message). I haven't had time to look at it yet because >> of other things that came up today, so it may be something simple. > > This looks like PyObjC being build for PPC being used on Intel, that is > the architecture for which PyObjC is build doesn't match the > architecture of the currently running interpreter. The easiest way to > fix this is probably to build a universal binary of PyObjC, there's an > AUTO_UNIVERSAL option at the top of setup.py that enables building a > universal binary with Apple's distribution of Python 2.3. I'm not using Apple's distribution of Python 2.3, so I didn't think this was necessary (I'm using 2.4.1 from from http://pythonmac.org/packages/py24-fat/). However, doing this fixed the problem and the application now works. Thanks for the help! Mike From glassfordm at hotmail.com Mon Jun 5 20:42:17 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Mon, 05 Jun 2006 14:42:17 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> Message-ID: <44847B09.9070504@hotmail.com> Ronald Oussoren wrote: > > On 2-jun-2006, at 22:39, Michael Glassford wrote: > >> This seems to have worked for me. I'm now getting another error (at >> the end of this message). I haven't had time to look at it yet because >> of other things that came up today, so it may be something simple. > > This looks like PyObjC being build for PPC being used on Intel, that is > the architecture for which PyObjC is build doesn't match the > architecture of the currently running interpreter. The easiest way to > fix this is probably to build a universal binary of PyObjC, there's an > AUTO_UNIVERSAL option at the top of setup.py that enables building a > universal binary with Apple's distribution of Python 2.3. I'm not using Apple's distribution of Python 2.3, so I didn't think this was necessary (I'm using 2.4.1 from from http://pythonmac.org/packages/py24-fat/). However, doing this fixed the problem and the application now works. Thanks for the help! Mike From bob at redivi.com Mon Jun 5 21:02:00 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 5 Jun 2006 12:02:00 -0700 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <44847B09.9070504@hotmail.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> <44847B09.9070504@hotmail.com> Message-ID: <2D5E5AD0-BD8B-48EC-A901-EE2E2075F243@redivi.com> On Jun 5, 2006, at 11:42 AM, Michael Glassford wrote: > Ronald Oussoren wrote: >> >> On 2-jun-2006, at 22:39, Michael Glassford wrote: >> >>> This seems to have worked for me. I'm now getting another error (at >>> the end of this message). I haven't had time to look at it yet >>> because >>> of other things that came up today, so it may be something simple. >> >> This looks like PyObjC being build for PPC being used on Intel, >> that is >> the architecture for which PyObjC is build doesn't match the >> architecture of the currently running interpreter. The easiest way to >> fix this is probably to build a universal binary of PyObjC, >> there's an >> AUTO_UNIVERSAL option at the top of setup.py that enables building a >> universal binary with Apple's distribution of Python 2.3. > > I'm not using Apple's distribution of Python 2.3, so I didn't think > this > was necessary (I'm using 2.4.1 from from > http://pythonmac.org/packages/py24-fat/). However, doing this fixed > the > problem and the application now works. If you got it from there, it's 2.4.3, not 2.4.1 (Universal- MacPython-2.4.3-2006-04-07.dmg). -bob From ronaldoussoren at mac.com Mon Jun 5 21:02:32 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 5 Jun 2006 21:02:32 +0200 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <44847B09.9070504@hotmail.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> <44847B09.9070504@hotmail.com> Message-ID: <17ABDA8D-CCD3-4B1B-8D82-6D9A6C542E22@mac.com> On 5-jun-2006, at 20:42, Michael Glassford wrote: > Ronald Oussoren wrote: >> On 2-jun-2006, at 22:39, Michael Glassford wrote: >>> This seems to have worked for me. I'm now getting another error >>> (at the end of this message). I haven't had time to look at it >>> yet because of other things that came up today, so it may be >>> something simple. >> This looks like PyObjC being build for PPC being used on Intel, >> that is the architecture for which PyObjC is build doesn't match >> the architecture of the currently running interpreter. The easiest >> way to fix this is probably to build a universal binary of PyObjC, >> there's an AUTO_UNIVERSAL option at the top of setup.py that >> enables building a universal binary with Apple's distribution of >> Python 2.3. > > I'm not using Apple's distribution of Python 2.3, so I didn't think > this was necessary (I'm using 2.4.1 from from http://pythonmac.org/ > packages/py24-fat/). However, doing this fixed the problem and the > application now works. Ehmm, you are NOT using Python 2.4. Look at the error message in your original e-mail, this mentions /System/Library/Python.framework/ Versions/2.3/..... Ronald From glassfordm at gmail.com Mon Jun 5 21:21:24 2006 From: glassfordm at gmail.com (Michael Glassford) Date: Mon, 05 Jun 2006 15:21:24 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <17ABDA8D-CCD3-4B1B-8D82-6D9A6C542E22@mac.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> <44847B09.9070504@hotmail.com> <17ABDA8D-CCD3-4B1B-8D82-6D9A6C542E22@mac.com> Message-ID: <44848434.4030305@hotmail.com> Ronald Oussoren wrote: > On 5-jun-2006, at 20:42, Michael Glassford wrote: > >> Ronald Oussoren wrote: >>> On 2-jun-2006, at 22:39, Michael Glassford wrote: >>>> This seems to have worked for me. I'm now getting another error >>>> (at the end of this message). I haven't had time to look at it >>>> yet because of other things that came up today, so it may be >>>> something simple. >>> This looks like PyObjC being build for PPC being used on Intel, >>> that is the architecture for which PyObjC is build doesn't match >>> the architecture of the currently running interpreter. The easiest >>> way to fix this is probably to build a universal binary of PyObjC, >>> there's an AUTO_UNIVERSAL option at the top of setup.py that >>> enables building a universal binary with Apple's distribution of >>> Python 2.3. >> I'm not using Apple's distribution of Python 2.3, so I didn't think >> this was necessary (I'm using 2.4.1 from from http://pythonmac.org/ >> packages/py24-fat/). However, doing this fixed the problem and the >> application now works. > > Ehmm, you are NOT using Python 2.4. Look at the error message in your > original e-mail, this mentions /System/Library/Python.framework/ > Versions/2.3/..... Well, you're right about that; apparently I wasn't using it there. However, I am using it most of the time, including earlier today when I said I got it working (I've verified that). What must have happened is this: /usr/local/bin isn't permanently added to the beginning of my PATH because most of the real work I'm doing requires Python 2.3; instead, when I want to work on the universal binary build, I open a new Terminal window and add it manually. I must have forgotten to add it once. So when I am correctly using the universal binary build of Python 2.4.3 (not 2.4.1, as Bob pointed out; sorry, I'm juggling too many things today), is it necessary to set AUTO_UNIVERSAL = 1 in PyObjC's setup.py? Mike From glassfordm at hotmail.com Mon Jun 5 21:21:24 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Mon, 05 Jun 2006 15:21:24 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <17ABDA8D-CCD3-4B1B-8D82-6D9A6C542E22@mac.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> <44847B09.9070504@hotmail.com> <17ABDA8D-CCD3-4B1B-8D82-6D9A6C542E22@mac.com> Message-ID: <44848434.4030305@hotmail.com> Ronald Oussoren wrote: > On 5-jun-2006, at 20:42, Michael Glassford wrote: > >> Ronald Oussoren wrote: >>> On 2-jun-2006, at 22:39, Michael Glassford wrote: >>>> This seems to have worked for me. I'm now getting another error >>>> (at the end of this message). I haven't had time to look at it >>>> yet because of other things that came up today, so it may be >>>> something simple. >>> This looks like PyObjC being build for PPC being used on Intel, >>> that is the architecture for which PyObjC is build doesn't match >>> the architecture of the currently running interpreter. The easiest >>> way to fix this is probably to build a universal binary of PyObjC, >>> there's an AUTO_UNIVERSAL option at the top of setup.py that >>> enables building a universal binary with Apple's distribution of >>> Python 2.3. >> I'm not using Apple's distribution of Python 2.3, so I didn't think >> this was necessary (I'm using 2.4.1 from from http://pythonmac.org/ >> packages/py24-fat/). However, doing this fixed the problem and the >> application now works. > > Ehmm, you are NOT using Python 2.4. Look at the error message in your > original e-mail, this mentions /System/Library/Python.framework/ > Versions/2.3/..... Well, you're right about that; apparently I wasn't using it there. However, I am using it most of the time, including earlier today when I said I got it working (I've verified that). What must have happened is this: /usr/local/bin isn't permanently added to the beginning of my PATH because most of the real work I'm doing requires Python 2.3; instead, when I want to work on the universal binary build, I open a new Terminal window and add it manually. I must have forgotten to add it once. So when I am correctly using the universal binary build of Python 2.4.3 (not 2.4.1, as Bob pointed out; sorry, I'm juggling too many things today), is it necessary to set AUTO_UNIVERSAL = 1 in PyObjC's setup.py? Mike From bob at redivi.com Mon Jun 5 21:26:49 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 5 Jun 2006 12:26:49 -0700 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <44848434.4030305@hotmail.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> <44847B09.9070504@hotmail.com> <17ABDA8D-CCD3-4B1B-8D82-6D9A6C542E22@mac.com> <44848434.4030305@hotmail.com> Message-ID: <1F8B15DE-7B1E-49D8-A6F7-587D72808A5D@redivi.com> On Jun 5, 2006, at 12:21 PM, Michael Glassford wrote: > Ronald Oussoren wrote: >> On 5-jun-2006, at 20:42, Michael Glassford wrote: >> >>> Ronald Oussoren wrote: >>>> On 2-jun-2006, at 22:39, Michael Glassford wrote: >>>>> This seems to have worked for me. I'm now getting another error >>>>> (at the end of this message). I haven't had time to look at it >>>>> yet because of other things that came up today, so it may be >>>>> something simple. >>>> This looks like PyObjC being build for PPC being used on Intel, >>>> that is the architecture for which PyObjC is build doesn't match >>>> the architecture of the currently running interpreter. The easiest >>>> way to fix this is probably to build a universal binary of PyObjC, >>>> there's an AUTO_UNIVERSAL option at the top of setup.py that >>>> enables building a universal binary with Apple's distribution of >>>> Python 2.3. >>> I'm not using Apple's distribution of Python 2.3, so I didn't think >>> this was necessary (I'm using 2.4.1 from from http://pythonmac.org/ >>> packages/py24-fat/). However, doing this fixed the problem and the >>> application now works. >> >> Ehmm, you are NOT using Python 2.4. Look at the error message in your >> original e-mail, this mentions /System/Library/Python.framework/ >> Versions/2.3/..... > > Well, you're right about that; apparently I wasn't using it there. > However, I am using it most of the time, including earlier today > when I > said I got it working (I've verified that). What must have happened is > this: /usr/local/bin isn't permanently added to the beginning of my > PATH > because most of the real work I'm doing requires Python 2.3; instead, > when I want to work on the universal binary build, I open a new > Terminal > window and add it manually. I must have forgotten to add it once. Out of curiosity, what are you doing that requires 2.3? > So when I am correctly using the universal binary build of Python > 2.4.3 > (not 2.4.1, as Bob pointed out; sorry, I'm juggling too many things > today), is it necessary to set AUTO_UNIVERSAL = 1 in PyObjC's > setup.py? It's not necessary to set it if you're using a universal build of Python. It's effectively just a hack to get PyObjC (and only PyObjC) to build universally with Apple's Python 2.3. -bob From h.goebel at goebel-consult.de Mon Jun 5 21:48:41 2006 From: h.goebel at goebel-consult.de (Hartmut Goebel) Date: Mon, 05 Jun 2006 21:48:41 +0200 Subject: [Pythonmac-SIG] Best way to use CoreGraphics In-Reply-To: <4E95D230-CF0A-4B9B-B56F-DC7C594F4F28@mac.com> References: <4483FDB2.7030003@goebel-consult.de> <4E95D230-CF0A-4B9B-B56F-DC7C594F4F28@mac.com> Message-ID: <44848A99.8050009@goebel-consult.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ronald Oussoren schrieb: >> That's definetly the one you shouldn't be using ;-) [...] >> That's not an open-source library, hence porting is not possible. [...] >> That doesn't work either, CoreGraphics isn't an ObjC library. I'm Urgs, no good news :-( But at least some clearance :-) >> Someone posted a message about bindings using Pyrex a while back. You >> should be able to find information about it in the list archives. I've found https://www.enthought.com/enthought/browser/trunk/src/lib/enthought/kiva/mac and will try it. - -- Sch?nen Gru? - Regards Hartmut Goebel | Hartmut Goebel | IT-Security -- effizient | | h.goebel at goebel-consult.de | www.goebel-consult.de | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iQEVAwUBRISKmczajR0mSa83AQIRmwf/U+k7dIdFzYfXljqzgwliD+VVVE36JXJf GlF1+/EHnuCY0FmHEMPAatlN5h+FD+dbeMtWXPSrYHBXne+2liUtTugZ52l/Dzkg E7T7xd6N2fNrQPjHuI27MgVuQrF0CE1HwLG6hPOYf4An/wxekViCQ9LmAdEIN1OC jxV6hGqVB99h7jZ2qZTkjgFMK64Gxe26A8kyj8JMzaXPaS791qYbGIAvMrE+ECzv EtWYMlIBzvEXPTSyhHuvIJwzodlM8Gcdkrjv0uaba32ZXqGacmks/EuEvyMo4533 rhnpnrfAUog52pa6Op+Up62aiV9rAnBRLSW5zJn1WJaDT83l5k2Vgw== =Tf8K -----END PGP SIGNATURE----- From glassfordm at gmail.com Mon Jun 5 22:05:49 2006 From: glassfordm at gmail.com (Michael Glassford) Date: Mon, 05 Jun 2006 16:05:49 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <1F8B15DE-7B1E-49D8-A6F7-587D72808A5D@redivi.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> <44847B09.9070504@hotmail.com> <17ABDA8D-CCD3-4B1B-8D82-6D9A6C542E22@mac.com> <44848434.4030305@hotmail.com> <1F8B15DE-7B1E-49D8-A6F7-587D72808A5D@redivi.com> Message-ID: <44848E9D.9030906@hotmail.com> Bob Ippolito wrote: > On Jun 5, 2006, at 12:21 PM, Michael Glassford wrote: [snip] >> Well, you're right about that; apparently I wasn't using it there. >> However, I am using it most of the time, including earlier today >> when I >> said I got it working (I've verified that). What must have happened is >> this: /usr/local/bin isn't permanently added to the beginning of my >> PATH >> because most of the real work I'm doing requires Python 2.3; instead, >> when I want to work on the universal binary build, I open a new >> Terminal >> window and add it manually. I must have forgotten to add it once. > > Out of curiosity, what are you doing that requires 2.3? There's nothing in the code that requires Python 2.3, it was a policy requirement: we've been officially using 2.3 because that's what we started with, there was never a compelling reason to move to 2.4, and we wanted to avoid code compatibility problems that could result if some developers were using 2.3 and some were using 2.4. We will likely be moving to 2.4 soon to use the universal binary versions of Python and PyObjC now that they appear to be stabilizing. >> So when I am correctly using the universal binary build of Python >> 2.4.3 >> (not 2.4.1, as Bob pointed out; sorry, I'm juggling too many things >> today), is it necessary to set AUTO_UNIVERSAL = 1 in PyObjC's >> setup.py? > > It's not necessary to set it if you're using a universal build of > Python. It's effectively just a hack to get PyObjC (and only PyObjC) > to build universally with Apple's Python 2.3. OK, thanks. I thought I had read that somewhere but wasn't sure. Mike From glassfordm at hotmail.com Mon Jun 5 22:05:49 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Mon, 05 Jun 2006 16:05:49 -0400 Subject: [Pythonmac-SIG] PyObjC/Py2App build problem In-Reply-To: <1F8B15DE-7B1E-49D8-A6F7-587D72808A5D@redivi.com> References: <6119DCA1-ADCA-4540-9898-BD60B37227EF@mac.com> <447F84A4.6050106@hotmail.com> <9682357.1149230106037.JavaMail.ronaldoussoren@mac.com> <4480A1F0.3070800@hotmail.com> <8759F69F-E092-4D55-8D7C-DFCEB16DE415@mac.com> <44847B09.9070504@hotmail.com> <17ABDA8D-CCD3-4B1B-8D82-6D9A6C542E22@mac.com> <44848434.4030305@hotmail.com> <1F8B15DE-7B1E-49D8-A6F7-587D72808A5D@redivi.com> Message-ID: <44848E9D.9030906@hotmail.com> Bob Ippolito wrote: > On Jun 5, 2006, at 12:21 PM, Michael Glassford wrote: [snip] >> Well, you're right about that; apparently I wasn't using it there. >> However, I am using it most of the time, including earlier today >> when I >> said I got it working (I've verified that). What must have happened is >> this: /usr/local/bin isn't permanently added to the beginning of my >> PATH >> because most of the real work I'm doing requires Python 2.3; instead, >> when I want to work on the universal binary build, I open a new >> Terminal >> window and add it manually. I must have forgotten to add it once. > > Out of curiosity, what are you doing that requires 2.3? There's nothing in the code that requires Python 2.3, it was a policy requirement: we've been officially using 2.3 because that's what we started with, there was never a compelling reason to move to 2.4, and we wanted to avoid code compatibility problems that could result if some developers were using 2.3 and some were using 2.4. We will likely be moving to 2.4 soon to use the universal binary versions of Python and PyObjC now that they appear to be stabilizing. >> So when I am correctly using the universal binary build of Python >> 2.4.3 >> (not 2.4.1, as Bob pointed out; sorry, I'm juggling too many things >> today), is it necessary to set AUTO_UNIVERSAL = 1 in PyObjC's >> setup.py? > > It's not necessary to set it if you're using a universal build of > Python. It's effectively just a hack to get PyObjC (and only PyObjC) > to build universally with Apple's Python 2.3. OK, thanks. I thought I had read that somewhere but wasn't sure. Mike From rowen at cesmail.net Tue Jun 6 01:56:41 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Mon, 05 Jun 2006 16:56:41 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python Message-ID: When using py2app to create an application, is there a simple way to get the path to the copy of python that is/will be bundled into the application? (I need this to copy in some matploblit data files) So far I'm generating it manually using some assumptions. it works but if there's a safer/easier way, I'd rather use that. -- Russell From bob at redivi.com Tue Jun 6 02:06:57 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 5 Jun 2006 17:06:57 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: Message-ID: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> On Jun 5, 2006, at 4:56 PM, Russell E. Owen wrote: > When using py2app to create an application, is there a simple way > to get > the path to the copy of python that is/will be bundled into the > application? > > (I need this to copy in some matploblit data files) > So far I'm generating it manually using some assumptions. it works but > if there's a safer/easier way, I'd rather use that. I don't know how matplotlib is structured, but you might want to look at writing a recipe for it. The pygame and PyOpenGL examples show how to include a few data files or an entire package as-is. -bob From Chris.Barker at noaa.gov Tue Jun 6 18:17:17 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 06 Jun 2006 09:17:17 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: Message-ID: <4485AA8D.3040001@noaa.gov> Russell E. Owen wrote: > When using py2app to create an application, is there a simple way to get > the path to the copy of python that is/will be bundled into the > application? > > (I need this to copy in some matploblit data files) I'm pretty sure there is a standard place in an App bundle that data files are supposed to go. It would be nice to use that place, and point MPL to it, rather than using a path relative to the python interpreter. With any luck, we could get the same approach to work with py2exe also. Both py2app and py2exe use set a "frozen" attribute in the sys module, so you can detect at runtime it you're running inside a bundle: http://pythonmac.org/wiki/FAQ#head-fda52eabc4c64a21d7044d62a49319a7c85faca9 -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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 bob at redivi.com Tue Jun 6 18:31:05 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 6 Jun 2006 09:31:05 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> Message-ID: <22031051-A810-48C2-8151-C06B0F99B4DE@redivi.com> On Jun 6, 2006, at 9:13 AM, Russell E Owen wrote: > At 5:06 PM -0700 2006-06-05, Bob Ippolito wrote: >> On Jun 5, 2006, at 4:56 PM, Russell E. Owen wrote: >> >>> When using py2app to create an application, is there a simple way >>> to get >>> the path to the copy of python that is/will be bundled into the >>> application? >>> >>> (I need this to copy in some matploblit data files) >>> So far I'm generating it manually using some assumptions. it >>> works but >>> if there's a safer/easier way, I'd rather use that. >> >> I don't know how matplotlib is structured, but you might want to >> look at writing a recipe for it. The pygame and PyOpenGL examples >> show how to include a few data files or an entire package as-is. > > That is a great idea. I'll take a look at creating such a recipe. > > Meanwhile...is there a simple way to get the path to the python > framework that is within the bundled application? I'm not entirely sure what that means, but probably not.. I think the frameworks get copied after all of the install phases have been run. > Also, one comment that may or may not be be relevant (since I've > not looked at the recipes yet): the right place for the matplotlib > data files is deep in the included python framework but... Technically the correct answer to that is probably sys.prefix/share/ matplotlib or something.. "deep in the framework" doesn't really mean anything to anyone. -bob From glassfordm at hotmail.com Tue Jun 6 18:33:15 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Tue, 06 Jun 2006 12:33:15 -0400 Subject: [Pythonmac-SIG] A couple of universal binary questions Message-ID: Is it possible to build a universal binary version of a Py2App/PyObjC based application that runs on pre-Tiger Macs? I assume this would require doing the build on a non-Intel Mac, since you generally have to build it on the earliest system version you want to run it on to get the right Foundation and AppKit. If so, could you point me to more information on how this is done? What's the right way to detect within the application whether its running on an Intel or a PowerPC Mac? I can figure out a way on my own (such as looking at sys.byteorder), but I wonder if there's an "official" way. Thanks, Mike From bob at redivi.com Tue Jun 6 18:44:00 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 6 Jun 2006 09:44:00 -0700 Subject: [Pythonmac-SIG] A couple of universal binary questions In-Reply-To: References: Message-ID: On Jun 6, 2006, at 9:33 AM, Michael Glassford wrote: > Is it possible to build a universal binary version of a Py2App/PyObjC > based application that runs on pre-Tiger Macs? I assume this would > require doing the build on a non-Intel Mac, since you generally > have to > build it on the earliest system version you want to run it on to > get the > right Foundation and AppKit. If so, could you point me to more > information on how this is done? All of it works with 10.3.9 out of the box. Anything else is unsupported and requires using gcc-3.3 for the PowerPC side and gcc-4.0 for the Intel side. Non-trivial. > What's the right way to detect within the application whether its > running on an Intel or a PowerPC Mac? I can figure out a way on my own > (such as looking at sys.byteorder), but I wonder if there's an > "official" way. The right way to detect is to not detect at all. Otherwise, it depends on what reason you're doing it. I'd probably use platform.processor(), which returns 'i386' or 'powerpc'.. but it returns 'powerpc' for ppc64 as well, so you might also want to check platform.architecture()[0] to be safe. You could probably also do these with sysctl. -bob From ronaldoussoren at mac.com Tue Jun 6 18:44:24 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 6 Jun 2006 18:44:24 +0200 Subject: [Pythonmac-SIG] A couple of universal binary questions In-Reply-To: References: Message-ID: On 6-jun-2006, at 18:33, Michael Glassford wrote: > Is it possible to build a universal binary version of a Py2App/PyObjC > based application that runs on pre-Tiger Macs? I assume this would > require doing the build on a non-Intel Mac, since you generally > have to > build it on the earliest system version you want to run it on to > get the > right Foundation and AppKit. If so, could you point me to more > information on how this is done? The universal build runs on 10.3.9 or later. With some luck it might run on earlier 10.3 versions as well, I haven't tested that. If you want to run on earlier versions (10.3.8, 10.2) you're basically on your own because the strategy used by the universal build won't work then. You'll have to use the strategy that is described by Apple on ADC: build a powerpc version using GCC, probably on the earliest version of OSX that you want to support and build the intel version on an intel mac using GCC 4. Then use lipo to paste the ppc and intel versions of binaries together. You don't really have build on the earliest version of OSX that you want to support, at least not if you're very careful and know what you're doing. That's why there are SDK's that you can install with Xcode. > > What's the right way to detect within the application whether its > running on an Intel or a PowerPC Mac? I can figure out a way on my own > (such as looking at sys.byteorder), but I wonder if there's an > "official" way. Why do you want to know? It's generally better to write your code in such way that you don't have to care. But if you really want to know: platform.mac_ver()[-1] is the architecture. Ronald > > > Thanks, > > Mike > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From glassfordm at hotmail.com Tue Jun 6 18:56:45 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Tue, 06 Jun 2006 12:56:45 -0400 Subject: [Pythonmac-SIG] A couple of universal binary questions In-Reply-To: References: Message-ID: Bob Ippolito wrote: > On Jun 6, 2006, at 9:33 AM, Michael Glassford wrote: > >> Is it possible to build a universal binary version of a Py2App/PyObjC >> based application that runs on pre-Tiger Macs? I assume this would >> require doing the build on a non-Intel Mac, since you generally >> have to >> build it on the earliest system version you want to run it on to >> get the >> right Foundation and AppKit. If so, could you point me to more >> information on how this is done? > > All of it works with 10.3.9 out of the box. Anything else is > unsupported and requires using gcc-3.3 for the PowerPC side and > gcc-4.0 for the Intel side. Non-trivial. OK, thanks. That's what I needed to know. >> What's the right way to detect within the application whether its >> running on an Intel or a PowerPC Mac? I can figure out a way on my own >> (such as looking at sys.byteorder), but I wonder if there's an >> "official" way. > > The right way to detect is to not detect at all. I realize that's generally preferable, but... > Otherwise, it depends on what reason you're doing it. I'm experimenting with getting Psyco working in the application, and obviously only want to enable it if I'm running on an Intel machine. It may turn out to do this check on its own; at the moment I can't tell, because enabling it automatically crashes my application on both Intel and PowerPC Macs. > I'd probably > use platform.processor(), which returns 'i386' or 'powerpc'.. but it > returns 'powerpc' for ppc64 as well, so you might also want to check > platform.architecture()[0] to be safe. You could probably also do > these with sysctl. In addition to these methods, I discovered that Pysco's setup.py has this: class ProcessorAutodetectError(Exception): pass def autodetect(): platform = sys.platform.lower() if platform.startswith('win'): # assume an Intel Windows return 'i386' # assume we have 'uname' mach = os.popen('uname -m', 'r').read().strip() if not mach: raise ProcessorAutodetectError, "cannot run 'uname -m'" try: return {'i386': 'i386', 'i486': 'i386', 'i586': 'i386', 'i686': 'i386', 'i86pc': 'i386', # Solaris/Intel 'x86': 'i386', # Apple }[mach] except KeyError: raise ProcessorAutodetectError, "unsupported processor '%s'" % mach Thanks, Mike From glassfordm at hotmail.com Tue Jun 6 19:01:52 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Tue, 06 Jun 2006 13:01:52 -0400 Subject: [Pythonmac-SIG] A couple of universal binary questions In-Reply-To: References: Message-ID: Ronald Oussoren wrote: > On 6-jun-2006, at 18:33, Michael Glassford wrote: > >> Is it possible to build a universal binary version of a Py2App/PyObjC >> based application that runs on pre-Tiger Macs? I assume this would >> require doing the build on a non-Intel Mac, since you generally >> have to >> build it on the earliest system version you want to run it on to >> get the >> right Foundation and AppKit. If so, could you point me to more >> information on how this is done? > > > The universal build runs on 10.3.9 or later. With some luck it might > run on earlier 10.3 versions as well, I haven't tested that. If you > want to run on earlier versions (10.3.8, 10.2) you're basically on > your own because the strategy used by the universal build won't work > then. You'll have to use the strategy that is described by Apple on > ADC: build a powerpc version using GCC, probably on the earliest > version of OSX that you want to support and build the intel version > on an intel mac using GCC 4. Then use lipo to paste the ppc and intel > versions of binaries together. Probably too much work to be worth it for my application, but knowing that's the case is useful information. > You don't really have build on the earliest version of OSX that you > want to support, at least not if you're very careful and know what > you're doing. That's why there are SDK's that you can install with > Xcode. > >> What's the right way to detect within the application whether its >> running on an Intel or a PowerPC Mac? I can figure out a way on my own >> (such as looking at sys.byteorder), but I wonder if there's an >> "official" way. > > Why do you want to know? > It's generally better to write your code in > such way that you don't have to care. Answered in my reply to Bob. > But if you really want to > know: platform.mac_ver()[-1] is the architecture. Thanks. Mike From ronaldoussoren at mac.com Tue Jun 6 19:08:13 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 6 Jun 2006 19:08:13 +0200 Subject: [Pythonmac-SIG] A couple of universal binary questions In-Reply-To: References: Message-ID: On 6-jun-2006, at 18:56, Michael Glassford wrote: > >>> What's the right way to detect within the application whether its >>> running on an Intel or a PowerPC Mac? I can figure out a way on >>> my own >>> (such as looking at sys.byteorder), but I wonder if there's an >>> "official" way. >> >> The right way to detect is to not detect at all. > > I realize that's generally preferable, but... > >> Otherwise, it depends on what reason you're doing it. > > I'm experimenting with getting Psyco working in the application, and > obviously only want to enable it if I'm running on an Intel > machine. It > may turn out to do this check on its own; at the moment I can't tell, > because enabling it automatically crashes my application on both Intel > and PowerPC Macs. Even here I wouldn't test for the architecture but would just import psyco and act on the success or failure of that. Ronald From bob at redivi.com Tue Jun 6 19:35:06 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 6 Jun 2006 10:35:06 -0700 Subject: [Pythonmac-SIG] A couple of universal binary questions In-Reply-To: References: Message-ID: <202C31D8-07CF-4CB9-B174-7DB78A5FAB7B@redivi.com> On Jun 6, 2006, at 9:56 AM, Michael Glassford wrote: > Bob Ippolito wrote: > >>> What's the right way to detect within the application whether its >>> running on an Intel or a PowerPC Mac? I can figure out a way on >>> my own >>> (such as looking at sys.byteorder), but I wonder if there's an >>> "official" way. >> >> The right way to detect is to not detect at all. > > I realize that's generally preferable, but... > >> Otherwise, it depends on what reason you're doing it. > > I'm experimenting with getting Psyco working in the application, and > obviously only want to enable it if I'm running on an Intel > machine. It > may turn out to do this check on its own; at the moment I can't tell, > because enabling it automatically crashes my application on both Intel > and PowerPC Macs. psyco doesn't quite work on Mac OS X i386. I think it's because Mac OS X requires a 16 byte stack alignment, and other i386 platforms expect much less (4 I think) so psyco ends up misaligning the stack on some function calls and ends up crashing somewhat non- deterministically. It didn't look very easy to fix, there's a lot of gnarly code in psyco... someone would more or less have to ask Armin how to fix it. psyco's ivm backend should work on both if it works at all, but I'm not sure how stable it is or how much of a performance boost it's going to get, and I don't think it's ever really seen any real-world use. Note that it'd be possible to simply change psyco a bit make the PPC part of psyco compile to a binary that raises ImportError.. which would alleviate any need to do platform detection. -bob From cookedm at physics.mcmaster.ca Tue Jun 6 20:38:18 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Tue, 6 Jun 2006 14:38:18 -0400 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: Message-ID: <20060606143818.2412fe86@arbutus.physics.mcmaster.ca> On Mon, 05 Jun 2006 16:56:41 -0700 "Russell E. Owen" wrote: > When using py2app to create an application, is there a simple way to > get the path to the copy of python that is/will be bundled into the > application? > > (I need this to copy in some matploblit data files) > So far I'm generating it manually using some assumptions. it works > but if there's a safer/easier way, I'd rather use that. Which version of matplotlib are you using? Latest versions put the data files inside the matplotlib package (as opposed to a /share/ directory), so it finds them relative to itself using __file__. That wouldn't require knowing where python itself is. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From bob at redivi.com Tue Jun 6 21:44:11 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 6 Jun 2006 12:44:11 -0700 Subject: [Pythonmac-SIG] psyco and Mac OS X i386 In-Reply-To: <202C31D8-07CF-4CB9-B174-7DB78A5FAB7B@redivi.com> References: <202C31D8-07CF-4CB9-B174-7DB78A5FAB7B@redivi.com> Message-ID: <8526D00F-66FC-4178-8B7B-69AE1D421D67@redivi.com> On Jun 6, 2006, at 10:35 AM, Bob Ippolito wrote: > > On Jun 6, 2006, at 9:56 AM, Michael Glassford wrote: > >> Bob Ippolito wrote: >> >>>> What's the right way to detect within the application whether its >>>> running on an Intel or a PowerPC Mac? I can figure out a way on >>>> my own >>>> (such as looking at sys.byteorder), but I wonder if there's an >>>> "official" way. >>> >>> The right way to detect is to not detect at all. >> >> I realize that's generally preferable, but... >> >>> Otherwise, it depends on what reason you're doing it. >> >> I'm experimenting with getting Psyco working in the application, and >> obviously only want to enable it if I'm running on an Intel >> machine. It >> may turn out to do this check on its own; at the moment I can't tell, >> because enabling it automatically crashes my application on both >> Intel >> and PowerPC Macs. > > psyco doesn't quite work on Mac OS X i386. I think it's because Mac > OS X requires a 16 byte stack alignment, and other i386 platforms > expect much less (4 I think) so psyco ends up misaligning the stack > on some function calls and ends up crashing somewhat non- > deterministically. It didn't look very easy to fix, there's a lot of > gnarly code in psyco... someone would more or less have to ask Armin > how to fix it. > > psyco's ivm backend should work on both if it works at all, but I'm > not sure how stable it is or how much of a performance boost it's > going to get, and I don't think it's ever really seen any real-world > use. > > Note that it'd be possible to simply change psyco a bit make the PPC > part of psyco compile to a binary that raises ImportError.. which > would alleviate any need to do platform detection. I went through and confirmed that indeed the stack alignment is the reason why psyco doesn't function properly on Mac OS X i386. You can confirm this by running the bpnn.py example under gdb. You'll eventually get an Illegal Instruction (GP(0) exception) during the call to the libSystem version of pow(). The reason for this is that pow() uses a SSE2 instruction that requires 16 byte alignment (specifically, "movapd %xmm1,-104(%ebp)") and the way that psyco set up the stack does not make it so. I can't really commit any more time to fixing this right now, but Armin has said that: arigo: let me see, you need to hack in c/i386/iencoding.h arigo: CALL_SET_ARG_* macros arigo: and CALL_C_FUNCTION* arigo: or maybe better yet, add a new macro CALL_ALIGN_STACK(nb_args) arigo: which should be called before any of the CALL_SET_ARG The IA-32 calling conventions for Mac OS X are documented here: http://developer.apple.com/documentation/DeveloperTools/Conceptual/ LowLevelABI/Articles/IA32.html And you'll probably also want to look at the disassembly (otool -tVv is good for this, or just gcc -S) of a trivial C program or two to get an idea of what it looks like in practice. -bob From glassfordm at hotmail.com Tue Jun 6 22:27:04 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Tue, 06 Jun 2006 16:27:04 -0400 Subject: [Pythonmac-SIG] psyco and Mac OS X i386 In-Reply-To: <8526D00F-66FC-4178-8B7B-69AE1D421D67@redivi.com> References: <202C31D8-07CF-4CB9-B174-7DB78A5FAB7B@redivi.com> <8526D00F-66FC-4178-8B7B-69AE1D421D67@redivi.com> Message-ID: Bob Ippolito wrote: [snip] > I went through and confirmed that indeed the stack alignment is the > reason why psyco doesn't function properly on Mac OS X i386. You can > confirm this by running the bpnn.py example under gdb. You'll > eventually get an Illegal Instruction (GP(0) exception) during the > call to the libSystem version of pow(). The reason for this is that > pow() uses a SSE2 instruction that requires 16 byte alignment > (specifically, "movapd %xmm1,-104(%ebp)") and the way that psyco set > up the stack does not make it so. > > I can't really commit any more time to fixing this right now, but > Armin has said that: > > arigo: let me see, you need to hack in c/i386/iencoding.h > arigo: CALL_SET_ARG_* macros > arigo: and CALL_C_FUNCTION* > arigo: or maybe better yet, add a new macro CALL_ALIGN_STACK(nb_args) > arigo: which should be called before any of the CALL_SET_ARG > > The IA-32 calling conventions for Mac OS X are documented here: > http://developer.apple.com/documentation/DeveloperTools/Conceptual/ > LowLevelABI/Articles/IA32.html > > And you'll probably also want to look at the disassembly (otool -tVv > is good for this, or just gcc -S) of a trivial C program or two to > get an idea of what it looks like in practice. OK, thanks. I was just trying it out because http://mail.python.org/pipermail/pythonmac-sig/2006-April/017153.html seemed to indicate that it might "just work". Apparently that's not the case, and I don't think I have the time right now to do what it sound like would be necessary. Maybe a project for another day. Mike From ronaldoussoren at mac.com Tue Jun 6 22:34:59 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 6 Jun 2006 22:34:59 +0200 Subject: [Pythonmac-SIG] psyco and Mac OS X i386 In-Reply-To: <8526D00F-66FC-4178-8B7B-69AE1D421D67@redivi.com> References: <202C31D8-07CF-4CB9-B174-7DB78A5FAB7B@redivi.com> <8526D00F-66FC-4178-8B7B-69AE1D421D67@redivi.com> Message-ID: On 6-jun-2006, at 21:44, Bob Ippolito wrote: > > The IA-32 calling conventions for Mac OS X are documented here: > http://developer.apple.com/documentation/DeveloperTools/Conceptual/ > LowLevelABI/Articles/IA32.html > > And you'll probably also want to look at the disassembly (otool -tVv > is good for this, or just gcc -S) of a trivial C program or two to > get an idea of what it looks like in practice. And if you prefer to decode hairy C code you could look at libffi (both the version in python-trunk and that in PyObjC support darwin/ x86) ;-) Ronald > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From saggau at gmail.com Wed Jun 7 09:08:42 2006 From: saggau at gmail.com (Jonathan Saggau) Date: Wed, 7 Jun 2006 03:08:42 -0400 Subject: [Pythonmac-SIG] pyobjc objs is subclasses of them python objs Message-ID: To paraphrase the movie "Groundhog Day:" Don't blog angry. Especially when it's your own code that usually sucks. I don't know how he finds the time, but the python / mac community owes Bobseveral rounds of applause. Let me be the first to stand (soon as I get this here foot outta mah mouth). I'm also wowed at how he managed to find my blog and comment before I got round to sending a question to the mailing lists. And ... well you know... he kicked my butt and I deserved it. Apologies and thanks to Bob. Cheers, Jonathan Saggau http://jonathansaggau.com/blog/ This amusement engaged me so much that [friends] were obliged to force me from it; and thus it is with every inclination I give into, it continues to augment, till at length it becomes so powerful, that I lose sight of everything except the favorite amusement. - Rousseau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060607/f76a445e/attachment.htm From rowen at u.washington.edu Tue Jun 6 18:13:46 2006 From: rowen at u.washington.edu (Russell E Owen) Date: Tue, 6 Jun 2006 09:13:46 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> References: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> Message-ID: At 5:06 PM -0700 2006-06-05, Bob Ippolito wrote: >On Jun 5, 2006, at 4:56 PM, Russell E. Owen wrote: > >>When using py2app to create an application, is there a simple way to get >>the path to the copy of python that is/will be bundled into the >>application? >> >>(I need this to copy in some matploblit data files) >>So far I'm generating it manually using some assumptions. it works but >>if there's a safer/easier way, I'd rather use that. > >I don't know how matplotlib is structured, but you might want to >look at writing a recipe for it. The pygame and PyOpenGL examples >show how to include a few data files or an entire package as-is. That is a great idea. I'll take a look at creating such a recipe. Meanwhile...is there a simple way to get the path to the python framework that is within the bundled application? Also, one comment that may or may not be be relevant (since I've not looked at the recipes yet): the right place for the matplotlib data files is deep in the included python framework but... I found (the hard way) that specifying data files that belong in the tcl/tk framework (tcl extension libraries) fails miserably because those files are copied *before* the tcl/tk framework, and in the process a directory structure is created that blocks proper copying of tcl/tk. (The root of the problem is my use of the link "Resources" as a shortcut for the full path -- by copying files before that link is created, it is created as a folder instead of a link). I can probably dodge the problem by not using links in the path. Indeed, py2app doesn't seem to copy those handy shortcut links for the python framework. -- Russell From ronaldoussoren at mac.com Wed Jun 7 11:26:10 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 07 Jun 2006 11:26:10 +0200 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> Message-ID: <14958240.1149672370929.JavaMail.ronaldoussoren@mac.com> On Wednesday, June 07, 2006, at 11:07AM, Russell E Owen wrote: >At 5:06 PM -0700 2006-06-05, Bob Ippolito wrote: >>On Jun 5, 2006, at 4:56 PM, Russell E. Owen wrote: >> >>>When using py2app to create an application, is there a simple way to get >>>the path to the copy of python that is/will be bundled into the >>>application? >>> >>>(I need this to copy in some matploblit data files) >>>So far I'm generating it manually using some assumptions. it works but >>>if there's a safer/easier way, I'd rather use that. >> >>I don't know how matplotlib is structured, but you might want to >>look at writing a recipe for it. The pygame and PyOpenGL examples >>show how to include a few data files or an entire package as-is. > >That is a great idea. I'll take a look at creating such a recipe. > >Meanwhile...is there a simple way to get the path to the python >framework that is within the bundled application? That's not really needed if matplotlib stores its datafiles in the same directory as its python files (that is in the package directory). In that case you can just explicitly include matplotlib (using the packages option). If that works you can create a recipe that does the same automaticly when a program depends on matplotlib. > > >Also, one comment that may or may not be be relevant (since I've not >looked at the recipes yet): the right place for the matplotlib data >files is deep in the included python framework but... That doesn't sound too good, do you mean the datafiles aren't in the package directory? > >I found (the hard way) that specifying data files that belong in the >tcl/tk framework (tcl extension libraries) fails miserably because >those files are copied *before* the tcl/tk framework, and in the >process a directory structure is created that blocks proper copying >of tcl/tk. (The root of the problem is my use of the link "Resources" >as a shortcut for the full path -- by copying files before that link >is created, it is created as a folder instead of a link). > >I can probably dodge the problem by not using links in the path. >Indeed, py2app doesn't seem to copy those handy shortcut links for >the python framework. What shortcut links? Py2app special-cases the python framework because we know how it is structured and know what parts must be copied into the application to get a working bundle. The tcl/tk framework is treated specially and that should mean the entire framework is copied verbatim. That again means that it shouldn't be necessary to specify that some additional datafiles in that framework should be copied because they'll be included anyway. Ronald From monsterkodi at gmx.net Wed Jun 7 13:06:34 2006 From: monsterkodi at gmx.net (Thorsten Kohnhorst) Date: Wed, 07 Jun 2006 13:06:34 +0200 Subject: [Pythonmac-SIG] pyobjc objs is subclasses of them python objs In-Reply-To: References: Message-ID: <4486B33A.1070400@gmx.net> Well, I am the second to stand up for another round of applause: Thanks a lot to Bob, Ronald and whoever else helped for this really, really great programming environment. Have a nice day, yours kodi From rowen at cesmail.net Wed Jun 7 18:24:52 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Wed, 07 Jun 2006 09:24:52 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python References: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> <14958240.1149672370929.JavaMail.ronaldoussoren@mac.com> Message-ID: In article <14958240.1149672370929.JavaMail.ronaldoussoren at mac.com>, Ronald Oussoren wrote: > > On Wednesday, June 07, 2006, at 11:07AM, Russell E Owen > wrote: > > >At 5:06 PM -0700 2006-06-05, Bob Ippolito wrote: > >>On Jun 5, 2006, at 4:56 PM, Russell E. Owen wrote: > >> > >>>When using py2app to create an application, is there a simple way to get > >>>the path to the copy of python that is/will be bundled into the > >>>application? > >>> > >>>(I need this to copy in some matploblit data files) > >>>So far I'm generating it manually using some assumptions. it works but > >>>if there's a safer/easier way, I'd rather use that. > >> > >>I don't know how matplotlib is structured, but you might want to > >>look at writing a recipe for it. The pygame and PyOpenGL examples > >>show how to include a few data files or an entire package as-is. > > > >That is a great idea. I'll take a look at creating such a recipe. > > > >Meanwhile...is there a simple way to get the path to the python > >framework that is within the bundled application? > > That's not really needed if matplotlib stores its datafiles in the same > directory as its python files (that is in the package directory). In that > case you can just explicitly include matplotlib (using the packages option). > If that works you can create a recipe that does the same automaticly when a > program depends on matplotlib. os.env["MATPLOTLIBDATA"] matplotlib 0.82 (which is somewhat outdated) looks here, in this order: .../Contents/Frameworks/Python.framework/Versions/2.4/share/matplotlib /usr/local/share/matplotlib /usr/share/matplotlib .../Contents/Resources/Python/site-packages/matplotlib/share/matplotlib .../Contents/share/matplotlib Although the last path is very convenient, by then matplotlib has looked in all sorts of places I don't want it to look -- I want it to find the packaged data files rather than any the user might have from possibly a different (and possibly incompatible) version of matplotlib. So I use the first path, which is a pain to construct -- hence my desire to ask py2app for the path. Apparently the current matplotlib is more sensible about where it puts its data files, so this may be moot. >... > What shortcut links? Py2app special-cases the python framework because we > know how it is structured and know what parts must be copied into the > application to get a working bundle. For Tcl/Tk, one may put extension libraries (such as snack) into: .../Contents/Framework/Tcl.Framework/Resources That works because Resources is a link. The full path (without links) is: .../Contents/Framework/Tcl/Framework/Versions/8.4/Resources which would you rather use, especially since the version number may change?!!! Unfortunately one cannot play a similar trick with python. The main installation of python has various useful shortcut links, but py2app doesn't copy them. > The tcl/tk framework is treated specially and that should mean the entire > framework is copied verbatim. That again means that it shouldn't be necessary > to specify that some additional datafiles in that framework should be copied > because they'll be included anyway. Tcl/Tk extensions are not auto-copied by py2app. Perhaps that is because they live in /Library/Tcl, rather than part of the tcl framework itself. On the whole I'm pleased because I have a ton of tcl extensions that I don't use (I use ActiveTcl -- it saves manually trying to install snack, which is a pain to build). But the flip side is that one has to figure out where to put tcl extensions in the bundled app. It's not documented anywhere that I could find, so I used trial and error. Also, the obvious-but-wrong thing to do is specify the extensions using the dataFiles argument with the correct final destination. That fails if one relies on the handy shortcut links because Tcl framework is copied *after* the data files. When the data files are copied, real directories are created instead of the necessary links, and that prevents the tcl framework from being properly copied. I really need to spend some time to document this publicly. But where? From rowen at cesmail.net Wed Jun 7 18:31:03 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Wed, 07 Jun 2006 09:31:03 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python References: <4485AA8D.3040001@noaa.gov> Message-ID: In article <4485AA8D.3040001 at noaa.gov>, Christopher Barker wrote: > Russell E. Owen wrote: > > When using py2app to create an application, is there a simple way to get > > the path to the copy of python that is/will be bundled into the > > application? > > > > (I need this to copy in some matploblit data files) > > I'm pretty sure there is a standard place in an App bundle that data > files are supposed to go. It would be nice to use that place, and point > MPL to it, rather than using a path relative to the python interpreter. > With any luck, we could get the same approach to work with py2exe also. > > Both py2app and py2exe use set a "frozen" attribute in the sys module, > so you can detect at runtime it you're running inside a bundle: > > http://pythonmac.org/wiki/FAQ#head-fda52eabc4c64a21d7044d62a49319a7c85faca9 matplotlib already uses this attribute for frozen Windows executables (by looking in a very convenient-and-obvious spot for the data files). However, it does not presently do that for Mac frozen apps. However, the current matplotlib uses saner search path for its data files, so it may be irrelevant. I will also note that freezing a windows exe that uses matplotlib is famously difficult. Ironically, the same is true for a Windows exe that uses the win32 package (a package used by many or most python programs on Windows). py2app is significantly smarter than py2exe about finding the necessary files. The only hassles on Mac are: - the need to copy the data files (not a big deal, especially, apparently, with newer matplotlibs that use smarter paths) - apparently the need to explicitly specify the FileDialog module (that one caught me off guard) - also, if one really wants to be safe, one should either delete os.env["MATPLOTLIBDATA"] or set it to the correct path. -- Russell From Chris.Barker at noaa.gov Wed Jun 7 20:23:22 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 07 Jun 2006 11:23:22 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> <14958240.1149672370929.JavaMail.ronaldoussoren@mac.com> Message-ID: <4487199A.6060808@noaa.gov> Russell E. Owen wrote: > Although the last path is very convenient, by then matplotlib has looked > in all sorts of places I don't want it to look -- Is there no way to tell matplotlib where to look? There should be, for just this reason. Personally, I'm not sure the matplotlibrc file is such a great idea anyway. I think perhaps a better approach would be to have sensible defaults, (which is does), and have the parameters all over-ridable (which I think they are), but NOT have it read an rc file be default, rather have the user specify one that they want read it, if they do: import matplotlib matplotlib.loadrcfile(PathToMyRCfile) In fact, nothing would have to change, all we'd need is to add the loadrcfile method. That is, if there is nothing set on import that can not be changed after import. Indeed, that method may already exist. I guess one of us should bring this up on the MPL list... -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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 Jun 7 21:26:40 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 7 Jun 2006 21:26:40 +0200 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> <14958240.1149672370929.JavaMail.ronaldoussoren@mac.com> Message-ID: <1AF62BC1-44E4-4698-AB72-A87DAFB4FB2C@mac.com> On 7-jun-2006, at 18:24, Russell E. Owen wrote: > >> ... >> What shortcut links? Py2app special-cases the python framework >> because we >> know how it is structured and know what parts must be copied into the >> application to get a working bundle. > > For Tcl/Tk, one may put extension libraries (such as snack) into: > .../Contents/Framework/Tcl.Framework/Resources > That works because Resources is a link. The full path (without > links) is: > .../Contents/Framework/Tcl/Framework/Versions/8.4/Resources > > which would you rather use, especially since the version number may > change?!!! > > Unfortunately one cannot play a similar trick with python. The main > installation of python has various useful shortcut links, but py2app > doesn't copy them. That's because the running application doesn't actually need the link. The easiest way out of this would be to check if a latest version of matplotlib behaves more sensibly, if it does we don't have to look for other ways to get this to work. Either way a recipe would be the best way to solve this: get this into py2app and no other user of matplotlib has to worry about this in the future. > >> The tcl/tk framework is treated specially and that should mean the >> entire >> framework is copied verbatim. That again means that it shouldn't >> be necessary >> to specify that some additional datafiles in that framework should >> be copied >> because they'll be included anyway. > > Tcl/Tk extensions are not auto-copied by py2app. Perhaps that is > because > they live in /Library/Tcl, rather than part of the tcl framework > itself. > On the whole I'm pleased because I have a ton of tcl extensions that I > don't use (I use ActiveTcl -- it saves manually trying to install > snack, > which is a pain to build). > > But the flip side is that one has to figure out where to put tcl > extensions in the bundled app. It's not documented anywhere that I > could > find, so I used trial and error. > > Also, the obvious-but-wrong thing to do is specify the extensions > using > the dataFiles argument with the correct final destination. That > fails if > one relies on the handy shortcut links because Tcl framework is copied > *after* the data files. When the data files are copied, real > directories > are created instead of the necessary links, and that prevents the tcl > framework from being properly copied. > > I really need to spend some time to document this publicly. But where? Do you have a python application that uses additional tcl/tk files? If so it might be worthwhile to teach py2app about this, that is an additional option to the 'py2app' distutils command that can be used to specify the Tcl/Tk extensions that should be copied into the framework. Bob has the last word on this of course, but I wouldn't mind if such functionality would get into py2app (and especially if I don't have to do the work ;-)) What is required to add Tcl/Tk extensions to the application bundle? Ronald > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Wed Jun 7 21:28:18 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 7 Jun 2006 21:28:18 +0200 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: <4485AA8D.3040001@noaa.gov> Message-ID: On 7-jun-2006, at 18:31, Russell E. Owen wrote: > > py2app is significantly smarter than py2exe about finding the > necessary > files. The only hassles on Mac are: > - the need to copy the data files (not a big deal, especially, > apparently, with newer matplotlibs that use smarter paths) > - apparently the need to explicitly specify the FileDialog module > (that > one caught me off guard) > - also, if one really wants to be safe, one should either delete > os.env["MATPLOTLIBDATA"] or set it to the correct path. To reiterate a point: all of these can be solved by a recipe ;-) ;-) ;-) Ronald From rowen at u.washington.edu Wed Jun 7 21:47:49 2006 From: rowen at u.washington.edu (Russell E Owen) Date: Wed, 7 Jun 2006 12:47:49 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: <1AF62BC1-44E4-4698-AB72-A87DAFB4FB2C@mac.com> References: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> <14958240.1149672370929.JavaMail.ronaldoussoren@mac.com> <1AF62BC1-44E4-4698-AB72-A87DAFB4FB2C@mac.com> Message-ID: At 9:26 PM +0200 2006-06-07, Ronald Oussoren wrote: >On 7-jun-2006, at 18:24, Russell E. Owen wrote: > >> >>>... >>>What shortcut links? Py2app special-cases the python framework because we >>>know how it is structured and know what parts must be copied into the >>>application to get a working bundle. >> >>For Tcl/Tk, one may put extension libraries (such as snack) into: >>.../Contents/Framework/Tcl.Framework/Resources >>That works because Resources is a link. The full path (without links) is: >>.../Contents/Framework/Tcl/Framework/Versions/8.4/Resources >> >>which would you rather use, especially since the version number may >>change?!!! >> >>Unfortunately one cannot play a similar trick with python. The main >>installation of python has various useful shortcut links, but py2app >>doesn't copy them. > >That's because the running application doesn't actually need the >link. The easiest way out of this would be to check if a latest >version of matplotlib behaves more sensibly, if it does we don't >have to look for other ways to get this to work. Either way a recipe >would be the best way to solve this: get this into py2app and no >other user of matplotlib has to worry about this in the future. I agree. >...Do you have a python application that uses additional tcl/tk >files? If so it might be worthwhile to teach py2app about this, that >is an additional option to the 'py2app' distutils command that can >be used to specify the Tcl/Tk extensions that should be copied into >the framework. Bob has the last word on this of course, but I >wouldn't mind if such functionality would get into py2app (and >especially if I don't have to do the work ;-)) Yes indeed. It uses the snack sound library (I wish there was a cross-platform python sound library I could use instead). But I'm sure other users of Tkinter have other extensions they like. >What is required to add Tcl/Tk extensions to the application bundle? Tcl additions are found in /Library/Tcl/ and are often folders of files. These need to be copied to: .../Contents/Frameworks/Tcl.framework/Resources I found it by asking tcl for the relevant path. As I recall, tcl only looks in one directory for extensions (though I hope I'm wrong; that seems hard to believe). I certainly tried to find a more convenient location, but no luck so far. As I mentioned before, if one uses the dataFiles argument, then one must not specify the final destination, as this messes up copying of Tcl.framework (due to a directory being created that should be a link). Instead, I first copy the files to a simple location and then move it. That issue *might* be avoided by specifying the full non-linked path to the destination, e.g.: .../Contents/Frameworks/Tcl/framework/Versions/8.4/Resources but that sounds painful. So built-in support would certainly be more convenient! -- Russell From ronaldoussoren at mac.com Wed Jun 7 22:14:29 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 7 Jun 2006 22:14:29 +0200 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: <4485AA8D.3040001@noaa.gov> Message-ID: <6D77BE22-238E-4084-B64D-D359094FEEA1@mac.com> On 7-jun-2006, at 21:54, Russell E Owen wrote: > At 9:28 PM +0200 2006-06-07, Ronald Oussoren wrote: >> On 7-jun-2006, at 18:31, Russell E. Owen wrote: >> >>> >>> py2app is significantly smarter than py2exe about finding the >>> necessary >>> files. The only hassles on Mac are: >>> - the need to copy the data files (not a big deal, especially, >>> apparently, with newer matplotlibs that use smarter paths) >>> - apparently the need to explicitly specify the FileDialog module >>> (that >>> one caught me off guard) >>> - also, if one really wants to be safe, one should either delete >>> os.env["MATPLOTLIBDATA"] or set it to the correct path. >> >> To reiterate a point: all of these can be solved by a >> recipe ;-) ;-) ;-) > > Yes. Once I can upgrade to the current matplotlib I'm looking > forward to trying to write that recipe. > > But...can dealing with os.env["MATPLOTLIBDATA"] really be part of > the recipe? I had assumed not. If it can, any hints on how to do it? You can do this using prescripts. The recipe for PIL uses one, although the one for matplatlib would be a lot easier. The recipe for matplatlib would be single module in py2app.recipes: matplotlib.py: # BOF from StringIO import StringIO def check(cmd, mf): m = mf.findNode('matplotlib') if m is None or m.filename is None: return None prescript = StringIO("""\ import os if 'MATPLOTLIBDATA' in os.environ: del os.environ['MATPLOTLIBDATA'] """) return dict( packages=['matplotlib'], # Include the entire package prescripts=[prescript], ) # EOF A word of warning, I typed this in mail.app and haven't actually used recipes before. Ronald > > -- Russell From rowen at u.washington.edu Wed Jun 7 21:54:33 2006 From: rowen at u.washington.edu (Russell E Owen) Date: Wed, 7 Jun 2006 12:54:33 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: <4485AA8D.3040001@noaa.gov> Message-ID: At 9:28 PM +0200 2006-06-07, Ronald Oussoren wrote: >On 7-jun-2006, at 18:31, Russell E. Owen wrote: > >> >>py2app is significantly smarter than py2exe about finding the necessary >>files. The only hassles on Mac are: >>- the need to copy the data files (not a big deal, especially, >>apparently, with newer matplotlibs that use smarter paths) >>- apparently the need to explicitly specify the FileDialog module (that >>one caught me off guard) >>- also, if one really wants to be safe, one should either delete >>os.env["MATPLOTLIBDATA"] or set it to the correct path. > >To reiterate a point: all of these can be solved by a recipe ;-) ;-) ;-) Yes. Once I can upgrade to the current matplotlib I'm looking forward to trying to write that recipe. But...can dealing with os.env["MATPLOTLIBDATA"] really be part of the recipe? I had assumed not. If it can, any hints on how to do it? -- Russell From jonathan at jonathansaggau.com Thu Jun 8 03:58:06 2006 From: jonathan at jonathansaggau.com (Jonathan) Date: Wed, 7 Jun 2006 21:58:06 -0400 Subject: [Pythonmac-SIG] py2app question: path to included python In-Reply-To: References: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> <14958240.1149672370929.JavaMail.ronaldoussoren@mac.com> <1AF62BC1-44E4-4698-AB72-A87DAFB4FB2C@mac.com> Message-ID: https://patrickkidd.com has wrappers for several audio libraries. Cheers, Jonathan Saggau jonathansaggau.com This amusement engaged me so much that [friends] were obliged to force me from it; and thus it is with every inclination I give into, it continues to augment, till at length it becomes so powerful, that I lose sight of everything except the favorite amusement. - Rousseau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060607/297188e0/attachment.htm From noah.gift at gmail.com Thu Jun 8 13:46:37 2006 From: noah.gift at gmail.com (Noah Gift) Date: Thu, 8 Jun 2006 07:46:37 -0400 Subject: [Pythonmac-SIG] python and quicktime Message-ID: Hi, I am new to python and was interested in writing some python code that converts image sequences, for example tiff, into Quicktime movies, for example animation codec. Can anyone point me in the right direction to begin my research? It would be nice to not use pyobjc as I am trying to focus on doing things in pure python for now as a learning excercise. Thanks, Noah Gift -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060608/79656e8d/attachment.html From kent_quirk at cognitoy.com Thu Jun 8 16:24:29 2006 From: kent_quirk at cognitoy.com (Kent Quirk) Date: Thu, 08 Jun 2006 10:24:29 -0400 Subject: [Pythonmac-SIG] python and quicktime In-Reply-To: References: Message-ID: <4488331D.3060001@cognitoy.com> Noah Gift wrote: > I am new to python and was interested in writing some python code that > converts image sequences, for example tiff, into Quicktime movies, for > example animation codec. Can anyone point me in the right direction > to begin my research? It would be nice to not use pyobjc as I am > trying to focus on doing things in pure python for now as a learning > excercise. > Well, having solved a similar problem last year (making quicktime animations from a sequence of screenshots), I can testify that: a) It's not easy. Quicktime doesn't make this problem simple or document it very well. In fact, at last year's WWDC, a guy from Pixar gave a talk about building a storyboarding tool and along the way ranted about how hard it was (and didn't need to be). I suppose it's possible that they've improved the documentation since then. b) It's probably not possible with "pure" python. The file formats are neither documented nor trivial, so you're not going to just write the bits out to files. And as far as I know, there's no prewritten Pythonic wrapper for Quicktime -- other than going through PyObjC. If you really don't want PyObjC, I think your remaining choice is to build a C++ plugin for Python that makes the appropriate Quicktime calls (which is what we did -- but we already had a C++ framework we were using). I wish I could help you with source code, but I'm no longer associated with that project. Kent From ronaldoussoren at mac.com Thu Jun 8 18:11:59 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 8 Jun 2006 18:11:59 +0200 Subject: [Pythonmac-SIG] python and quicktime In-Reply-To: <4488331D.3060001@cognitoy.com> References: <4488331D.3060001@cognitoy.com> Message-ID: <4F84430E-D521-42CE-AADB-1FC1F00C7454@mac.com> On 8-jun-2006, at 16:24, Kent Quirk wrote: > Noah Gift wrote: >> I am new to python and was interested in writing some python code >> that >> converts image sequences, for example tiff, into Quicktime movies, >> for >> example animation codec. Can anyone point me in the right direction >> to begin my research? It would be nice to not use pyobjc as I am >> trying to focus on doing things in pure python for now as a learning >> excercise. >> > > Well, having solved a similar problem last year (making quicktime > animations from a sequence of screenshots), I can testify that: > > a) It's not easy. Quicktime doesn't make this problem simple or > document > it very well. In fact, at last year's WWDC, a guy from Pixar gave a > talk > about building a storyboarding tool and along the way ranted about how > hard it was (and didn't need to be). I suppose it's possible that > they've improved the documentation since then. > > b) It's probably not possible with "pure" python. The file formats are > neither documented nor trivial, so you're not going to just write the > bits out to files. And as far as I know, there's no prewritten > Pythonic > wrapper for Quicktime -- other than going through PyObjC. If you > really > don't want PyObjC, I think your remaining choice is to build a C++ > plugin for Python that makes the appropriate Quicktime calls (which is > what we did -- but we already had a C++ framework we were using). There's also Carbon.Qt, which are wrappers for Quicktime. I haven't used these (or Quicktime at all), and can't help with them. Given the description of QTKit in Apple's developer documentation I'd say that using QTKit through PyObjC would be the easiest way to implement the application you want to build. BTW. I don't understand why you want to avoid PyObjC. Do you also want to avoid PIL and other libraries? Ronald > > I wish I could help you with source code, but I'm no longer associated > with that project. > > Kent > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From kaweh.kazemi at chello.at Thu Jun 8 18:44:02 2006 From: kaweh.kazemi at chello.at (Kaweh Kazemi) Date: Thu, 8 Jun 2006 18:44:02 +0200 Subject: [Pythonmac-SIG] py2app and dynamic libraries Message-ID: <076F27CF-C800-46BA-A8F8-1B5CC0256EC6@chello.at> hi there, sorry if that has already been answered previously but i couldn't find anything about this issue*: i have a set of libraries - Panda3D in my case - consisting of various *.so and *.dylib (+ python code), which are located in /usr/ local/panda/lib. using py2app and a rather simple setup.py it will create an application bundle with only the needed *.so but not the needed *.dylib thus the application is not self-contained. is there a way to force these files into the approriate place in the application bundle? i tried the "includes" option but that does not work as excepted. i'm sorry if my question is not clear, i'm totally new to *.so/ *.dylib and py2app. thanks in advance, kw. (* is there a possibility to search the mailing list archives?) From kaweh.kazemi at chello.at Thu Jun 8 18:55:27 2006 From: kaweh.kazemi at chello.at (Kaweh Kazemi) Date: Thu, 8 Jun 2006 18:55:27 +0200 Subject: [Pythonmac-SIG] py2app includes documentation? Message-ID: <6E252E02-CB8A-41DB-A554-2A8FDF6CEC9C@chello.at> hi there, seems that py2app includes the python documentation into the application bundle if it's installed on the system? myApp/dist/myApp.app/Contents/Frameworks/Python.framework/Versions/ 2.4/Resources/English.lproj/Documentation i assume it's because it just copies the Python.framework, correct? any way to prevent that? i really do not need the documentation in the application bundle. :) thanks, kw. From ronaldoussoren at mac.com Thu Jun 8 20:43:10 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 8 Jun 2006 20:43:10 +0200 Subject: [Pythonmac-SIG] py2app includes documentation? In-Reply-To: <6E252E02-CB8A-41DB-A554-2A8FDF6CEC9C@chello.at> References: <6E252E02-CB8A-41DB-A554-2A8FDF6CEC9C@chello.at> Message-ID: On 8-jun-2006, at 18:55, Kaweh Kazemi wrote: > hi there, > > seems that py2app includes the python documentation into the > application bundle if it's installed on the system? > > myApp/dist/myApp.app/Contents/Frameworks/Python.framework/Versions/ > 2.4/Resources/English.lproj/Documentation > > i assume it's because it just copies the Python.framework, correct? > any way to prevent that? i really do not need the documentation in > the application bundle. :) The version of py2app that you get when you install PyObjC from SVN doesn't copy the documentation. Ronald From ronaldoussoren at mac.com Thu Jun 8 20:44:59 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 8 Jun 2006 20:44:59 +0200 Subject: [Pythonmac-SIG] py2app and dynamic libraries In-Reply-To: <076F27CF-C800-46BA-A8F8-1B5CC0256EC6@chello.at> References: <076F27CF-C800-46BA-A8F8-1B5CC0256EC6@chello.at> Message-ID: On 8-jun-2006, at 18:44, Kaweh Kazemi wrote: > hi there, > > sorry if that has already been answered previously but i couldn't > find anything about this issue*: > > i have a set of libraries - Panda3D in my case - consisting of > various *.so and *.dylib (+ python code), which are located in /usr/ > local/panda/lib. > > using py2app and a rather simple setup.py it will create an > application bundle with only the needed *.so but not the needed > *.dylib thus the application is not self-contained. > > is there a way to force these files into the approriate place in the > application bundle? > > i tried the "includes" option but that does not work as excepted. > > i'm sorry if my question is not clear, i'm totally new to *.so/ > *.dylib and py2app. Py2app should do this automaticly if the .so's link to the .dylibs. Do you have an example project that doesn't work for you? Ronald From noah.gift at gmail.com Thu Jun 8 21:26:15 2006 From: noah.gift at gmail.com (Noah Gift) Date: Thu, 8 Jun 2006 15:26:15 -0400 Subject: [Pythonmac-SIG] python and quicktime In-Reply-To: <4F84430E-D521-42CE-AADB-1FC1F00C7454@mac.com> References: <4488331D.3060001@cognitoy.com> <4F84430E-D521-42CE-AADB-1FC1F00C7454@mac.com> Message-ID: Thanks you both for answering me! It would be great if I could make a command line tool that I could script against on any platform, but I am very lazy and it appears that using pyobjc and QTKit is quickest solution. The PIL library does seem very interesting as well. It seems to do "Shake" type things like cropping and padding etc. If I write something worthwhile I will throw it up on sourceforge... On 6/8/06, Ronald Oussoren wrote: > > > On 8-jun-2006, at 16:24, Kent Quirk wrote: > > > Noah Gift wrote: > >> I am new to python and was interested in writing some python code > >> that > >> converts image sequences, for example tiff, into Quicktime movies, > >> for > >> example animation codec. Can anyone point me in the right direction > >> to begin my research? It would be nice to not use pyobjc as I am > >> trying to focus on doing things in pure python for now as a learning > >> excercise. > >> > > > > Well, having solved a similar problem last year (making quicktime > > animations from a sequence of screenshots), I can testify that: > > > > a) It's not easy. Quicktime doesn't make this problem simple or > > document > > it very well. In fact, at last year's WWDC, a guy from Pixar gave a > > talk > > about building a storyboarding tool and along the way ranted about how > > hard it was (and didn't need to be). I suppose it's possible that > > they've improved the documentation since then. > > > > b) It's probably not possible with "pure" python. The file formats are > > neither documented nor trivial, so you're not going to just write the > > bits out to files. And as far as I know, there's no prewritten > > Pythonic > > wrapper for Quicktime -- other than going through PyObjC. If you > > really > > don't want PyObjC, I think your remaining choice is to build a C++ > > plugin for Python that makes the appropriate Quicktime calls (which is > > what we did -- but we already had a C++ framework we were using). > > There's also Carbon.Qt, which are wrappers for Quicktime. I haven't > used these (or Quicktime at all), and can't help with them. > > Given the description of QTKit in Apple's developer documentation I'd > say that using QTKit through PyObjC would be the easiest way to > implement the application you want to build. > > BTW. I don't understand why you want to avoid PyObjC. Do you also > want to avoid PIL and other libraries? > > Ronald > > > > > I wish I could help you with source code, but I'm no longer associated > > with that project. > > > > Kent > > > > _______________________________________________ > > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > > http://mail.python.org/mailman/listinfo/pythonmac-sig > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060608/792dbfed/attachment.html From kaweh.kazemi at chello.at Thu Jun 8 22:13:19 2006 From: kaweh.kazemi at chello.at (Kaweh Kazemi) Date: Thu, 8 Jun 2006 22:13:19 +0200 Subject: [Pythonmac-SIG] py2app includes documentation? In-Reply-To: References: <6E252E02-CB8A-41DB-A554-2A8FDF6CEC9C@chello.at> Message-ID: <8D3F46F8-55B7-42E9-A408-9DAE01FA6CF3@chello.at> thanks, but is the setuptools-0.6b2-py2.4 egg broken? trying to build from svn does need that package, right? probably easiest if i install by hand. just wanted to report the problem. kaweh$ p setup.py bdist_mpkg --open Traceback (most recent call last): File "setup.py", line 89, in ? zip_safe=False, File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ python2.4/distutils/core.py", line 110, in setup _setup_distribution = dist = klass(attrs) File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ setuptools/dist.py", line 219, in __init__ File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ setuptools/dist.py", line 242, in fetch_build_eggs File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ pkg_resources.py", line 481, in resolve File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ pkg_resources.py", line 717, in best_match File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ pkg_resources.py", line 729, in obtain File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ setuptools/dist.py", line 274, in fetch_build_egg AttributeError: Distribution instance has no attribute 'dependency_links' cheers, kw. On 08.06.2006, at 20:43, Ronald Oussoren wrote: > > On 8-jun-2006, at 18:55, Kaweh Kazemi wrote: > >> hi there, >> >> seems that py2app includes the python documentation into the >> application bundle if it's installed on the system? >> >> myApp/dist/myApp.app/Contents/Frameworks/Python.framework/Versions/ >> 2.4/Resources/English.lproj/Documentation >> >> i assume it's because it just copies the Python.framework, correct? >> any way to prevent that? i really do not need the documentation in >> the application bundle. :) > > The version of py2app that you get when you install PyObjC from SVN > doesn't copy the documentation. > > Ronald > From ronaldoussoren at mac.com Thu Jun 8 22:34:19 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 8 Jun 2006 22:34:19 +0200 Subject: [Pythonmac-SIG] py2app includes documentation? In-Reply-To: <8D3F46F8-55B7-42E9-A408-9DAE01FA6CF3@chello.at> References: <6E252E02-CB8A-41DB-A554-2A8FDF6CEC9C@chello.at> <8D3F46F8-55B7-42E9-A408-9DAE01FA6CF3@chello.at> Message-ID: <4410B73C-9EC5-485C-8831-5C76C5A120F4@mac.com> On 8-jun-2006, at 22:13, Kaweh Kazemi wrote: > thanks, but is the setuptools-0.6b2-py2.4 egg broken? trying to > build from svn does need that package, right? probably easiest if i > install by hand. just wanted to report the problem. That's the wrong version, you downloaded the trunk of the py2app repository. That contains unfinished work. The url below contains the current stable version of py2app: http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint Ronald > > kaweh$ p setup.py bdist_mpkg --open > Traceback (most recent call last): > File "setup.py", line 89, in ? > zip_safe=False, > File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ > python2.4/distutils/core.py", line 110, in setup > _setup_distribution = dist = klass(attrs) > File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ > setuptools/dist.py", line 219, in __init__ > File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ > setuptools/dist.py", line 242, in fetch_build_eggs > File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ > pkg_resources.py", line 481, in resolve > File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ > pkg_resources.py", line 717, in best_match > File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ > pkg_resources.py", line 729, in obtain > File "/Users/kaweh/Projects/3rd/py2app/setuptools-0.6b2-py2.4.egg/ > setuptools/dist.py", line 274, in fetch_build_egg > AttributeError: Distribution instance has no attribute > 'dependency_links' > > cheers, > kw. > > On 08.06.2006, at 20:43, Ronald Oussoren wrote: > >> >> On 8-jun-2006, at 18:55, Kaweh Kazemi wrote: >> >>> hi there, >>> >>> seems that py2app includes the python documentation into the >>> application bundle if it's installed on the system? >>> >>> myApp/dist/myApp.app/Contents/Frameworks/Python.framework/Versions/ >>> 2.4/Resources/English.lproj/Documentation >>> >>> i assume it's because it just copies the Python.framework, correct? >>> any way to prevent that? i really do not need the documentation in >>> the application bundle. :) >> >> The version of py2app that you get when you install PyObjC from >> SVN doesn't copy the documentation. >> >> Ronald >> > From rowen at cesmail.net Fri Jun 9 22:44:43 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Fri, 09 Jun 2006 13:44:43 -0700 Subject: [Pythonmac-SIG] py2app question: path to included python References: <5E2A954E-CC10-4A55-B811-2594D6DBA48B@redivi.com> <14958240.1149672370929.JavaMail.ronaldoussoren@mac.com> <1AF62BC1-44E4-4698-AB72-A87DAFB4FB2C@mac.com> Message-ID: In article , Jonathan wrote: > https://patrickkidd.com has wrappers for several audio libraries. The info there is sparse, but none of these seems to be cross-platform. I need a sound player that works on unix, Mac and Windows. snack does the job, but the fact that it's tcl (with a python interface) makes it a bit complicated. (Also, some users report sound cues coming later and later after hours of running -- that *may* be an error in the way I'm using snack, but...). -- Russell From Chris.Barker at noaa.gov Sat Jun 10 00:22:01 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 09 Jun 2006 15:22:01 -0700 Subject: [Pythonmac-SIG] python and quicktime In-Reply-To: References: <4488331D.3060001@cognitoy.com> <4F84430E-D521-42CE-AADB-1FC1F00C7454@mac.com> Message-ID: <4489F489.9030309@noaa.gov> Noah Gift wrote: >It would be great if I could make a > command line tool that I could script against on any platform This was just posted to the PIL mailing list -- perhaps it could be helpful to you: """ http://yourmachines.org/tutorials/mgpy.html this uses PIL, ffmpeg, aggdraw, PyGame, and a bunch of other tools to do various kinds of motion graphics in Python, including animated graphics and video processing. """ -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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 Sat Jun 10 18:13:21 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 10 Jun 2006 18:13:21 +0200 Subject: [Pythonmac-SIG] Carbon wrappers and bugs on the SF tracker Message-ID: <9B5036C4-CB78-44E9-9ACE-B6EECC7AE88C@mac.com> The first beta of python 2.5 is getting close (the planned release date is jun 14th). There have been complaints in the past about the quality of the Carbon bindings (anything in the Carbon namespace in python, which includes stuff that isn't actually part of Carbon such as QuickTime). It would be nice if we could fix at least some of those problems before 2.5 is out. That will obviously not happen all by itself. I'd appriate if people that actually use this functionality could at least write down the problems they run into, actual patches would be even better. The prefered mode for writing down issues are items on the SF trackers assigned to me, but feel free to post e-mail messages if you don't want to use the SF tracker. Related to this is documentation: there was talk about improving the mac-specific documentation a while back, but as far as I know nothing actually happened. Again any help would be appriated. The most glaring omission right now is a generic description of how the wrappers in the Carbon namespace actually work (that is, an introduction to chapter 4 in the documentation at http:// docs.python.org/dev/mac/mac.html). Most of chapter one can be removed, and I'll probably add a deprecation warning to chapter 3 (OSA support) and point people to appscript instead. Ronald From jerry.levan at eku.edu Sat Jun 10 21:00:49 2006 From: jerry.levan at eku.edu (Jerry LeVan) Date: Sat, 10 Jun 2006 15:00:49 -0400 Subject: [Pythonmac-SIG] PIL related crash? Message-ID: Hi, I am trying my hand at trying to build a simple image viewer for embedding into a larger application. The following code will display images ok on my linux box running python 2.4.2 and ActiveState Tcl/Tk 8.4.13 The same code crashes before the interface comes up on my Mac OSX 10.4.6 Aqua TclTk Batteries included 8.4.10 and python 2.4.3, it looks like it is dying deep in the imaging code. Is this a know problem? Any suggestions? Jerry ***************** #!/usr/bin/env python from Tkinter import * import Image, ImageTk def build_scrolled_canvas(parent): canvas=Canvas(parent) sy = Scrollbar(parent, command=canvas.yview) sx = Scrollbar(parent, orient=HORIZONTAL, command= canvas.xview) canvas.configure(yscrollcommand=sy.set,xscrollcommand=sx.set) canvas.grid(row=0,column=0,sticky=NSEW) sy.grid(row=0,column=1,stick=N+S) sx.grid(row=1,column=0,sticky=E+W) parent.columnconfigure(0,weight=1) parent.rowconfigure(0,weight=1) return canvas # if __name__ == '__main__': theWin = Toplevel() theFrame = Frame(theWin) theCanvas = build_scrolled_canvas(theFrame) theButton= Button(theWin,text="exit",command=theWin.destroy) theFrame.pack(side=TOP, expand=TRUE, fill=BOTH) theButton.pack(side=TOP) im = Image.open(sys.argv[1]) (width,height) = im.size tkim = ImageTk.PhotoImage(im) theCanvas.create_image(0,0,image=tkim,anchor=NW) theCanvas['scrollregion'] = (0,0,width,height) mainloop() ********************** From daniellord at mac.com Sun Jun 11 00:55:16 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 10 Jun 2006 15:55:16 -0700 Subject: [Pythonmac-SIG] PIL related crash? In-Reply-To: References: Message-ID: On Jun 10, 2006, at 12:00, Jerry LeVan wrote: > Hi, I am trying my hand at trying to build a simple image > viewer for embedding into a larger application. > > The following code will display images ok on my linux > box running python 2.4.2 and ActiveState Tcl/Tk 8.4.13 > > The same code crashes before the interface comes up on > my Mac OSX 10.4.6 Aqua TclTk Batteries included 8.4.10 > and python 2.4.3, it looks like it is dying deep in > the imaging code. > > Is this a know problem? > > Any suggestions? Your code works fine on my Macbook Pro although when I press the 'exit' button, it leaves the main tk window open so you need to clean up a bit better. I suggest you consider something is wrong uniquely with your system or installations of the components. Are you on a PPC or Intel? Showing the traceback would perhaps be more helpful. My system is: OS X 10.4.6 Python 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Tcl/Tk 8.4.13 Daniel Lord From jerry.levan at eku.edu Sun Jun 11 00:58:39 2006 From: jerry.levan at eku.edu (Jerry LeVan) Date: Sat, 10 Jun 2006 18:58:39 -0400 Subject: [Pythonmac-SIG] PIL related crash? Message-ID: <77242A85-321A-421F-BE92-E556924017AD@eku.edu> Rats, I can't get even the simplest PIL programs to display... Here is one...(works fine on my linux box....) from Tkinter import * import Image,ImageTk import sys def main(): filename = sys.argv[1] root = Tk() img = ImageTk.PhotoImage(file=filename) label = Label(root, image=img) label.pack() root.mainloop() main() ********** I get a bus error , here is a partial dump Date/Time: 2006-06-10 18:48:29.695 -0400 OS Version: 10.4.6 (Build 8I127) Report Version: 4 Command: Python Path: /Library/Frameworks/Python.framework/Versions/2.4/Resources/ Python.app/Contents/MacOS/Python Parent: bash [7890] Version: 2.4a0 (2.4alpha1) PID: 6367 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000028 Thread 0 Crashed: 0 com.tcltk.tklibrary 0x0b065d08 Tk_GetImageMasterData + 32 1 com.tcltk.tklibrary 0x0b071098 Tk_FindPhoto + 32 2 _imagingtk.so 0x007fd98c TkImaging_Init + 192 3 com.tcltk.tcllibrary 0x0a00dc8c TclInvokeStringCommand + 148 4 com.tcltk.tcllibrary 0x9bd02bfc TclEvalObjvInternal + 668 5 com.tcltk.tcllibrary 0x9bd02ddc Tcl_EvalObjv + 216 6 _tkinter.so 0x000a8980 Tkapp_Call + 348 (_tkinter.c:1314) 7 org.python.python 0x0028b7fc PyEval_EvalFrame + 16700 (ceval.c:3563) 8 org.python.python 0x0028da5c PyEval_EvalCodeEx + 2064 (ceval.c:2736) 9 org.python.python 0x0028ba18 PyEval_EvalFrame + 17240 (ceval.c:3656) 10 org.python.python 0x0028da5c PyEval_EvalCodeEx + 2064 (ceval.c:2736) 11 org.python.python 0x0022bf40 function_call + 340 (funcobject.c:555) 12 org.python.python 0x0020d5a4 PyObject_Call + 52 (abstract.c: 1796) 13 org.python.python 0x00217324 instancemethod_call + 520 (classobject.c:2448) 14 org.python.python 0x0020d5a4 PyObject_Call + 52 (abstract.c: 1796) 15 org.python.python 0x00286578 PyEval_CallObjectWithKeywords + 268 (ceval.c:3431) 16 org.python.python 0x00219b88 PyInstance_New + 540 (classobject.c:576) 17 org.python.python 0x0020d5a4 PyObject_Call + 52 (abstract.c: 1796) 18 org.python.python 0x0028ba98 PyEval_EvalFrame + 17368 (ceval.c:3773) 19 org.python.python 0x0028b984 PyEval_EvalFrame + 17092 (ceval.c:3647) 20 org.python.python 0x0028da5c PyEval_EvalCodeEx + 2064 (ceval.c:2736) 21 org.python.python 0x0028dbe4 PyEval_EvalCode + 48 (ceval.c:490) 22 org.python.python 0x002b5ba8 PyRun_FileExFlags + 212 (pythonrun.c:1266) 23 org.python.python 0x002b5dbc PyRun_SimpleFileExFlags + 432 (pythonrun.c:860) 24 org.python.python 0x002c0bfc Py_Main + 2732 (main.c:501) 25 org.python.python 0x0000257c 0x1000 + 5500 26 org.python.python 0x00002424 0x1000 + 5156 Thread 1: 0 libSystem.B.dylib 0x9001f5ec select + 12 1 com.tcltk.tklibrary 0x9be24a20 NotifierThreadProc + 432 2 libSystem.B.dylib 0x9002ba68 _pthread_body + 96 Thread 0 crashed with PPC Thread State 64: srr0: 0x000000000b065d08 srr1: 0x000000000200d030 vrsave: 0x0000000000000000 cr: 0x44244422 xer: 0x0000000000000004 lr: 0x000000000b065d04 ctr: 0x000000000b071078 r0: 0x000000000b065d04 r1: 0x00000000bfffe730 r2: 0x0000000000000000 r3: 0x0000000000000000 r4: 0x00000000007d4728 r5: 0x00000000bfffe7c0 r6: 0x00000000bfffe8e0 r7: 0x0000000080808080 r8: 0x0000000000000000 r9: 0x00000000016d26f0 r10: 0x0000000036352eff r11: 0x00000000007fe058 r12: 0x000000000b071078 r13: 0x00000000ffffffff r14: 0x0000000000000000 r15: 0x00000000ffffffff r16: 0x0000000000606ab4 r17: 0x00000000005824e0 r18: 0x000000000057d060 r19: 0x0000000000000000 r20: 0x0000000000040000 r21: 0x0000000000000000 r22: 0x000000009bd7396c r23: 0x00000000bfffe8e0 r24: 0x00000000005faa08 r25: 0x00000000040c8008 r26: 0x00000000bfffeb6c r27: 0x0000000000000003 r28: 0x00000000bfffe8e0 r29: 0x00000000007d4728 r30: 0x00000000bfffe7c0 r31: 0x000000000b071084 Binary Images Description: 0x1000 - 0x2fff org.python.python 2.4a0 (2.4alpha1) /Library/ Frameworks/Python.framework/Versions/2.4/Resources/Python.app/ Contents/MacOS/Python 0xa3000 - 0xaafff _tkinter.so /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/lib-dynload/_tkinter.so 0x205000 - 0x2f3fff org.python.python 2.4a0 (2.2) /Library/ Frameworks/Python.framework/Versions/2.4/Python 0x709000 - 0x70afff MacOS.so /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/lib-dynload/MacOS.so 0x712000 - 0x755fff _imaging.so /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/PIL/ _imaging.so 0x76b000 - 0x76ffff array.so /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/lib-dynload/array.so 0x77e000 - 0x781fff strop.so /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/lib-dynload/strop.so 0x78e000 - 0x790fff operator.so /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/lib-dynload/operator.so 0x7fd000 - 0x7fdfff _imagingtk.so /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/PIL/ _imagingtk.so 0xa000000 - 0xa087fff com.tcltk.tcllibrary 8.4.10 /Library/ Frameworks/Tcl.framework/Versions/8.4/Tcl 0xb000000 - 0xb0c2fff com.tcltk.tklibrary 8.4.10 /Library/Frameworks/ Tk.framework/Versions/8.4/Tk From jerry.levan at eku.edu Sun Jun 11 01:07:25 2006 From: jerry.levan at eku.edu (Jerry LeVan) Date: Sat, 10 Jun 2006 19:07:25 -0400 Subject: [Pythonmac-SIG] PIL related crash? In-Reply-To: References: Message-ID: <28B7FD62-B599-4D79-8ADE-CACDBA096294@eku.edu> I just posted another example with the dump. I did not want the app to close since I want to suck images out of my database and display them to the user. Did you build your own Tcl/Tk ( I am using the oldish 8.4.10 Aqua BI distribution...). I seem to recall that PIL worked prior to upgrading to Python 2.4.3... I think I got the MacPython from Python.org. The PIL software seems to be present in /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site- packages/PIL Jerry On Jun 10, 2006, at 6:55 PM, Daniel Lord wrote: > > On Jun 10, 2006, at 12:00, Jerry LeVan wrote: > >> Hi, I am trying my hand at trying to build a simple image >> viewer for embedding into a larger application. >> >> The following code will display images ok on my linux >> box running python 2.4.2 and ActiveState Tcl/Tk 8.4.13 >> >> The same code crashes before the interface comes up on >> my Mac OSX 10.4.6 Aqua TclTk Batteries included 8.4.10 >> and python 2.4.3, it looks like it is dying deep in >> the imaging code. >> >> Is this a know problem? >> >> Any suggestions? > > Your code works fine on my Macbook Pro although when I press the > 'exit' button, it leaves the main tk window open so you need to > clean up a bit better. > > I suggest you consider something is wrong uniquely with your system > or installations of the components. > Are you on a PPC or Intel? > Showing the traceback would perhaps be more helpful. > > My system is: > OS X 10.4.6 > Python 2.4.3 (#1, Apr 7 2006, 10:54:33) > [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin > Tcl/Tk 8.4.13 > > Daniel Lord > > From jerry.levan at eku.edu Sun Jun 11 01:09:33 2006 From: jerry.levan at eku.edu (Jerry LeVan) Date: Sat, 10 Jun 2006 19:09:33 -0400 Subject: [Pythonmac-SIG] PIL related crash? In-Reply-To: References: Message-ID: I forgot to add: I am running on a "QuickSilver 933MHZ PPC" mac. Jerry On Jun 10, 2006, at 6:55 PM, Daniel Lord wrote: > > On Jun 10, 2006, at 12:00, Jerry LeVan wrote: > >> Hi, I am trying my hand at trying to build a simple image >> viewer for embedding into a larger application. >> >> The following code will display images ok on my linux >> box running python 2.4.2 and ActiveState Tcl/Tk 8.4.13 >> >> The same code crashes before the interface comes up on >> my Mac OSX 10.4.6 Aqua TclTk Batteries included 8.4.10 >> and python 2.4.3, it looks like it is dying deep in >> the imaging code. >> >> Is this a know problem? >> >> Any suggestions? > > Your code works fine on my Macbook Pro although when I press the > 'exit' button, it leaves the main tk window open so you need to > clean up a bit better. > > I suggest you consider something is wrong uniquely with your system > or installations of the components. > Are you on a PPC or Intel? > Showing the traceback would perhaps be more helpful. > > My system is: > OS X 10.4.6 > Python 2.4.3 (#1, Apr 7 2006, 10:54:33) > [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin > Tcl/Tk 8.4.13 > > Daniel Lord > > From jerry.levan at eku.edu Sun Jun 11 02:16:40 2006 From: jerry.levan at eku.edu (Jerry LeVan) Date: Sat, 10 Jun 2006 20:16:40 -0400 Subject: [Pythonmac-SIG] FIXED: PIL related crash? In-Reply-To: References: Message-ID: <600B6867-C47F-415B-80FC-7CB7020002E3@eku.edu> I checked the PIL directory and noticed that the dates on the PIL files looked a bit old. I went back to pythonmac.org and downloaded the PIL that was available and all is well now :) Jerry On Jun 10, 2006, at 6:55 PM, Daniel Lord wrote: > > On Jun 10, 2006, at 12:00, Jerry LeVan wrote: > >> Hi, I am trying my hand at trying to build a simple image >> viewer for embedding into a larger application. >> >> The following code will display images ok on my linux >> box running python 2.4.2 and ActiveState Tcl/Tk 8.4.13 >> >> The same code crashes before the interface comes up on >> my Mac OSX 10.4.6 Aqua TclTk Batteries included 8.4.10 >> and python 2.4.3, it looks like it is dying deep in >> the imaging code. >> >> Is this a know problem? >> >> Any suggestions? > > Your code works fine on my Macbook Pro although when I press the > 'exit' button, it leaves the main tk window open so you need to > clean up a bit better. > > I suggest you consider something is wrong uniquely with your system > or installations of the components. > Are you on a PPC or Intel? > Showing the traceback would perhaps be more helpful. > > My system is: > OS X 10.4.6 > Python 2.4.3 (#1, Apr 7 2006, 10:54:33) > [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin > Tcl/Tk 8.4.13 > > Daniel Lord > > From daniellord at mac.com Sun Jun 11 02:44:02 2006 From: daniellord at mac.com (Daniel Lord) Date: Sat, 10 Jun 2006 17:44:02 -0700 Subject: [Pythonmac-SIG] FIXED: PIL related crash? In-Reply-To: <600B6867-C47F-415B-80FC-7CB7020002E3@eku.edu> References: <600B6867-C47F-415B-80FC-7CB7020002E3@eku.edu> Message-ID: On Jun 10, 2006, at 17:16, Jerry LeVan wrote: > I checked the PIL directory and noticed that the dates on the PIL > files looked a bit old. > > I went back to pythonmac.org and downloaded the PIL that was > available and all is well now :) > > Jerry > Jerry, The PIL you just got is the one I am using if I recall correctly--ben a while since I built and installed it PIL. Glad it works for you too--you had me worried there for a while since I think that is the one I built ;-) Daniel From monsterkodi at gmx.net Sun Jun 11 11:55:14 2006 From: monsterkodi at gmx.net (Thorsten Kohnhorst) Date: Sun, 11 Jun 2006 11:55:14 +0200 Subject: [Pythonmac-SIG] krix, a visual music browser for OS X written in pyobjc Message-ID: Hello, I am currently developing a pyobjc application for visually browsing music libraries. Maybe it is of same value for somebody here. If you tested it, it would be nice if you could give some feedback if it worked or not. The latest version is available for download at sourceforge: http://kiki.sf.net Thanks in advance, have a nice day, yours kodi From ronaldoussoren at mac.com Sun Jun 11 12:56:39 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 11 Jun 2006 12:56:39 +0200 Subject: [Pythonmac-SIG] krix, a visual music browser for OS X written in pyobjc In-Reply-To: References: Message-ID: <36CFCA32-6911-46D1-9AB0-C89C1B582865@mac.com> On 11-jun-2006, at 11:55, Thorsten Kohnhorst wrote: > Hello, > > I am currently developing a pyobjc application for visually browsing > music libraries. > Maybe it is of same value for somebody here. > If you tested it, it would be nice if you could give some feedback if > it worked or not. > The latest version is available for download at sourceforge: > > http://kiki.sf.net That should be: http://krix.sourceforge.net/ ;-) Ronald From marcink at ieee.org Sun Jun 11 21:45:20 2006 From: marcink at ieee.org (Marcin Komorowski) Date: Sun, 11 Jun 2006 15:45:20 -0400 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 38, Issue 16 In-Reply-To: References: Message-ID: Hey Kodi, I think you meant to quote http://krix.sf.net as the link Cheers, Marcin On 11-Jun-06, at 6:00 AM, pythonmac-sig-request at python.org wrote: > From: Thorsten Kohnhorst > Date: June 11, 2006 5:55:14 AM EDT (CA) > To: pythonmac-sig at python.org > Subject: [Pythonmac-SIG] krix, a visual music browser for OS X > written in pyobjc > > > Hello, > > I am currently developing a pyobjc application for visually > browsing music libraries. > Maybe it is of same value for somebody here. > If you tested it, it would be nice if you could give some feedback > if it worked or not. > The latest version is available for download at sourceforge: > > http://kiki.sf.net > > Thanks in advance, > have a nice day, > yours kodi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060611/abc02485/attachment.html From monsterkodi at gmx.net Mon Jun 12 00:08:25 2006 From: monsterkodi at gmx.net (Thorsten Kohnhorst) Date: Mon, 12 Jun 2006 00:08:25 +0200 Subject: [Pythonmac-SIG] krix, a visual music browser for OS X written in pyobjc In-Reply-To: References: Message-ID: <896BC954-0D3B-4D76-9E51-6FA321367E84@gmx.net> Hello Ronald and Marcin, Ooops, yes, you are right. Sorry for the mistake and thanks for pointing it out. By the way, I have just uploaded the latest version :-) Yours kodi From dan at chalkie.org.uk Mon Jun 12 10:33:33 2006 From: dan at chalkie.org.uk (Dan White) Date: Mon, 12 Jun 2006 11:33:33 +0300 Subject: [Pythonmac-SIG] py2app universal binary problems In-Reply-To: References: Message-ID: Hi Steve, I have got as far a building the python wrapped c++ libraries i need to use on ppc and intel, and now I need to lipo them together to make universal ones, then i can get working with py2app. We had problem previously with py2app not picking up all the bits it needed to make a working .app for our project. Probably that was just us doing it wrong. As I understand it the most development with py2app is going on as part of the pyobjC project, and they have a bleeding edge py2app there, which i am planning to install and try out to build our universal app cheers Dan On 11 Jun 2006, at 22:44, Steve Doe wrote: > Dan, > > I found one of your posts on problems building universal binaries > with py2app. I have finally been able to get a macpython 2.4 > variant and the latest experimental wxpython universal builds to > work. I am only missing the py2app to build universal > applications. From your post it appears you had the same problem. > > Have you figured it out? or is it still a problem for you? > > thanks, > > Steve Doe - steve.doe at gmail.com > Fellow Python user Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From njriley at uiuc.edu Mon Jun 12 17:21:47 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon, 12 Jun 2006 10:21:47 -0500 Subject: [Pythonmac-SIG] exception on NSWorkspace.launchAppWithBundleIdentifier_options_additionalEventParamDescriptor_launchIdentifier_ Message-ID: <20060612152147.GA61258@uiuc.edu> Hi, I'm trying to launch an app in the background, as follows: ws = NSWorkspace.sharedWorkspace() ws.launchAppWithBundleIdentifier_options_additionalEventParamDescriptor_launchIdentifier_(bundleID, NSWorkspaceLaunchAndHide | NSWorkspaceLaunchWithoutActivation, None) I've tried simplifying this and changing it, for example: ws.launchAppWithBundleIdentifier_options_additionalEventParamDescriptor_launchIdentifier_(u'com.apple.Finder', 0, NSAppleEventDescriptor.nullDescriptor()) But no matter what I do, I get an IndexError: NSRangeException - *** -[NSCFArray objectAtIndex:]: index (0) beyond bounds (0) This occurs inside the method; that's about all I can tell from here: #0 0x92991008 in -[NSException raise] () #1 0x92990e5c in +[NSException raise:format:] () #2 0x92954050 in -[NSCFArray objectAtIndex:] () #3 0x93b739f8 in -[NSWorkspace launchAppWithBundleIdentifier:options:additionalEventParamDescriptor:launchIdentifier:] () #4 0x002be654 in ffi_call_DARWIN () #5 0x002be248 in ffi_call () #6 0x002c840c in PyObjCFFI_Caller () #7 0x002dc5c0 in PyObjCSelector_GetFlags () #8 0x0040d5a4 in PyObject_Call (func=0x12278e0, arg=0x90aae1a0, kw=0x54) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/abstract.c:1795 The exception is raised after the method has successfully done its work, so if I catch it and ignore it, everything works, but that doesn't exactly fill me with feelings of happiness. The same method invocation works fine from Objective-C. What's going on? I'm using Python 2.4.3 Universal on a PPC 10.4.6 machine, and PyObjC 1.3.7. Thanks, -- Nicholas Riley | From jf at ai.univ-paris8.fr Mon Jun 12 18:15:09 2006 From: jf at ai.univ-paris8.fr (Feat) Date: Mon, 12 Jun 2006 18:15:09 +0200 Subject: [Pythonmac-SIG] client + server Message-ID: I need some help to make this simple program run [please, see the source code below] as it's probably some basic misunderstanding. I'm trying to lay out the principles of an elementary chat server with a fixed number of clients, and I've been testing these two programs on my local network -- WiFi, no fire wall. The client would be an iMac G5 running X.4.6 at 192.168.1.20 while the server would be a PowerBook running X.3.9 at 192.168.1.129. That said, swapping the machines doesn't solve anything. The question is: why can't the client use the socket.connect function here? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The server runs with no glitch and cycles in its while-loop. Meanwhile, I launch the client, but it quits on a sys.exit instruction, and the socket.connect function doesn't return anything printable -- maybe because it executes in a try-block?... Here's the error I get: $ python client.py jf ~~~ Name : jf - Host : 192.168.1.129 - Port : 5007 Connection failed - error : None Any idea? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ # -- source code # -- server from socket import * import threading import sys def server (Host, Port): global clients S = socket (AF_INET, SOCK_STREAM) try: S.bind ((Host, Port)) except: print "socket connection failed" sys.exit () print "Host =", Host, "\nPort =", Port print "Accepting new clients..." S.listen (MAX) while True: C, A = S.accept () P = C.recv (10) # pseudonym clients.append (C) print "New client connected:", P, A threading.Thread (target = dialog, args = (P, C)).start () def dialog (pseudo, socket): help (socket) while True: CliMsg = socket.recv (BuffSize) if (CliMsg == '/quit'): SrvMsg = pseudo + ' = disconnected' break if (CliMsg == '/help'): help (socket) continue SrvMsg = pseudo + ' = ' + CliMsg print SrvMsg for c in range (len (clients)): clients[c].send (SrvMsg) print SrvMsg for c in range (len (clients)): clients[c].send (SrvMsg) for c in range (len (clients)): if (clients[c] == socket): del (clients[c]) socket.close () def help (socket): help_text = "\n" help_text += "type /help to display this again\n" help_text += "type /quit to disconnect\n" help_text += "press [quit] to quit\n" socket.send (help_text) clients = [] HOST = 'localhost' PORT = 5007 # can't bind this for 2 successive runs BuffSize = 1024 MAX = 5 if len (sys.argv) > 1: if len (sys.argv) == 3: HOST = sys.argv[1] PORT = int (sys.argv[2]) else: print "usage:", sys.argv[0], " " sys.exit () threading.Thread (target = server, args = (HOST, PORT)).start () # -- client import threading import Tkinter import sys import tkSimpleDialog import socket def send_handler (event): global NT try: CliMsg = NT.get () NT.delete (0, END) socket.send (CliMsg) except: socket.close () sys.exit def quit (): try: socket.send ('/quit') except: pass root.destroy () root.quit () def setup (root, title): global TF, NT root.title (title) TF = Text (root, width = 60, height = 20) TF.grid (row = 0, column = 0, columnspan = 3) SB = Scrollbar (root, orient = VERTICAL) SB.config (command = TF.yview) TF.config (yscrollcommand = SB.set) SB.grid (row = 0, column = 3, sticky = N + S) NT = Entry (root) NT.grid (row = 1, column = 0, columnspan = 2, sticky = W + E) NT.bind ("", send_handler) NT.focus_set () QB = Button (root, text = 'quit', command = quit) QB.grid (row = 1, column = 2) def connect (Host, Port, P): Sk = socket.socket (socket.AF_INET, socket.SOCK_STREAM) try: Sk.socket.connect ((Host, Port)) except : print "Connection failed..." sys.exit () print "Connection successful @ ", Host , Port Sk.socket.send (P) return Sk def listening (sock): global TF while True: try: SrvMsg = sock.recv (BuffSize) if (SrvMsg): TF.insert (END, SrvMsg + '\n') except: TF.insert (END, "not connected...\n") print "Not connected..." break sock.close () # Application specific ~~~~~~~~~~~~~~~~~~~~~~~~ HOST = 'localhost' HOST = '192.168.1.129' # my network only PORT = 5007 BuffSize = 1024 P = None # pseudonym if (len (sys.argv) > 1): if (len (sys.argv) == 2): P = sys.argv[1] elif (len (sys.argv) == 3): HOST = sys.argv[1] PORT = int (sys.argv[2]) elif (len (sys.argv) == 4): HOST = sys.argv[1] PORT = int (sys.argv[2]) P = sys.argv[3] else : print "usage:", sys.argv[0], " [HOST PORT] [userName]" sys.exit () while (not P): P = tkSimpleDialog.askstring ('P', 'Pseudonym?...') # remove this one print "~~~ Client name:", P, "- Host:", HOST, "- Port:", PORT socket = connect (HOST, PORT, P) root = Tk () setup (root, "PyChAt @ " + P) threading.Thread (target = listening, args = [socket]).start () root.mainloop () -- Jym Feat -- Paris FR 75018 From vivacarlie at gmail.com Mon Jun 12 19:02:43 2006 From: vivacarlie at gmail.com (Nehemiah Dacres) Date: Mon, 12 Jun 2006 12:02:43 -0500 Subject: [Pythonmac-SIG] krix, a visual music browser for OS X written in pyobjc In-Reply-To: <896BC954-0D3B-4D76-9E51-6FA321367E84@gmx.net> References: <896BC954-0D3B-4D76-9E51-6FA321367E84@gmx.net> Message-ID: <65fadfc30606121002m4b1edb90r43aad29203fc2ec@mail.gmail.com> to mr Kohnhorst did u design that page in iweb? It looks good. to the rest I wanted to get into pyopbc, but i only learned python in class last semester freshman year. it was geared towards object oriented programming, not to design end user software so i have no where to start for a gui. I would like to start programming in python before i forget it. (use it or lose it) as for those on the sig who remember, i've reinstalled os10.4. some things are funny but i hope things are fixed. On 6/11/06, Thorsten Kohnhorst wrote: > > > Hello Ronald and Marcin, > > Ooops, yes, you are right. > > Sorry for the mistake and thanks for pointing it out. > > By the way, I have just uploaded the latest version :-) > > Yours kodi > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060612/c711bf26/attachment.htm From bob at redivi.com Mon Jun 12 19:17:23 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 12 Jun 2006 10:17:23 -0700 Subject: [Pythonmac-SIG] client + server In-Reply-To: References: Message-ID: On Jun 12, 2006, at 9:15 AM, Feat wrote: > I need some help to make this simple program run [please, see the > source code below] as it's probably some basic misunderstanding. > I'm trying to lay out the principles of an elementary chat server > with a fixed number of clients, and I've been testing these two > programs on my local network -- WiFi, no fire wall. > > The client would be an iMac G5 running X.4.6 at 192.168.1.20 while > the server would be a PowerBook running X.3.9 at 192.168.1.129. > That said, swapping the machines doesn't solve anything. > > The question is: why can't the client use the socket.connect > function here? The first thing is that it's really hard to read because the naming conventions and spacing are very strange. You should give PEP 8 a good read and get used to writing Python code the way most other people do: http://www.python.org/dev/peps/pep-0008/ The reason that it doesn't work is that your connect function is totally busted: > def connect (Host, Port, P): > Sk = socket.socket (socket.AF_INET, socket.SOCK_STREAM) > try: > Sk.socket.connect ((Host, Port)) > except : > print "Connection failed..." > sys.exit () > print "Connection successful @ ", Host , Port > Sk.socket.send (P) > return Sk Sockets don't have a socket attribute. It should be just "sk.connect ((host, port))" and "sk.send(p)". This is also why you should never use a bare try:except: statement. It should really only be catching socket.error; logging the exception is usually a good idea as well. In this case you're getting an AttributeError, which is clearly not what you'd expect. Another reason that it might not work (once you fix connect) is that the server listens on ('localhost', 5007) by default... you probably want to listen on ('', 5007) or ('0.0.0.0', 5007) if you want other machines to connect to you. -bob From rswerdlow at goombah.com Tue Jun 13 01:52:52 2006 From: rswerdlow at goombah.com (Bob Swerdlow) Date: Mon, 12 Jun 2006 19:52:52 -0400 Subject: [Pythonmac-SIG] py2app crash if path contains a colon Message-ID: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> Hi, our app is using py2app 0.2.1 and we've been quite happy with it - thanks! However, we have found that it crashes if the application is started in a folder whose name contains a colon. Of course, the Finder does not allow the user to use a colon in file names, but other applications do. According to the user: > Dated Download Folders are a standard option in > Saft for Safari which a lot of users are using. The error report sent to us was: >> I'm getting an error when starting your application when freshly >> downloaded. >> See the subject. >> Complete log in console : >> 'import site' failed; use -v for traceback >> Traceback (most recent call last): >> File >> "/Users/sreiche/Downloads/6:10:06/GoombahDisk/Goombah.app/Contents/Resources/__boot__.py", >> line 4, in ? >> _chdir_resource() >> File >> "/Users/sreiche/Downloads/6:10:06/GoombahDisk/Goombah.app/Contents/Resources/__boot__.py", >> line 2, in _chdir_resource >> import os >> ImportError: No module named os >> 2006-06-10 13:07:12.823 Goombah[2890] Goombah Error >> 2006-06-10 13:07:12.823 Goombah[2890] An unexpected error has >> occurred during execution of the main script >> >> I'm running 10.4.6 on a DualP 1.8 GHz PowerMac G5... Is this a known problem? Is there a work-around? Thanks, Bob From bob at redivi.com Wed Jun 14 10:20:31 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 14 Jun 2006 01:20:31 -0700 Subject: [Pythonmac-SIG] py2app crash if path contains a colon In-Reply-To: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> References: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> Message-ID: <4F891AB0-7AEB-411B-9B84-2339166FE9B7@redivi.com> On Jun 12, 2006, at 4:52 PM, Bob Swerdlow wrote: > Hi, our app is using py2app 0.2.1 and we've been quite happy with it - > thanks! > > However, we have found that it crashes if the application is > started in a > folder whose name contains a colon. Of course, the Finder does not > allow > the user to use a colon in file names, but other applications do. > According > to the user: In Carbon APIs, these colons are represented by '/' (the POSIX path delimiter)... from Finder (and I think also at the lowest level HFS+ APIs), that path looks like "6/10/06". Anything using the POSIX APIs is going to see "6:10:06" though. > Is this a known problem? Is there a work-around? It's a problem with Python actually, which persists even in the trunk. Probably because a colon is often treated as a delimiter for a list of paths (such as the PATH or PYTHONPATH environment variables). If you run Python from a path containing ':' and look at sys.path, you'll see that the paths that would've contained a colon are mangled. I'm not sure where this happens and I don't have time to track it down at the moment. It won't be possible to work around this without patching the Python interpreter. For now you'll just have to tell your users Don't Do That. I can only think of two workarounds: (1) just tell the user that they can't run the app from a path containing a ":" in a relatively friendly manner (could be done in the py2app bootstrap). (2) make a symlink somewhere from the py2app bootstrap if a ":" is in the working directory and re-exec. I'm unlikely to do either of those things any time soon, but patches are accepted. If you come up with a patch for Python, file it on sourceforge and shoot a message referencing it here and someone will definitely apply it. I'd hurry up though, because Python 2.5 is pretty far along. -bob From ronaldoussoren at mac.com Wed Jun 14 11:51:37 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 14 Jun 2006 11:51:37 +0200 Subject: [Pythonmac-SIG] py2app crash if path contains a colon In-Reply-To: <4F891AB0-7AEB-411B-9B84-2339166FE9B7@redivi.com> References: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> <4F891AB0-7AEB-411B-9B84-2339166FE9B7@redivi.com> Message-ID: <3508427.1150278697824.JavaMail.ronaldoussoren@mac.com> Could either of you file a bug about this (the sys.path mangling when there's a colon in the directory that contains the executable) on python's SF tracker? Preferably including decription of how to reproduce this. Bob, I've created a directory 'test:dir' and added a script named 'test.py' in that directory that prints sys.path. If I run 'python test:dir/test.py' sys.path[0] looks correct (including the colon in test:dir). Ronald On Wednesday, June 14, 2006, at 10:21AM, Bob Ippolito wrote: >On Jun 12, 2006, at 4:52 PM, Bob Swerdlow wrote: > >> Hi, our app is using py2app 0.2.1 and we've been quite happy with it - >> thanks! >> >> However, we have found that it crashes if the application is >> started in a >> folder whose name contains a colon. Of course, the Finder does not >> allow >> the user to use a colon in file names, but other applications do. >> According >> to the user: > >In Carbon APIs, these colons are represented by '/' (the POSIX path >delimiter)... from Finder (and I think also at the lowest level HFS+ >APIs), that path looks like "6/10/06". Anything using the POSIX APIs >is going to see "6:10:06" though. > >> Is this a known problem? Is there a work-around? > >It's a problem with Python actually, which persists even in the >trunk. Probably because a colon is often treated as a delimiter for a >list of paths (such as the PATH or PYTHONPATH environment variables). >If you run Python from a path containing ':' and look at sys.path, >you'll see that the paths that would've contained a colon are >mangled. I'm not sure where this happens and I don't have time to >track it down at the moment. > >It won't be possible to work around this without patching the Python >interpreter. For now you'll just have to tell your users Don't Do >That. I can only think of two workarounds: >(1) just tell the user that they can't run the app from a path >containing a ":" in a relatively friendly manner (could be done in >the py2app bootstrap). >(2) make a symlink somewhere from the py2app bootstrap if a ":" is in >the working directory and re-exec. > >I'm unlikely to do either of those things any time soon, but patches >are accepted. If you come up with a patch for Python, file it on >sourceforge and shoot a message referencing it here and someone will >definitely apply it. I'd hurry up though, because Python 2.5 is >pretty far along. > >-bob > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG at python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > From dan at chalkie.org.uk Wed Jun 14 15:41:19 2006 From: dan at chalkie.org.uk (Dan White) Date: Wed, 14 Jun 2006 16:41:19 +0300 Subject: [Pythonmac-SIG] py2app SVN - install error Message-ID: <314E8EB2-1462-4870-B04D-A481CACDF5E7@chalkie.org.uk> Hi Bob, i checked out the py2app SVN onto my MacBookPro with the universal python2.4 installed The py2app install instructions say run python setup.py bdist_mpkg --open but that gives me an error after it downloads the egg, see below, am I doing something wrong? cheers Dan white:~/Desktop/py2appSVN/trunk dan$ python2.4 setup.py bdist_mpkg -- open ------------------------------------------------------------------------ --- This script requires setuptools version 0.6b3 to run (even to display help). I will attempt to download it for you (from http://cheeseshop.python.org/packages/2.4/s/setuptools/), but you may need to enable firewall access for this script first. I will start the download in 15 seconds. (Note: if this machine does not have network access, please obtain the file http://cheeseshop.python.org/packages/2.4/s/setuptools/ setuptools-0.6b3-py2.4.egg and place it in this directory before rerunning this script.) ------------------------------------------------------------------------ --- Downloading http://cheeseshop.python.org/packages/2.4/s/setuptools/ setuptools-0.6b3-py2.4.egg Traceback (most recent call last): File "setup.py", line 89, in ? zip_safe=False, File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ python2.4/distutils/core.py", line 110, in setup _setup_distribution = dist = klass(attrs) File "/Users/dan/Desktop/py2appSVN/trunk/setuptools-0.6b3- py2.4.egg/setuptools/dist.py", line 219, in __init__ File "/Users/dan/Desktop/py2appSVN/trunk/setuptools-0.6b3- py2.4.egg/setuptools/dist.py", line 242, in fetch_build_eggs File "/Users/dan/Desktop/py2appSVN/trunk/setuptools-0.6b3- py2.4.egg/pkg_resources.py", line 481, in resolve File "/Users/dan/Desktop/py2appSVN/trunk/setuptools-0.6b3- py2.4.egg/pkg_resources.py", line 717, in best_match File "/Users/dan/Desktop/py2appSVN/trunk/setuptools-0.6b3- py2.4.egg/pkg_resources.py", line 729, in obtain File "/Users/dan/Desktop/py2appSVN/trunk/setuptools-0.6b3- py2.4.egg/setuptools/dist.py", line 274, in fetch_build_egg AttributeError: Distribution instance has no attribute 'dependency_links' white:~/Desktop/py2appSVN/trunk dan$ Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From ronaldoussoren at mac.com Wed Jun 14 16:01:44 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 14 Jun 2006 16:01:44 +0200 Subject: [Pythonmac-SIG] py2app SVN - install error In-Reply-To: <314E8EB2-1462-4870-B04D-A481CACDF5E7@chalkie.org.uk> References: <314E8EB2-1462-4870-B04D-A481CACDF5E7@chalkie.org.uk> Message-ID: <11312619.1150293704474.JavaMail.ronaldoussoren@mac.com> On Wednesday, June 14, 2006, at 03:41PM, Dan White wrote: >Hi Bob, > >i checked out the py2app SVN onto my MacBookPro with the universal >python2.4 installed > >The py2app install instructions say run >python setup.py bdist_mpkg --open >but that gives me an error after it downloads the egg, see below, > >am I doing something wrong? You checked out the wrong version. The current stable version can be checked out the URL below: http://svn.red-bean.com/bob/py2app/branches/py2app-0.2-maint The trunk contains unfinished work in progres. Ronald From dan at chalkie.org.uk Wed Jun 14 16:58:07 2006 From: dan at chalkie.org.uk (Dan White) Date: Wed, 14 Jun 2006 17:58:07 +0300 Subject: [Pythonmac-SIG] OSX on intel, py2app 0.2 maint wxPython2.6.3.2rc3-universal10.4-py24.dmg .rsrc file missing In-Reply-To: <74F95C3C-7A83-42E1-A1C8-B2494B405EFB@tulane.edu> References: <1147915537.16558.ezmlm@lists.wxwidgets.org> <3B53D06F-CA49-4262-9FDF-CEFC31959A9E@chalkie.org.uk> <62D6CDF9-723B-4601-AD5D-BB9BEAC843CF@chalkie.org.uk> <7FE50739-C2C1-48AB-A82C-2033BF8F3037@chalkie.org.uk> <74F95C3C-7A83-42E1-A1C8-B2494B405EFB@tulane.edu> Message-ID: Hi Kevin and all, > Please try the following build: > > http://kevino.theolliviers.com/wxpython/wxPython2.6-osx- > unicode-2.6.3.2rc3-universal10.4-py2.4.dmg > > It does link against the wx libraries now, but I realized that > PyOpenGL (even CVS) won't build for Universal Python, at least not > out of the box, so I wasn't able to test it via the demo. If this > does fix your problem, I'll upload the release to the wxPython site. > > Otherwise, I'd suggest trying the PPC build on the Intel Mac. In a > vast majority of cases, things run just fine, albeit a bit slower. > The PyOpenGL problems seem to be long-standing, and there are other > extensions as well that really haven't made the transition to > Universal Python yet. To be completely honest, I don't see > Universal Python building a majority of Python C extensions for > several more months. If you really need the extra speed, or your > app is fairly simple, Universal Python is probably worth investing > in, but otherwise I'd just wait for all these issues to be sorted > out and let people use the PPC builds on Intel Mac. I have been testing your wxPython2.6-osx-unicode-2.6.3.2rc3- universal10.4-py2.4.dmg version of wxpython with universal python2.4 with our BioImageXD python and VTK driven software. Looking very good so far! Now I am trying to use py2app 0.2maint svn version to build the .app on intel core duo MacBook Pro. However, there is a command in our code to make py2app look for a rsrc file for wxPython. This file is not present in your 2.6.3.2rc3- universal10.4-py2.4.dmg DATA_FILES.append( ('../Frameworks', [ '/usr/local/lib/wxPython-unicode-2.5.5.1/lib/ libwx_macud-2.5.5.rsrc', ])) Do I still need this append ? cheers Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From dan at chalkie.org.uk Wed Jun 14 17:01:04 2006 From: dan at chalkie.org.uk (Dan White) Date: Wed, 14 Jun 2006 18:01:04 +0300 Subject: [Pythonmac-SIG] py2app with libraries compiled with intel compilers, intel libguide.dylib not included Message-ID: Hi Python Mac folks, I am using intel compilers to make VTK dylibs, then py2app 0.2 maint svn version to make a .app bundle When I run the .app that i am making it complains about not being able to find one of the intel compiler .dylib s libguide.dylib which is found at /opt/intel/cc/9.1.024/lib/libguide.dylib how do I get py2app to include this dylib correctly so the vtk libs can see it as they do when I run my app from the command line? Adding libguide.dylib to the .app/Contents/Frameworks/ dir does not solve the problem, does py2app need to know about /opt/intel/cc/9.1.024/lib ? any clues? cheers Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From bob at redivi.com Wed Jun 14 17:18:10 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 14 Jun 2006 08:18:10 -0700 Subject: [Pythonmac-SIG] py2app crash if path contains a colon In-Reply-To: <3508427.1150278697824.JavaMail.ronaldoussoren@mac.com> References: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> <4F891AB0-7AEB-411B-9B84-2339166FE9B7@redivi.com> <3508427.1150278697824.JavaMail.ronaldoussoren@mac.com> Message-ID: <38A1EEA3-E655-407A-BDF3-E7F2152DE46A@redivi.com> python itself needs to be in a directory containing a colon. bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print sys.path" 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', 'colon/../Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat- darwin', '/Users/bob/src/python/', 'colon/../Lib/plat-mac', '/Users/ bob/src/python/', 'colon/../Lib/plat-mac/lib-scriptpackages', '/Users/ bob/src/python/', 'colon/../Lib/lib-tk', '/Users/bob/src/python/', 'colon/Modules'] -bob On Jun 14, 2006, at 2:51 AM, Ronald Oussoren wrote: > Could either of you file a bug about this (the sys.path mangling > when there's a colon in the directory that contains the executable) > on python's SF tracker? Preferably including decription of how to > reproduce this. > > Bob, I've created a directory 'test:dir' and added a script named > 'test.py' in that directory that prints sys.path. If I run 'python > test:dir/test.py' sys.path[0] looks correct (including the colon in > test:dir). > > Ronald > > On Wednesday, June 14, 2006, at 10:21AM, Bob Ippolito > wrote: > >> On Jun 12, 2006, at 4:52 PM, Bob Swerdlow wrote: >> >>> Hi, our app is using py2app 0.2.1 and we've been quite happy with >>> it - >>> thanks! >>> >>> However, we have found that it crashes if the application is >>> started in a >>> folder whose name contains a colon. Of course, the Finder does not >>> allow >>> the user to use a colon in file names, but other applications do. >>> According >>> to the user: >> >> In Carbon APIs, these colons are represented by '/' (the POSIX path >> delimiter)... from Finder (and I think also at the lowest level HFS+ >> APIs), that path looks like "6/10/06". Anything using the POSIX APIs >> is going to see "6:10:06" though. >> >>> Is this a known problem? Is there a work-around? >> >> It's a problem with Python actually, which persists even in the >> trunk. Probably because a colon is often treated as a delimiter for a >> list of paths (such as the PATH or PYTHONPATH environment variables). >> If you run Python from a path containing ':' and look at sys.path, >> you'll see that the paths that would've contained a colon are >> mangled. I'm not sure where this happens and I don't have time to >> track it down at the moment. >> >> It won't be possible to work around this without patching the Python >> interpreter. For now you'll just have to tell your users Don't Do >> That. I can only think of two workarounds: >> (1) just tell the user that they can't run the app from a path >> containing a ":" in a relatively friendly manner (could be done in >> the py2app bootstrap). >> (2) make a symlink somewhere from the py2app bootstrap if a ":" is in >> the working directory and re-exec. >> >> I'm unlikely to do either of those things any time soon, but patches >> are accepted. If you come up with a patch for Python, file it on >> sourceforge and shoot a message referencing it here and someone will >> definitely apply it. I'd hurry up though, because Python 2.5 is >> pretty far along. >> >> -bob >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> From bob at redivi.com Wed Jun 14 17:26:03 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 14 Jun 2006 08:26:03 -0700 Subject: [Pythonmac-SIG] py2app with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: References: Message-ID: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> On Jun 14, 2006, at 8:01 AM, Dan White wrote: > Hi Python Mac folks, > > I am using intel compilers to make VTK dylibs, > then py2app 0.2 maint svn version to make a .app bundle > > When I run the .app that i am making it complains about not being > able to find one of the intel compiler .dylib s > libguide.dylib > which is found at > /opt/intel/cc/9.1.024/lib/libguide.dylib > > how do I get py2app to include this dylib correctly so the vtk libs > can see it as they do when I run my app from the command line? Could you please paste the actual error messages? Also, do you have any DYLD_* environment variables set? -bob From dan at chalkie.org.uk Thu Jun 15 09:28:10 2006 From: dan at chalkie.org.uk (Dan White) Date: Thu, 15 Jun 2006 10:28:10 +0300 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> Message-ID: On 14 Jun 2006, at 18:26, Bob Ippolito wrote: > > On Jun 14, 2006, at 8:01 AM, Dan White wrote: > >> Hi Python Mac folks, >> >> I am using intel compilers to make VTK dylibs, >> then py2app 0.2 maint svn version to make a .app bundle >> >> When I run the .app that i am making it complains about not being >> able to find one of the intel compiler .dylib s >> libguide.dylib >> which is found at >> /opt/intel/cc/9.1.024/lib/libguide.dylib >> >> how do I get py2app to include this dylib correctly so the vtk libs >> can see it as they do when I run my app from the command line? > > Could you please paste the actual error messages? Also, do you have > any DYLD_* environment variables set? here you go Bob, from the error message python/BioImageXD.app pops up on failed launch: An unexpected error has occurred during execution of the main script ImportError: Failure linking new module: /Users/dan/Desktop/ bioimagexdsvn/trunk/dist/BioImageXD.app/Contents/Resources/Python/lib- dynload/vtk/libvtkCommonPython.so: Library not loaded: libguide.dylib Referenced from: /Users/dan/Desktop/bioimagexdsvn/trunk/dist/ BioImageXD.app/Contents/MacOS/../Frameworks/libvtkCommonPythonD.dylib. 5.1 Reason: image not found See the Console for a detailed traceback. and from the console 2006-06-15 10:18:39.707 BioImageXD[294] BioImageXD Error 2006-06-15 10:18:39.707 BioImageXD[294] An unexpected error has occurred during execution of the main script ImportError: Failure linking new module: /Users/dan/Desktop/ bioimagexdsvn/trunk/dist/BioImageXD.app/Contents/Resources/Python/lib- dynload/vtk/libvtkCommonPython.so: Library not loaded: libguide.dylib Referenced from: /Users/dan/Desktop/bioimagexdsvn/trunk/dist/ BioImageXD.app/Contents/MacOS/../Frameworks/libvtkCommonPythonD.dylib. 5.1 Reason: image not found See the Console for a detailed traceback. 2006-06-15 10:18:39.836 BioImageXD[294] *** -[NSBundle load]: Error loading code /Users/dan/Library/InputManagers/Smart Crash Reports/ Smart Crash Reports.bundle/Contents/MacOS/Smart Crash Reports for bundle /Users/dan/Library/InputManagers/Smart Crash Reports/Smart Crash Reports.bundle, error code 2 (link edit error code 4, error number 0 ()) 2006-06-15 10:18:52.656 BioImageXD[294] CFLog (21): dyld returns 2 when trying to load /Users/dan/Library/Contextual Menu Items/ ToastIt.plugin/Contents/MacOS/ToastIt 2006-06-15 10:18:52.657 BioImageXD[294] CFLog (22): Cannot find function pointer pluginFactory for factory 053918F4-2869-11D7- A671-000A27E2DB90 in CFBundle/CFPlugIn 0x3b72f0 (bundle, not loaded) 2006-06-15 10:19:46.868 Console[299] *** -[NSBundle load]: Error loading code /Users/dan/Library/InputManagers/Smart Crash Reports/ Smart Crash Reports.bundle/Contents/MacOS/Smart Crash Reports for bundle /Users/dan/Library/InputManagers/Smart Crash Reports/Smart Crash Reports.bundle, error code 2 (link edit error code 0, error number 0 ()) This is a new computer, and I haven't set many env variables yet white:~ dan$ echo $DYLD_* Desktop Documents Downloads Incomplete Library Movies Music Network Trash Folder Pictures Public Shared Sites TheVolumeSettingsFolder mbox white:~ dan$ and my .bashrc has to be manually called, since its supposed to br named .profile right? anyway my .bashrc contains only source /opt/intel/cc/9.1.024/bin/iccvars.sh export PATH=$PATH:/usr/local/bin:/Library/Frameworks/Python.framework/ Versions/2.4/bin/ ahh haaa, but iccvars.sh contains this: #! /bin/sh if [ -z "${PATH}" ] then PATH="/opt/intel/cc/9.1.024/bin"; export PATH else PATH="/opt/intel/cc/9.1.024/bin:${PATH}"; export PATH fi if [ -z "${LD_LIBRARY_PATH}" ] then LD_LIBRARY_PATH="/opt/intel/cc/9.1.024/lib"; export LD_LIBRARY_PATH else LD_LIBRARY_PATH="/opt/intel/cc/9.1.024/lib:${LD_LIBRARY_PATH}"; export LD_LIBRARY_PATH fi # DYLD_LIBRARY_PATH is used on MAC OS if [ -z "${DYLD_LIBRARY_PATH}" ] then DYLD_LIBRARY_PATH="/opt/intel/cc/9.1.024/lib"; export DYLD_LIBRARY_PATH else DYLD_LIBRARY_PATH="/opt/intel/cc/9.1.024/lib:$ {DYLD_LIBRARY_PATH}"; export DYLD_LIBRARY_PATH fi if [ -z "${MANPATH}" ] then MANPATH="/opt/intel/cc/9.1.024/man":$(manpath); export MANPATH else MANPATH="/opt/intel/cc/9.1.024/man:${MANPATH}"; export MANPATH fi if [ -z "${INTEL_LICENSE_FILE}" ] then INTEL_LICENSE_FILE="/opt/intel/cc/9.1.024/licenses:/opt/intel/ licenses:${HOME}/intel/licenses:/Users/Shared/Library/Application Support/Intel/licenses"; export INTEL_LICENSE_FILE else INTEL_LICENSE_FILE="${INTEL_LICENSE_FILE}:/opt/intel/cc/9.1.024/ licenses:/opt/intel/licenses:${HOME}/intel/licenses:/Users/Shared/ Library/Application Support/Intel/licenses"; export INTEL_LICENSE_FILE fi So yes there are some DYLD_LIBRARY_PATH suff set. Maybe therein lies the problem...? Python probably doesn't know about that stuff? Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From ronaldoussoren at mac.com Thu Jun 15 09:55:21 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 15 Jun 2006 09:55:21 +0200 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> Message-ID: <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> On 15-jun-2006, at 9:28, Dan White wrote: > > > So yes there are some DYLD_LIBRARY_PATH suff set. > > Maybe therein lies the problem...? > Python probably doesn't know about that stuff? That might be the problem, and seems to indicate that Intel does something completely wrong. Any use of the DYLD_* variables in a production environment is an indication that something fishy is going on. Unlike linux executables on osx contain the full path to libraries they link to. If DYLD_LIBRARY_PATH is needed the compiler doesn't include the full path to some libraries that are needed. It should be possible to teach py2app/macholib about this "feature" of the intel compiler, but you'll probably have to do that yourself. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060615/c49c13a3/attachment.bin From dan at chalkie.org.uk Thu Jun 15 10:38:01 2006 From: dan at chalkie.org.uk (Dan White) Date: Thu, 15 Jun 2006 11:38:01 +0300 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> Message-ID: <3F9DA4DD-CADB-42A8-9097-D320A83DD85D@chalkie.org.uk> On 15 Jun 2006, at 10:55, Ronald Oussoren wrote: > > On 15-jun-2006, at 9:28, Dan White wrote: > > >> >> >> So yes there are some DYLD_LIBRARY_PATH suff set. >> >> Maybe therein lies the problem...? >> Python probably doesn't know about that stuff? > > That might be the problem, and seems to indicate that Intel does > something completely wrong. Any use of the DYLD_* variables in a > production environment is an indication that something fishy is > going on. Unlike linux executables on osx contain the full path to > libraries they link to. If DYLD_LIBRARY_PATH is needed the compiler > doesn't include the full path to some libraries that are needed. It > should be possible to teach py2app/macholib about this "feature" of > the intel compiler, but you'll probably have to do that yourself. > > Ronald > Maybe since these are free testing compilers, bets version s essentially ... I should tell intel and they might even fix it! thanks for looking at it anyway Ronald cheers Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From bob at redivi.com Thu Jun 15 23:12:04 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 15 Jun 2006 14:12:04 -0700 Subject: [Pythonmac-SIG] py2app crash if path contains a colon In-Reply-To: <38A1EEA3-E655-407A-BDF3-E7F2152DE46A@redivi.com> References: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> <4F891AB0-7AEB-411B-9B84-2339166FE9B7@redivi.com> <3508427.1150278697824.JavaMail.ronaldoussoren@mac.com> <38A1EEA3-E655-407A-BDF3-E7F2152DE46A@redivi.com> Message-ID: <70BC0978-1532-49A3-B611-7D9391290CD7@redivi.com> FWIW, this isn't at all Mac OS X specific.. $ uname -rs && pwd && ./python -c "import sys; print sys.path" FreeBSD 6.0-RELEASE /usr/home/bob/src/python/:colon 'import site' failed; use -v for traceback ['', '/usr/local/lib/python25.zip', '/usr/home/bob/src/python/', 'colon/../Lib/', '/usr/home/bob/src/python/', 'colon/../Lib/plat- freebsd6', '/usr/home/bob/src/python/', 'colon/../Lib/lib-tk', '/usr/ home/bob/src/python/', 'colon/Modules'] The issue is of course that all this code is happening in C and expecting ':' as the delimiter. Modules/getpath.c probably should be refactored to use PyObject* ASAP, rather than doing it last. -bob On Jun 14, 2006, at 8:18 AM, Bob Ippolito wrote: > python itself needs to be in a directory containing a colon. > > bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print > sys.path" > 'import site' failed; use -v for traceback > ['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', > 'colon/../Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat- > darwin', '/Users/bob/src/python/', 'colon/../Lib/plat-mac', '/Users/ > bob/src/python/', 'colon/../Lib/plat-mac/lib-scriptpackages', '/Users/ > bob/src/python/', 'colon/../Lib/lib-tk', '/Users/bob/src/python/', > 'colon/Modules'] > > -bob > > On Jun 14, 2006, at 2:51 AM, Ronald Oussoren wrote: > >> Could either of you file a bug about this (the sys.path mangling >> when there's a colon in the directory that contains the executable) >> on python's SF tracker? Preferably including decription of how to >> reproduce this. >> >> Bob, I've created a directory 'test:dir' and added a script named >> 'test.py' in that directory that prints sys.path. If I run 'python >> test:dir/test.py' sys.path[0] looks correct (including the colon in >> test:dir). >> >> Ronald >> >> On Wednesday, June 14, 2006, at 10:21AM, Bob Ippolito >> wrote: >> >>> On Jun 12, 2006, at 4:52 PM, Bob Swerdlow wrote: >>> >>>> Hi, our app is using py2app 0.2.1 and we've been quite happy with >>>> it - >>>> thanks! >>>> >>>> However, we have found that it crashes if the application is >>>> started in a >>>> folder whose name contains a colon. Of course, the Finder does not >>>> allow >>>> the user to use a colon in file names, but other applications do. >>>> According >>>> to the user: >>> >>> In Carbon APIs, these colons are represented by '/' (the POSIX path >>> delimiter)... from Finder (and I think also at the lowest level HFS+ >>> APIs), that path looks like "6/10/06". Anything using the POSIX APIs >>> is going to see "6:10:06" though. >>> >>>> Is this a known problem? Is there a work-around? >>> >>> It's a problem with Python actually, which persists even in the >>> trunk. Probably because a colon is often treated as a delimiter >>> for a >>> list of paths (such as the PATH or PYTHONPATH environment >>> variables). >>> If you run Python from a path containing ':' and look at sys.path, >>> you'll see that the paths that would've contained a colon are >>> mangled. I'm not sure where this happens and I don't have time to >>> track it down at the moment. >>> >>> It won't be possible to work around this without patching the Python >>> interpreter. For now you'll just have to tell your users Don't Do >>> That. I can only think of two workarounds: >>> (1) just tell the user that they can't run the app from a path >>> containing a ":" in a relatively friendly manner (could be done in >>> the py2app bootstrap). >>> (2) make a symlink somewhere from the py2app bootstrap if a ":" >>> is in >>> the working directory and re-exec. >>> >>> I'm unlikely to do either of those things any time soon, but patches >>> are accepted. If you come up with a patch for Python, file it on >>> sourceforge and shoot a message referencing it here and someone will >>> definitely apply it. I'd hurry up though, because Python 2.5 is >>> pretty far along. >>> >>> -bob >>> >>> _______________________________________________ >>> 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 bob at redivi.com Thu Jun 15 23:21:05 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 15 Jun 2006 14:21:05 -0700 Subject: [Pythonmac-SIG] py2app crash if path contains a colon In-Reply-To: <70BC0978-1532-49A3-B611-7D9391290CD7@redivi.com> References: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> <4F891AB0-7AEB-411B-9B84-2339166FE9B7@redivi.com> <3508427.1150278697824.JavaMail.ronaldoussoren@mac.com> <38A1EEA3-E655-407A-BDF3-E7F2152DE46A@redivi.com> <70BC0978-1532-49A3-B611-7D9391290CD7@redivi.com> Message-ID: On Jun 15, 2006, at 2:12 PM, Bob Ippolito wrote: > FWIW, this isn't at all Mac OS X specific.. > > $ uname -rs && pwd && ./python -c "import sys; print sys.path" > FreeBSD 6.0-RELEASE > /usr/home/bob/src/python/:colon > 'import site' failed; use -v for traceback > ['', '/usr/local/lib/python25.zip', '/usr/home/bob/src/python/', > 'colon/../Lib/', '/usr/home/bob/src/python/', 'colon/../Lib/plat- > freebsd6', '/usr/home/bob/src/python/', 'colon/../Lib/lib-tk', '/usr/ > home/bob/src/python/', 'colon/Modules'] > > The issue is of course that all this code is happening in C and > expecting ':' as the delimiter. Modules/getpath.c probably should be > refactored to use PyObject* ASAP, rather than doing it last. Well, it looks like that's not such a good idea either, because Py_GetPath() is called before Python's fully initialized. Any exception would probably make the interpreter explode. Hmm :) -bob From ronaldoussoren at mac.com Fri Jun 16 13:24:28 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 16 Jun 2006 13:24:28 +0200 Subject: [Pythonmac-SIG] py2app crash if path contains a colon In-Reply-To: <38A1EEA3-E655-407A-BDF3-E7F2152DE46A@redivi.com> References: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> <4F891AB0-7AEB-411B-9B84-2339166FE9B7@redivi.com> <3508427.1150278697824.JavaMail.ronaldoussoren@mac.com> <38A1EEA3-E655-407A-BDF3-E7F2152DE46A@redivi.com> Message-ID: <4383228.1150457068750.JavaMail.ronaldoussoren@mac.com> On Wednesday, June 14, 2006, at 05:18PM, Bob Ippolito wrote: >python itself needs to be in a directory containing a colon. > >bump:~/src/python/:colon bob$ ./python.exe -c "import sys; print >sys.path" >'import site' failed; use -v for traceback >['', '/usr/local/lib/python25.zip', '/Users/bob/src/python/', >'colon/../Lib/', '/Users/bob/src/python/', 'colon/../Lib/plat- >darwin', '/Users/bob/src/python/', 'colon/../Lib/plat-mac', '/Users/ >bob/src/python/', 'colon/../Lib/plat-mac/lib-scriptpackages', '/Users/ >bob/src/python/', 'colon/../Lib/lib-tk', '/Users/bob/src/python/', >'colon/Modules'] This is now python bug #1507224. It might be possible to work around this in py2app's executable stub, I don't have time to look at this at the moment. Ronald From kw at kevin-walzer.com Fri Jun 16 18:40:33 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Fri, 16 Jun 2006 12:40:33 -0400 Subject: [Pythonmac-SIG] Can't build 2.4.3 against X11 Tcl/Tk Message-ID: <4492DF01.6000907@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a new twist on an old problem. I'm trying to build a standard Unix version of Python (without - -enable-framework) and link it against an X11-based version of Tcl/Tk. However, no matter what I do, it builds against the system-installed Tk/Aqua. Googling for some solutions to this problem has turned up lots of complaints about Python linking against an X11 version of Tk (usually Fink's). How far we've come! :-) Anyway, here are the flags I'm using to run the build: export CFLAGS="-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 - -I/usr/local/tcl-tk-unix/include" export LDFLAGS="-L/usr/local/tcl-tk-unix/lib" ./configure --prefix=/usr/local/python-unix --enable-threads I know it would be simple to use a Fink or DarwinPorts version of Python, but I want this version to link against the universal X11 build of Tcl/Tk I have installed. Any advice? - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkt8BrTC5hIgjqTMRAklrAJ9ud55r7wCpdqfg4XN08OCUCoKkPwCfRiTH LYSEzUFUWuaEdynMTHM2sd8= =rltL -----END PGP SIGNATURE----- From bob at redivi.com Fri Jun 16 19:07:19 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 16 Jun 2006 10:07:19 -0700 Subject: [Pythonmac-SIG] Can't build 2.4.3 against X11 Tcl/Tk In-Reply-To: <4492DF01.6000907@kevin-walzer.com> References: <4492DF01.6000907@kevin-walzer.com> Message-ID: <4328DD29-4AA4-4535-8EE4-2214818C2470@redivi.com> On Jun 16, 2006, at 9:40 AM, Kevin Walzer wrote: > This is a new twist on an old problem. > > I'm trying to build a standard Unix version of Python (without > - -enable-framework) and link it against an X11-based version of > Tcl/Tk. > However, no matter what I do, it builds against the system-installed > Tk/Aqua. > > Googling for some solutions to this problem has turned up lots of > complaints about Python linking against an X11 version of Tk (usually > Fink's). How far we've come! :-) > > Anyway, here are the flags I'm using to run the build: > > export CFLAGS="-arch ppc -arch i386 -isysroot > /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 > - -I/usr/local/tcl-tk-unix/include" > > export LDFLAGS="-L/usr/local/tcl-tk-unix/lib" > > > ./configure --prefix=/usr/local/python-unix --enable-threads > > I know it would be simple to use a Fink or DarwinPorts version of > Python, but I want this version to link against the universal X11 > build > of Tcl/Tk I have installed. > > Any advice? Edit setup.py, remove the "if platform == 'darwin': self.detect_tkinter_darwin..." -bob From ronaldoussoren at mac.com Fri Jun 16 09:21:03 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 16 Jun 2006 09:21:03 +0200 Subject: [Pythonmac-SIG] py2app crash if path contains a colon In-Reply-To: References: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> <4F891AB0-7AEB-411B-9B84-2339166FE9B7@redivi.com> <3508427.1150278697824.JavaMail.ronaldoussoren@mac.com> <38A1EEA3-E655-407A-BDF3-E7F2152DE46A@redivi.com> <70BC0978-1532-49A3-B611-7D9391290CD7@redivi.com> Message-ID: <3EDD8D55-FB95-4A5D-A56A-E6C04553435A@mac.com> On 15-jun-2006, at 23:21, Bob Ippolito wrote: > > On Jun 15, 2006, at 2:12 PM, Bob Ippolito wrote: > >> FWIW, this isn't at all Mac OS X specific.. >> >> $ uname -rs && pwd && ./python -c "import sys; print sys.path" >> FreeBSD 6.0-RELEASE >> /usr/home/bob/src/python/:colon >> 'import site' failed; use -v for traceback >> ['', '/usr/local/lib/python25.zip', '/usr/home/bob/src/python/', >> 'colon/../Lib/', '/usr/home/bob/src/python/', 'colon/../Lib/plat- >> freebsd6', '/usr/home/bob/src/python/', 'colon/../Lib/lib-tk', '/usr/ >> home/bob/src/python/', 'colon/Modules'] >> >> The issue is of course that all this code is happening in C and >> expecting ':' as the delimiter. Modules/getpath.c probably should be >> refactored to use PyObject* ASAP, rather than doing it last. > > Well, it looks like that's not such a good idea either, because > Py_GetPath() is called before Python's fully initialized. Any > exception would probably make the interpreter explode. Hmm :) The most prudent thing to do right now is to file a bug at python's SF tracker and let someone else worry about this ;-). Wouldn't it be possible to set up the right sys.path in py2app's application stub to work around this issue? Ronald From bob at redivi.com Fri Jun 16 23:06:20 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 16 Jun 2006 14:06:20 -0700 Subject: [Pythonmac-SIG] py2app crash if path contains a colon In-Reply-To: <3EDD8D55-FB95-4A5D-A56A-E6C04553435A@mac.com> References: <00c601c68e7b$5232a450$066fa8c0@RSWERDLOW800> <4F891AB0-7AEB-411B-9B84-2339166FE9B7@redivi.com> <3508427.1150278697824.JavaMail.ronaldoussoren@mac.com> <38A1EEA3-E655-407A-BDF3-E7F2152DE46A@redivi.com> <70BC0978-1532-49A3-B611-7D9391290CD7@redivi.com> <3EDD8D55-FB95-4A5D-A56A-E6C04553435A@mac.com> Message-ID: On Jun 16, 2006, at 12:21 AM, Ronald Oussoren wrote: > > On 15-jun-2006, at 23:21, Bob Ippolito wrote: > >> >> On Jun 15, 2006, at 2:12 PM, Bob Ippolito wrote: >> >>> FWIW, this isn't at all Mac OS X specific.. >>> >>> $ uname -rs && pwd && ./python -c "import sys; print sys.path" >>> FreeBSD 6.0-RELEASE >>> /usr/home/bob/src/python/:colon >>> 'import site' failed; use -v for traceback >>> ['', '/usr/local/lib/python25.zip', '/usr/home/bob/src/python/', >>> 'colon/../Lib/', '/usr/home/bob/src/python/', 'colon/../Lib/plat- >>> freebsd6', '/usr/home/bob/src/python/', 'colon/../Lib/lib-tk', '/ >>> usr/ >>> home/bob/src/python/', 'colon/Modules'] >>> >>> The issue is of course that all this code is happening in C and >>> expecting ':' as the delimiter. Modules/getpath.c probably should be >>> refactored to use PyObject* ASAP, rather than doing it last. >> >> Well, it looks like that's not such a good idea either, because >> Py_GetPath() is called before Python's fully initialized. Any >> exception would probably make the interpreter explode. Hmm :) > > The most prudent thing to do right now is to file a bug at python's > SF tracker and let someone else worry about this ;-). > > Wouldn't it be possible to set up the right sys.path in py2app's > application stub to work around this issue? Maybe in the C part of the code.. by the time any Python code executes it's already failed to load site. -bob From kevino at tulane.edu Wed Jun 14 19:44:05 2006 From: kevino at tulane.edu (Kevin Ollivier) Date: Wed, 14 Jun 2006 10:44:05 -0700 Subject: [Pythonmac-SIG] OSX on intel, py2app 0.2 maint wxPython2.6.3.2rc3-universal10.4-py24.dmg .rsrc file missing In-Reply-To: References: <1147915537.16558.ezmlm@lists.wxwidgets.org> <3B53D06F-CA49-4262-9FDF-CEFC31959A9E@chalkie.org.uk> <62D6CDF9-723B-4601-AD5D-BB9BEAC843CF@chalkie.org.uk> <7FE50739-C2C1-48AB-A82C-2033BF8F3037@chalkie.org.uk> <74F95C3C-7A83-42E1-A1C8-B2494B405EFB@tulane.edu> Message-ID: <8BAD3F8B-9E29-4A20-B272-EC2137B7F82B@tulane.edu> Hi Dan, On Jun 14, 2006, at 7:58 AM, Dan White wrote: > Hi Kevin and all, > >> Please try the following build: >> >> http://kevino.theolliviers.com/wxpython/wxPython2.6-osx- >> unicode-2.6.3.2rc3-universal10.4-py2.4.dmg >> >> It does link against the wx libraries now, but I realized that >> PyOpenGL (even CVS) won't build for Universal Python, at least not >> out of the box, so I wasn't able to test it via the demo. If this >> does fix your problem, I'll upload the release to the wxPython site. >> >> Otherwise, I'd suggest trying the PPC build on the Intel Mac. In a >> vast majority of cases, things run just fine, albeit a bit slower. >> The PyOpenGL problems seem to be long-standing, and there are other >> extensions as well that really haven't made the transition to >> Universal Python yet. To be completely honest, I don't see >> Universal Python building a majority of Python C extensions for >> several more months. If you really need the extra speed, or your >> app is fairly simple, Universal Python is probably worth investing >> in, but otherwise I'd just wait for all these issues to be sorted >> out and let people use the PPC builds on Intel Mac. > > > I have been testing your wxPython2.6-osx-unicode-2.6.3.2rc3- > universal10.4-py2.4.dmg version of wxpython with universal python2.4 > with our BioImageXD python and VTK driven software. > > Looking very good so far! Glad to hear it! > Now I am trying to use py2app 0.2maint svn version > to build the .app on intel core duo MacBook Pro. > > However, there is a command in our code to make py2app look for a > rsrc file for wxPython. This file is not present in your 2.6.3.2rc3- > universal10.4-py2.4.dmg > > DATA_FILES.append( ('../Frameworks', [ > '/usr/local/lib/wxPython-unicode-2.5.5.1/lib/ > libwx_macud-2.5.5.rsrc', > ])) > > Do I still need this append ? No, you no longer need it. :-) Regards, Kevin > cheers > > Dan > > > > Dr. Daniel James White BSc. (Hons.) PhD > Bioimaging Coordinator > Nanoscience Centre and Department of Biological and Environmental > Sciences > Division of Molecular Recognition > Ambiotica C242 > PO Box 35 > University of Jyv?skyl? > Jyv?skyl? > FIN 40014 > Finland > > +358 14 260 4183 (work) > +358 468102840 (mobile) > http://www.bioimagexd.org > http://www.chalkie.org.uk > dan at chalkie.org.uk > white at cc.jyu.fi > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From kiaup at mac.com Thu Jun 15 03:15:49 2006 From: kiaup at mac.com (Roberta Mintz) Date: Wed, 14 Jun 2006 21:15:49 -0400 Subject: [Pythonmac-SIG] $PYTHON and path variables? Is this Tad from Alexandria? Message-ID: <4c3b2053c6770b91f24d59885f00227e@mac.com> From Sexyblondenj36s at aol.com Thu Jun 15 16:32:46 2006 From: Sexyblondenj36s at aol.com (Sexyblondenj36s at aol.com) Date: Thu, 15 Jun 2006 10:32:46 EDT Subject: [Pythonmac-SIG] Packman Question Message-ID: <4bb.1a8e6f3.31c2c98e@aol.com> is this craig packman from margate nj thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060615/1b1b68e9/attachment.htm From kw at kevin-walzer.com Sun Jun 18 01:18:53 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Sat, 17 Jun 2006 19:18:53 -0400 Subject: [Pythonmac-SIG] Can't build 2.4.3 against X11 Tcl/Tk In-Reply-To: <4328DD29-4AA4-4535-8EE4-2214818C2470@redivi.com> References: <4492DF01.6000907@kevin-walzer.com> <4328DD29-4AA4-4535-8EE4-2214818C2470@redivi.com> Message-ID: <44948DDD.609@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bob Ippolito wrote: > > On Jun 16, 2006, at 9:40 AM, Kevin Walzer wrote: > >> This is a new twist on an old problem. >> >> I'm trying to build a standard Unix version of Python (without >> - -enable-framework) and link it against an X11-based version of Tcl/Tk. >> However, no matter what I do, it builds against the system-installed >> Tk/Aqua. >> >> Googling for some solutions to this problem has turned up lots of >> complaints about Python linking against an X11 version of Tk (usually >> Fink's). How far we've come! :-) >> >> Anyway, here are the flags I'm using to run the build: >> >> export CFLAGS="-arch ppc -arch i386 -isysroot >> /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 >> - -I/usr/local/tcl-tk-unix/include" >> >> export LDFLAGS="-L/usr/local/tcl-tk-unix/lib" >> >> >> ./configure --prefix=/usr/local/python-unix --enable-threads >> >> I know it would be simple to use a Fink or DarwinPorts version of >> Python, but I want this version to link against the universal X11 build >> of Tcl/Tk I have installed. >> >> Any advice? > > Edit setup.py, remove the "if platform == 'darwin': > self.detect_tkinter_darwin..." > > -bob > > > I've done this, and it builds, but not universal. This holds true for both the universal "fat" code in SVN and for the official 2.4.3 distro from Python.org--it's PPC only. Is there anything special I can look at, apart from the flags above? I've confirmed that the Tcl/Tk libs I'm linking against are universal: /usr/local/tcl-tk-unix/bin/tclsh8.4: Mach-O fat file with 2 architectures /usr/local/tcl-tk-unix/bin/tclsh8.4 (for architecture ppc): Mach-O executable ppc /usr/local/tcl-tk-unix/bin/tclsh8.4 (for architecture i386): Mach-O executable i386 - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElI3crTC5hIgjqTMRAnomAJ9uGdbDvyPJh1RbekztB8fdp7nh/gCgiI7k zUtL/Qd0EG8ty1BSi566Fek= =MTRS -----END PGP SIGNATURE----- From bob at redivi.com Sun Jun 18 04:51:35 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 17 Jun 2006 19:51:35 -0700 Subject: [Pythonmac-SIG] Can't build 2.4.3 against X11 Tcl/Tk In-Reply-To: <44948DDD.609@kevin-walzer.com> References: <4492DF01.6000907@kevin-walzer.com> <4328DD29-4AA4-4535-8EE4-2214818C2470@redivi.com> <44948DDD.609@kevin-walzer.com> Message-ID: On Jun 17, 2006, at 4:18 PM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Bob Ippolito wrote: >> >> On Jun 16, 2006, at 9:40 AM, Kevin Walzer wrote: >> >>> This is a new twist on an old problem. >>> >>> I'm trying to build a standard Unix version of Python (without >>> - -enable-framework) and link it against an X11-based version of >>> Tcl/Tk. >>> However, no matter what I do, it builds against the system-installed >>> Tk/Aqua. >>> >>> Googling for some solutions to this problem has turned up lots of >>> complaints about Python linking against an X11 version of Tk >>> (usually >>> Fink's). How far we've come! :-) >>> >>> Anyway, here are the flags I'm using to run the build: >>> >>> export CFLAGS="-arch ppc -arch i386 -isysroot >>> /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 >>> - -I/usr/local/tcl-tk-unix/include" >>> >>> export LDFLAGS="-L/usr/local/tcl-tk-unix/lib" >>> >>> >>> ./configure --prefix=/usr/local/python-unix --enable-threads >>> >>> I know it would be simple to use a Fink or DarwinPorts version of >>> Python, but I want this version to link against the universal X11 >>> build >>> of Tcl/Tk I have installed. >>> >>> Any advice? >> >> Edit setup.py, remove the "if platform == 'darwin': >> self.detect_tkinter_darwin..." >> >> -bob >> >> >> > I've done this, and it builds, but not universal. This holds true for > both the universal "fat" code in SVN and for the official 2.4.3 distro > from Python.org--it's PPC only. > > Is there anything special I can look at, apart from the flags above? > I've confirmed that the Tcl/Tk libs I'm linking against are universal: > > /usr/local/tcl-tk-unix/bin/tclsh8.4: Mach-O fat file with 2 > architectures > /usr/local/tcl-tk-unix/bin/tclsh8.4 (for architecture ppc): Mach-O > executable ppc > /usr/local/tcl-tk-unix/bin/tclsh8.4 (for architecture i386): Mach-O > executable i386 Universal builds are currently only supported --enable-framework -- enable-universalsdk. I doubt that TCL is the problem here. I don't know what it would take to get --enable-universalsdk to work without --enable-framework. Maybe it already does. It hasn't been tried and it's not yet supported. -bob From ronaldoussoren at mac.com Sun Jun 18 09:48:21 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 18 Jun 2006 09:48:21 +0200 Subject: [Pythonmac-SIG] Can't build 2.4.3 against X11 Tcl/Tk In-Reply-To: References: <4492DF01.6000907@kevin-walzer.com> <4328DD29-4AA4-4535-8EE4-2214818C2470@redivi.com> <44948DDD.609@kevin-walzer.com> Message-ID: On 18-jun-2006, at 4:51, Bob Ippolito wrote: > > On Jun 17, 2006, at 4:18 PM, Kevin Walzer wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Bob Ippolito wrote: >>> >>> On Jun 16, 2006, at 9:40 AM, Kevin Walzer wrote: >>> >>>> This is a new twist on an old problem. >>>> >>>> I'm trying to build a standard Unix version of Python (without >>>> - -enable-framework) and link it against an X11-based version of >>>> Tcl/Tk. >>>> However, no matter what I do, it builds against the system- >>>> installed >>>> Tk/Aqua. >>>> >>>> Googling for some solutions to this problem has turned up lots of >>>> complaints about Python linking against an X11 version of Tk >>>> (usually >>>> Fink's). How far we've come! :-) >>>> >>>> Anyway, here are the flags I'm using to run the build: >>>> >>>> export CFLAGS="-arch ppc -arch i386 -isysroot >>>> /Developer/SDKs/MacOSX10.4u.sdk -mmacosx-version-min=10.4 >>>> - -I/usr/local/tcl-tk-unix/include" >>>> >>>> export LDFLAGS="-L/usr/local/tcl-tk-unix/lib" >>>> >>>> >>>> ./configure --prefix=/usr/local/python-unix --enable-threads >>>> >>>> I know it would be simple to use a Fink or DarwinPorts version of >>>> Python, but I want this version to link against the universal X11 >>>> build >>>> of Tcl/Tk I have installed. >>>> >>>> Any advice? >>> >>> Edit setup.py, remove the "if platform == 'darwin': >>> self.detect_tkinter_darwin..." >>> >>> -bob >>> >>> >>> >> I've done this, and it builds, but not universal. This holds true for >> both the universal "fat" code in SVN and for the official 2.4.3 >> distro >> from Python.org--it's PPC only. >> >> Is there anything special I can look at, apart from the flags above? >> I've confirmed that the Tcl/Tk libs I'm linking against are >> universal: >> >> /usr/local/tcl-tk-unix/bin/tclsh8.4: Mach-O fat file with 2 >> architectures >> /usr/local/tcl-tk-unix/bin/tclsh8.4 (for architecture ppc): >> Mach-O >> executable ppc >> /usr/local/tcl-tk-unix/bin/tclsh8.4 (for architecture i386): >> Mach-O >> executable i386 > > Universal builds are currently only supported --enable-framework -- > enable-universalsdk. I doubt that TCL is the problem here. I don't > know what it would take to get --enable-universalsdk to work without > --enable-framework. Maybe it already does. It hasn't been tried and > it's not yet supported. For 2.5 --universalsdk also works for normal unix builds and I don't think I changed anything substantial for that. Are you (Kevin) sure that the build picks up the right copy of tcl/ tk? /usr/local/tcl-tk-unix/ isn't on the default search path and setup.py ignores extra CFLAGS and LDFLAGS when looking for libraries. Ronald From kw at kevin-walzer.com Sun Jun 18 15:54:22 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Sun, 18 Jun 2006 09:54:22 -0400 Subject: [Pythonmac-SIG] Can't build 2.4.3 against X11 Tcl/Tk In-Reply-To: References: <4492DF01.6000907@kevin-walzer.com> <4328DD29-4AA4-4535-8EE4-2214818C2470@redivi.com> <44948DDD.609@kevin-walzer.com> Message-ID: <44955B0E.4070502@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ronald Oussoren wrote: > > For 2.5 --universalsdk also works for normal unix builds and I don't > think I changed anything substantial for that. > > Are you (Kevin) sure that the build picks up the right copy of tcl/tk? > /usr/local/tcl-tk-unix/ isn't on the default search path and setup.py > ignores extra CFLAGS and LDFLAGS when looking for libraries. > > Why does it ignore extra CFLAGS and LDFLAGS? I see code in def detect_modules in setup.py that seems to register the extra flags: if platform == 'darwin': # Actually any unix-y platform will do :-) # This picks up additional library and include directories # from the user-specified CFLAGS. # XXX: shouldn't this be in distutils? opt, = sysconfig.get_config_vars('OPT') cppflags, = sysconfig.get_config_vars('CPPFLAGS') for item in (opt.split() + cppflags.split()): if item.startswith('-I'): inc_dirs.append(item[2:]) ldflags, = sysconfig.get_config_vars('LDFLAGS') for item in ldflags.split(): if item.startswith('-L'): lib_dirs.append(item[2:]) However, in light of what you've said, I've hacked the universal setup.py with some code from the current 2.4.3 setup.py that hard-codes some additional search paths for my specialized stuff (derived from code that searches for Fink and DarwinPorts): if sys.platform == "darwin": # kevin's custom build of tcl/tk installs add_dir_to_list(self.compiler.library_dirs, '/usr/local/tcl-tk-unix/lib') add_dir_to_list(self.compiler.include_dirs, '/usr/local/tcl-tk-unix/include') I will report back if this works. - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElVsNrTC5hIgjqTMRAnH9AJ9c7G3sE0yyWPMGX2wdPw/wfnA3NQCglJpy x89aLcnjn9B6kJscmt3eIVU= =t4v3 -----END PGP SIGNATURE----- From kw at kevin-walzer.com Sun Jun 18 16:30:01 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Sun, 18 Jun 2006 10:30:01 -0400 Subject: [Pythonmac-SIG] Can't build 2.4.3 against X11 Tcl/Tk In-Reply-To: <44955B0E.4070502@kevin-walzer.com> References: <4492DF01.6000907@kevin-walzer.com> <4328DD29-4AA4-4535-8EE4-2214818C2470@redivi.com> <44948DDD.609@kevin-walzer.com> <44955B0E.4070502@kevin-walzer.com> Message-ID: <44956369.70007@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Kevin Walzer wrote: > However, in light of what you've said, I've hacked the universal > setup.py with some code from the current 2.4.3 setup.py that hard-codes > some additional search paths for my specialized stuff (derived from code > that searches for Fink and DarwinPorts): > > if sys.platform == "darwin": > # kevin's custom build of tcl/tk installs > add_dir_to_list(self.compiler.library_dirs, > '/usr/local/tcl-tk-unix/lib') > add_dir_to_list(self.compiler.include_dirs, > '/usr/local/tcl-tk-unix/include') > > > I will report back if this works. Success! Kevin-Walzers-Computer:~/python24-fat kevin$ file /usr/local/python-unix/bin/python /usr/local/python-unix/bin/python: Mach-O fat file with 2 architectures /usr/local/python-unix/bin/python (for architecture ppc): Mach-O executable ppc /usr/local/python-unix/bin/python (for architecture i386): Mach-O executable i386 I used the hacked-up setup.py and also added the "--enable-universalsdk" and "prefix=/usr/local/python-unix". I still think the setup.py should recognize custom CFLAGS and LDFLAGS, but this was a successful workaround. Thanks to Ron and Bob for their advice--I wouldn't have figured this out by myself. - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElWNorTC5hIgjqTMRArJCAJoCy24MJNN+VuGRUMmvFAEDxTMcUgCeJLPV TpsnSU4ywHTvjvQFz683rCk= =rxw+ -----END PGP SIGNATURE----- From ronaldoussoren at mac.com Sun Jun 18 16:52:10 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 18 Jun 2006 16:52:10 +0200 Subject: [Pythonmac-SIG] Can't build 2.4.3 against X11 Tcl/Tk In-Reply-To: <44955B0E.4070502@kevin-walzer.com> References: <4492DF01.6000907@kevin-walzer.com> <4328DD29-4AA4-4535-8EE4-2214818C2470@redivi.com> <44948DDD.609@kevin-walzer.com> <44955B0E.4070502@kevin-walzer.com> Message-ID: <4237C0B4-F49F-4791-B473-98E0B0DE1DA0@mac.com> On 18-jun-2006, at 15:54, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ronald Oussoren wrote: >> > >> For 2.5 --universalsdk also works for normal unix builds and I don't >> think I changed anything substantial for that. >> >> Are you (Kevin) sure that the build picks up the right copy of tcl/ >> tk? >> /usr/local/tcl-tk-unix/ isn't on the default search path and setup.py >> ignores extra CFLAGS and LDFLAGS when looking for libraries. >> >> > > Why does it ignore extra CFLAGS and LDFLAGS? I see code in def > detect_modules in setup.py that seems to register the extra flags: > > if platform == 'darwin': > # Actually any unix-y platform will do :-) > # This picks up additional library and include directories > # from the user-specified CFLAGS. > # XXX: shouldn't this be in distutils? > opt, = sysconfig.get_config_vars('OPT') > cppflags, = sysconfig.get_config_vars('CPPFLAGS') > for item in (opt.split() + cppflags.split()): > if item.startswith('-I'): > inc_dirs.append(item[2:]) > ldflags, = sysconfig.get_config_vars('LDFLAGS') > for item in ldflags.split(): > if item.startswith('-L'): > lib_dirs.append(item[2:]) That's in 2.5 because I got annoyed by the build process not picking up sqlite and other 3th-party libraries when they are not in the expected location. This code isn't in 2.4. Ronald From kw at kevin-walzer.com Sun Jun 18 22:05:56 2006 From: kw at kevin-walzer.com (Kevin Walzer) Date: Sun, 18 Jun 2006 16:05:56 -0400 Subject: [Pythonmac-SIG] py2app with X11/Tkinter app Message-ID: <4495B224.6010309@kevin-walzer.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've installed py2app with my X11-based build of Python, and have tried to run the "hello world" sample. py2app fails with this error message: ValueError: '/usr/local/python-unix/lib/libpython2.4.dylib' does not exist > /usr/local/python-unix/lib/python2.4/site-packages/py2app/macholib/MachOGraph.py(58)run_file() - -> raise ValueError, '%r does not exist' % (pathname,) (Pdb) exit Is py2app compatible with non-framework builds of Python? If not, how do other people distribute X11 (non-framework) Python GUI applications? A pkg installer, or wrap everything manually in an app bundle with a stub launcher (such as those created by Platypus)? - -- Kevin Walzer Poetic Code http://www.kevin-walzer.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFElbIkrTC5hIgjqTMRAjDeAKCNC6lb+1dz1HACfYiM025FkzkLcACfUhec TvTyOrbKzfs46iGqc0HwetE= =9mNL -----END PGP SIGNATURE----- From bob at redivi.com Sun Jun 18 22:16:52 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 18 Jun 2006 13:16:52 -0700 Subject: [Pythonmac-SIG] py2app with X11/Tkinter app In-Reply-To: <4495B224.6010309@kevin-walzer.com> References: <4495B224.6010309@kevin-walzer.com> Message-ID: On Jun 18, 2006, at 1:05 PM, Kevin Walzer wrote: > I've installed py2app with my X11-based build of Python, and have > tried > to run the "hello world" sample. py2app fails with this error message: > > ValueError: '/usr/local/python-unix/lib/libpython2.4.dylib' does > not exist >> > /usr/local/python-unix/lib/python2.4/site-packages/py2app/macholib/ > MachOGraph.py(58)run_file() > - -> raise ValueError, '%r does not exist' % (pathname,) > (Pdb) exit > > Is py2app compatible with non-framework builds of Python? If not, > how do > other people distribute X11 (non-framework) Python GUI applications? A > pkg installer, or wrap everything manually in an app bundle with a > stub > launcher (such as those created by Platypus)? It was compatible with unix builds at one point, but it hasn't been tested with one in quite some time. If you figure out what the problem is, patches are definitely accepted. -bob From tbirch at cse.unsw.edu.au Mon Jun 19 12:30:22 2006 From: tbirch at cse.unsw.edu.au (Tom Birch) Date: Mon, 19 Jun 2006 20:30:22 +1000 Subject: [Pythonmac-SIG] Missing symbols in module compiled with distutils Message-ID: <40E16B9B-2B43-4E1C-9179-E7A0DA7DF71B@cse.unsw.edu.au> I'm just playing around with writing a Python wrapper for SearchKit, and when I was just getting the very basics down of the first class, I ran into this problem when importing my module: ImportError: Failure linking new module: /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/ pysearchkit.so: Symbol not found: _CFRelease Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/pysearchkit.so Expected in: dynamic lookup I went and double-checked my setup.py file: module1 = Extension('pysearchkit', extra_link_args = ['-framework CoreServices', '- framework CoreFoundation'], sources = ['module.c','index.c']) but I couldn't find any problem. I looked at the last link command and it seemed ok, I tried running it again manually and it didn't work: % gcc -bundle -undefined dynamic_lookup build/temp.darwin-8.6.0- Power_Macintosh-2.4/module.o build/temp.darwin-8.6.0- Power_Macintosh-2.4/index.o -o build/lib.darwin-8.6.0- Power_Macintosh-2.4/pysearchkit.so -framework CoreServices -framework CoreFoundation /usr/bin/ld: flag: -undefined dynamic_lookup can't be used with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 collect2: ld returned 1 exit status so I fixed that with adding 'MACOSX_DEPLOYMENT_TARGET=10.4' to the start, and it worked: % MACOSX_DEPLOYMENT_TARGET=10.4 gcc -bundle -undefined dynamic_lookup build/temp.darwin-8.6.0-Power_Macintosh-2.4/module.o build/ temp.darwin-8.6.0-Power_Macintosh-2.4/index.o -o build/ lib.darwin-8.6.0-Power_Macintosh-2.4/pysearchkit.so -framework CoreServices -framework CoreFoundation % Running 'sudo python setup.py install' after this results in an installed module that imports correctly, so I was wondering exactly what the issue is. I'm sure it's something to do with the environment passed to the link command, but a look at distutils.sysconfig.get_config_vars() didn't show up anything interesting (although I'm not an expert on ld). I was wondering if anyone had an idea as to why this is broken. I'm running python2.4 on ppc (installed as a framework), and interestingly enough it works fine with python2.3. Could this be a problem with my python2.4 install? I haven't had any problems with PyObjC and that seems to link things the same way as I am (and uses plenty of stuff in frameworks) so I'm at a complete loss as to what's happening here. The source for everything is available here if you want to try and replicate it: http://www.cse.unsw.edu.au/~tbirch/pysearchkit.tar.bz2 cheers, Tom From tbirch at cse.unsw.edu.au Mon Jun 19 13:10:58 2006 From: tbirch at cse.unsw.edu.au (Tom Birch) Date: Mon, 19 Jun 2006 21:10:58 +1000 Subject: [Pythonmac-SIG] Missing symbols in module compiled with distutils In-Reply-To: <40E16B9B-2B43-4E1C-9179-E7A0DA7DF71B@cse.unsw.edu.au> References: <40E16B9B-2B43-4E1C-9179-E7A0DA7DF71B@cse.unsw.edu.au> Message-ID: I just tried with the Python2.4.3 binary release for OSX from python.org and i get the same error cheers, Tom On 19/06/2006, at 20:30:22, Tom Birch wrote: > I'm just playing around with writing a Python wrapper for SearchKit, > and when I was just getting the very basics down of the first class, > I ran into this problem when importing my module: > > ImportError: Failure linking new module: /Library/Frameworks/ > Python.framework/Versions/2.4/lib/python2.4/site-packages/ > pysearchkit.so: Symbol not found: _CFRelease > Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ > lib/python2.4/site-packages/pysearchkit.so > Expected in: dynamic lookup > > I went and double-checked my setup.py file: > > module1 = Extension('pysearchkit', > extra_link_args = ['-framework CoreServices', '- > framework CoreFoundation'], > sources = ['module.c','index.c']) > > but I couldn't find any problem. I looked at the last link command > and it seemed ok, I tried running it again manually and it didn't > work: > > % gcc -bundle -undefined dynamic_lookup build/temp.darwin-8.6.0- > Power_Macintosh-2.4/module.o build/temp.darwin-8.6.0- > Power_Macintosh-2.4/index.o -o build/lib.darwin-8.6.0- > Power_Macintosh-2.4/pysearchkit.so -framework CoreServices -framework > CoreFoundation > /usr/bin/ld: flag: -undefined dynamic_lookup can't be used with > MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 > collect2: ld returned 1 exit status > > so I fixed that with adding 'MACOSX_DEPLOYMENT_TARGET=10.4' to the > start, and it worked: > > % MACOSX_DEPLOYMENT_TARGET=10.4 gcc -bundle -undefined dynamic_lookup > build/temp.darwin-8.6.0-Power_Macintosh-2.4/module.o build/ > temp.darwin-8.6.0-Power_Macintosh-2.4/index.o -o build/ > lib.darwin-8.6.0-Power_Macintosh-2.4/pysearchkit.so -framework > CoreServices -framework CoreFoundation > % > > Running 'sudo python setup.py install' after this results in an > installed module that imports correctly, so I was wondering exactly > what the issue is. I'm sure it's something to do with the environment > passed to the link command, but a look at > distutils.sysconfig.get_config_vars() didn't show up anything > interesting (although I'm not an expert on ld). I was wondering if > anyone had an idea as to why this is broken. I'm running python2.4 on > ppc (installed as a framework), and interestingly enough it works > fine with python2.3. Could this be a problem with my python2.4 > install? I haven't had any problems with PyObjC and that seems to > link things the same way as I am (and uses plenty of stuff in > frameworks) so I'm at a complete loss as to what's happening here. > > The source for everything is available here if you want to try and > replicate it: > http://www.cse.unsw.edu.au/~tbirch/pysearchkit.tar.bz2 > > cheers, > Tom > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From tbirch at cse.unsw.edu.au Mon Jun 19 13:29:40 2006 From: tbirch at cse.unsw.edu.au (Tom Birch) Date: Mon, 19 Jun 2006 21:29:40 +1000 Subject: [Pythonmac-SIG] Missing symbols in module compiled with distutils In-Reply-To: References: <40E16B9B-2B43-4E1C-9179-E7A0DA7DF71B@cse.unsw.edu.au> Message-ID: <43FDC020-ACD7-462B-A1A8-0C219AAA38F9@cse.unsw.edu.au> really really weird, I changed my setup.py to this: def frameworks(*args): lst = [] for arg in args: lst.extend(['-framework', arg]) return lst module1 = Extension('pysearchkit', extra_link_args = frameworks ('CoreServices','CoreFoundation'), sources = ['module.c','index.c'] ) and it worked, I'm still confused as to how that really changes anything... anyway sorry for the trouble cheers, Tom On 19/06/2006, at 21:10:58, Tom Birch wrote: > I just tried with the Python2.4.3 binary release for OSX from > python.org and i get the same error > > cheers, > Tom > > On 19/06/2006, at 20:30:22, Tom Birch wrote: > >> I'm just playing around with writing a Python wrapper for SearchKit, >> and when I was just getting the very basics down of the first class, >> I ran into this problem when importing my module: >> >> ImportError: Failure linking new module: /Library/Frameworks/ >> Python.framework/Versions/2.4/lib/python2.4/site-packages/ >> pysearchkit.so: Symbol not found: _CFRelease >> Referenced from: /Library/Frameworks/Python.framework/Versions/ >> 2.4/ >> lib/python2.4/site-packages/pysearchkit.so >> Expected in: dynamic lookup >> >> I went and double-checked my setup.py file: >> >> module1 = Extension('pysearchkit', >> extra_link_args = ['-framework CoreServices', '- >> framework CoreFoundation'], >> sources = ['module.c','index.c']) >> >> but I couldn't find any problem. I looked at the last link command >> and it seemed ok, I tried running it again manually and it didn't >> work: >> >> % gcc -bundle -undefined dynamic_lookup build/temp.darwin-8.6.0- >> Power_Macintosh-2.4/module.o build/temp.darwin-8.6.0- >> Power_Macintosh-2.4/index.o -o build/lib.darwin-8.6.0- >> Power_Macintosh-2.4/pysearchkit.so -framework CoreServices -framework >> CoreFoundation >> /usr/bin/ld: flag: -undefined dynamic_lookup can't be used with >> MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1 >> collect2: ld returned 1 exit status >> >> so I fixed that with adding 'MACOSX_DEPLOYMENT_TARGET=10.4' to the >> start, and it worked: >> >> % MACOSX_DEPLOYMENT_TARGET=10.4 gcc -bundle -undefined dynamic_lookup >> build/temp.darwin-8.6.0-Power_Macintosh-2.4/module.o build/ >> temp.darwin-8.6.0-Power_Macintosh-2.4/index.o -o build/ >> lib.darwin-8.6.0-Power_Macintosh-2.4/pysearchkit.so -framework >> CoreServices -framework CoreFoundation >> % >> >> Running 'sudo python setup.py install' after this results in an >> installed module that imports correctly, so I was wondering exactly >> what the issue is. I'm sure it's something to do with the environment >> passed to the link command, but a look at >> distutils.sysconfig.get_config_vars() didn't show up anything >> interesting (although I'm not an expert on ld). I was wondering if >> anyone had an idea as to why this is broken. I'm running python2.4 on >> ppc (installed as a framework), and interestingly enough it works >> fine with python2.3. Could this be a problem with my python2.4 >> install? I haven't had any problems with PyObjC and that seems to >> link things the same way as I am (and uses plenty of stuff in >> frameworks) so I'm at a complete loss as to what's happening here. >> >> The source for everything is available here if you want to try and >> replicate it: >> http://www.cse.unsw.edu.au/~tbirch/pysearchkit.tar.bz2 >> >> cheers, >> Tom >> _______________________________________________ >> 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 h.goebel at goebel-consult.de Mon Jun 19 13:51:07 2006 From: h.goebel at goebel-consult.de (Hartmut Goebel) Date: Mon, 19 Jun 2006 13:51:07 +0200 Subject: [Pythonmac-SIG] Missing symbols in module compiled with distutils In-Reply-To: <43FDC020-ACD7-462B-A1A8-0C219AAA38F9@cse.unsw.edu.au> References: <40E16B9B-2B43-4E1C-9179-E7A0DA7DF71B@cse.unsw.edu.au> <43FDC020-ACD7-462B-A1A8-0C219AAA38F9@cse.unsw.edu.au> Message-ID: <44968FAB.5060500@goebel-consult.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Birch schrieb: > extra_link_args = frameworks > ('CoreServices','CoreFoundation'), This gives you a list of four arguments, while this >>> extra_link_args = ['-framework CoreServices', '- >>> framework CoreFoundation'], are only two. - -- Sch?nen Gru? - Regards Hartmut Goebel | Hartmut Goebel | IT-Security -- effizient | | h.goebel at goebel-consult.de | www.goebel-consult.de | -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iQEVAwUBRJaPq8zajR0mSa83AQJzXgf8D3kZ+MXQhBu7vL/Zua7zFF0nDkn8Flvb 1eeYXNLrUCcTDI9y51jIZIWVgUXCMeWYLpSPcySPEWOnfIrOq3UwPGpJHRfQkvO5 Fi/2w2YIEFIXldivqj9FvqSlaBPCU3B3OBxfphdnRzPvrzr/Li1Tk/i8VMuFHHKL S5r2hYApp/6LB5RxNVGhzsA7/agdJEx46pJxp7HQ0W4lnthDn7EUezhuzBlla/39 G+etxUgj7TY8HJCh63l/UWls+9GWDv3Ec7MTU5cyDFWxb1xxM+GT3cYMoW+8KVkv TWTm0FQNPL5xyUijTJdRVugNQZ/k369An0ajh6JgkVdplFkOw3a0Xg== =p0Sw -----END PGP SIGNATURE----- From banoffi at gmail.com Mon Jun 19 17:24:50 2006 From: banoffi at gmail.com (Banoffi) Date: Mon, 19 Jun 2006 16:24:50 +0100 Subject: [Pythonmac-SIG] Bundling Python framework with app Message-ID: <053B9706-B02E-4599-8E06-45565362E427@gmail.com> Hi, Sorry if this is a naieve question - I'm completely new to OS X programming. What I'm trying to do is embed Python 2.4 in a Cocoa app, and include the framework (2.4.3) in the app bundle so that users don't need to install the framework separately. I can get the framework copied into the bundle no problem, but whatever I try, the executable remains linked to /Library/Frameworks/Python.framework. Is this even possible? Thanks for any ideas, Tom From tbirch at cse.unsw.edu.au Mon Jun 19 17:28:09 2006 From: tbirch at cse.unsw.edu.au (Tom Birch) Date: Tue, 20 Jun 2006 01:28:09 +1000 Subject: [Pythonmac-SIG] Bundling Python framework with app In-Reply-To: <053B9706-B02E-4599-8E06-45565362E427@gmail.com> References: <053B9706-B02E-4599-8E06-45565362E427@gmail.com> Message-ID: <72F1FCAD-420F-45FB-8688-3F74F99D9E29@cse.unsw.edu.au> On 20/06/2006, at 01:24:50, Banoffi wrote: > Hi, > > Sorry if this is a naieve question - I'm completely new to OS X > programming. What I'm trying to do is embed Python 2.4 in a Cocoa > app, and include the framework (2.4.3) in the app bundle so that > users don't need to install the framework separately. I can get the > framework copied into the bundle no problem, but whatever I try, the > executable remains linked to /Library/Frameworks/Python.framework. > Is this even possible? Maybe this is what you're looking for: http://rentzsch.com/cocoa/ embeddedFrameworks cheers, Tom > > Thanks for any ideas, > > Tom > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Mon Jun 19 17:43:38 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 19 Jun 2006 17:43:38 +0200 Subject: [Pythonmac-SIG] Bundling Python framework with app In-Reply-To: <72F1FCAD-420F-45FB-8688-3F74F99D9E29@cse.unsw.edu.au> References: <053B9706-B02E-4599-8E06-45565362E427@gmail.com> <72F1FCAD-420F-45FB-8688-3F74F99D9E29@cse.unsw.edu.au> Message-ID: <3999219.1150731818493.JavaMail.ronaldoussoren@mac.com> On Monday, June 19, 2006, at 05:28PM, Tom Birch wrote: > >On 20/06/2006, at 01:24:50, Banoffi wrote: > >> Hi, >> >> Sorry if this is a naieve question - I'm completely new to OS X >> programming. What I'm trying to do is embed Python 2.4 in a Cocoa >> app, and include the framework (2.4.3) in the app bundle so that >> users don't need to install the framework separately. I can get the >> framework copied into the bundle no problem, but whatever I try, the >> executable remains linked to /Library/Frameworks/Python.framework. >> Is this even possible? > >Maybe this is what you're looking for: http://rentzsch.com/cocoa/ >embeddedFrameworks Py2app contains machostandalone, which can do at least part of what you need. Ronald From banoffi at gmail.com Mon Jun 19 20:08:51 2006 From: banoffi at gmail.com (Banoffi) Date: Mon, 19 Jun 2006 19:08:51 +0100 Subject: [Pythonmac-SIG] Bundling Python framework with app In-Reply-To: References: Message-ID: Ronald, Tom, thanks for the information. I think I understand what's going on a bit more now. But now I think it would make more sense to package my app and the Python framework as a .pkg (the only slight disadvantage is that non-admin users may not be able to install it, but I don't think that'll be a problem.) cheers, Tom From bob at redivi.com Mon Jun 19 20:37:44 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 19 Jun 2006 11:37:44 -0700 Subject: [Pythonmac-SIG] Bundling Python framework with app In-Reply-To: References: Message-ID: <61FBB187-AEDD-4C11-BE79-8DC64082C182@redivi.com> On Jun 19, 2006, at 11:08 AM, Banoffi wrote: > Ronald, Tom, thanks for the information. I think I understand what's > going on a bit more now. But now I think it would make more sense to > package my app and the Python framework as a .pkg (the only slight > disadvantage is that non-admin users may not be able to install it, > but I don't think that'll be a problem.) That rarely ever makes sense. You really shouldn't do that for an application. -bob From banoffi at gmail.com Mon Jun 19 20:43:57 2006 From: banoffi at gmail.com (Banoffi) Date: Mon, 19 Jun 2006 19:43:57 +0100 Subject: [Pythonmac-SIG] Bundling Python framework with app In-Reply-To: <61FBB187-AEDD-4C11-BE79-8DC64082C182@redivi.com> References: <61FBB187-AEDD-4C11-BE79-8DC64082C182@redivi.com> Message-ID: <69F3094B-5320-48A5-A289-88BDF75E289A@gmail.com> On 19 Jun 2006, at 19:37, Bob Ippolito wrote: >> Ronald, Tom, thanks for the information. I think I understand what's >> going on a bit more now. But now I think it would make more sense to >> package my app and the Python framework as a .pkg (the only slight >> disadvantage is that non-admin users may not be able to install it, >> but I don't think that'll be a problem.) > > That rarely ever makes sense. You really shouldn't do that for an > application. Um, why not? I know it's not as simple as drag-and-drop, but neither is it particularly hard work for the user. (And I'm not at all confident of getting the embedded package approach to work.) Tom From bob at redivi.com Mon Jun 19 20:46:33 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 19 Jun 2006 11:46:33 -0700 Subject: [Pythonmac-SIG] Bundling Python framework with app In-Reply-To: <69F3094B-5320-48A5-A289-88BDF75E289A@gmail.com> References: <61FBB187-AEDD-4C11-BE79-8DC64082C182@redivi.com> <69F3094B-5320-48A5-A289-88BDF75E289A@gmail.com> Message-ID: <102DE116-9F10-4FA8-80BF-5CF3D9937FBA@redivi.com> On Jun 19, 2006, at 11:43 AM, Banoffi wrote: > On 19 Jun 2006, at 19:37, Bob Ippolito wrote: > >>> Ronald, Tom, thanks for the information. I think I understand what's >>> going on a bit more now. But now I think it would make more sense to >>> package my app and the Python framework as a .pkg (the only slight >>> disadvantage is that non-admin users may not be able to install it, >>> but I don't think that'll be a problem.) >> >> That rarely ever makes sense. You really shouldn't do that for an >> application. > > Um, why not? I know it's not as simple as drag-and-drop, but > neither is it particularly hard work for the user. (And I'm not at > all confident of getting the embedded package approach to work.) It's harder for the user, you're could overwrite an existing Python installation, it doesn't follow Apple's guidelines, etc. Don't do it that way. I definitely wouldn't even consider installing your software if it used a .pkg installer unless I *really* needed it. It's not a slight disadvantage. -bob From njriley at uiuc.edu Mon Jun 19 20:54:33 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon, 19 Jun 2006 13:54:33 -0500 Subject: [Pythonmac-SIG] Bundling Python framework with app In-Reply-To: <69F3094B-5320-48A5-A289-88BDF75E289A@gmail.com> References: <61FBB187-AEDD-4C11-BE79-8DC64082C182@redivi.com> <69F3094B-5320-48A5-A289-88BDF75E289A@gmail.com> Message-ID: <20060619185432.GA51721@uiuc.edu> On Mon, Jun 19, 2006 at 07:43:57PM +0100, Banoffi wrote: > Um, why not? I know it's not as simple as drag-and-drop, but neither > is it particularly hard work for the user. (And I'm not at all > confident of getting the embedded package approach to work.) One major reason I avoid .pkg installers is there's no easy way to uninstall. With an app bundle, you just trash it. (And yes, this is Apple's problem that they still don't have a robust installer after 5 years.) -- Nicholas Riley | From banoffi at gmail.com Mon Jun 19 21:32:14 2006 From: banoffi at gmail.com (Banoffi) Date: Mon, 19 Jun 2006 20:32:14 +0100 Subject: [Pythonmac-SIG] Bundling Python framework with app In-Reply-To: <102DE116-9F10-4FA8-80BF-5CF3D9937FBA@redivi.com> References: <61FBB187-AEDD-4C11-BE79-8DC64082C182@redivi.com> <69F3094B-5320-48A5-A289-88BDF75E289A@gmail.com> <102DE116-9F10-4FA8-80BF-5CF3D9937FBA@redivi.com> Message-ID: <1FF0C971-40EB-4A56-B059-19638123D839@gmail.com> On 19 Jun 2006, at 19:46, Bob Ippolito wrote: > It's harder for the user, you're could overwrite an existing Python > installation, it doesn't follow Apple's guidelines, etc. Don't do > it that way. > > I definitely wouldn't even consider installing your software if it > used a .pkg installer unless I *really* needed it. It's not a > slight disadvantage. Well... you're right. I'm always telling my Windows-using colleagues how elegant and stuff the OS X way is. Anyway, after a bit of hacking at macho_standalone, I think I've got the bundled approach working. thanks all, Tom From dan at chalkie.org.uk Tue Jun 20 19:08:34 2006 From: dan at chalkie.org.uk (Dan White) Date: Tue, 20 Jun 2006 20:08:34 +0300 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> Message-ID: <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> On 15 Jun 2006, at 10:55, Ronald Oussoren wrote: > > On 15-jun-2006, at 9:28, Dan White wrote: > > >> >> >> So yes there are some DYLD_LIBRARY_PATH suff set. >> >> Maybe therein lies the problem...? >> Python probably doesn't know about that stuff? > > That might be the problem, and seems to indicate that Intel does > something completely wrong. Any use of the DYLD_* variables in a > production environment is an indication that something fishy is > going on. Unlike linux executables on osx contain the full path to > libraries they link to. If DYLD_LIBRARY_PATH is needed the compiler > doesn't include the full path to some libraries that are needed. It > should be possible to teach py2app/macholib about this "feature" of > the intel compiler, but you'll probably have to do that yourself. I tried fixing the .dylibs in my application bindle (made by py2app) that were unable to find libguide.dylib using for instance install_name_tool -change libguide.dylib @executable_path/../ Frameworks/libguide.dylib /Users/dan/Desktop/bioimagexdsvn/trunk/dist/ BioImageXD.app/Contents/MacOS/../Frameworks/libvtkGraphicsPythonD. 5.1.dylib and it worked ok! (My .app still fails to launch form some pythonic reason in our code though...) so is it a case of teaching macholib this trick for the case of DATA_FILES.append( ('../Frameworks', [ '/opt/intel/cc/9.1.024/lib/libguide.dylib', ])) or am I barking up the wrong tree. I'm not sure macholib doesnt already do this, as it does when you tell py2app to append other dylibs into ../Frameworks? Or doesnt it do that for dylibs actually? DATA_FILES.append literally just to put data files there, and macholib knows nothing about it. cheers Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From ronaldoussoren at mac.com Tue Jun 20 19:40:34 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 20 Jun 2006 19:40:34 +0200 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> Message-ID: <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> On 20-jun-2006, at 19:08, Dan White wrote: > > On 15 Jun 2006, at 10:55, Ronald Oussoren wrote: > >> >> On 15-jun-2006, at 9:28, Dan White wrote: >> >> >>> >>> >>> So yes there are some DYLD_LIBRARY_PATH suff set. >>> >>> Maybe therein lies the problem...? >>> Python probably doesn't know about that stuff? >> >> That might be the problem, and seems to indicate that Intel does >> something completely wrong. Any use of the DYLD_* variables in a >> production environment is an indication that something fishy is >> going on. Unlike linux executables on osx contain the full path to >> libraries they link to. If DYLD_LIBRARY_PATH is needed the >> compiler doesn't include the full path to some libraries that are >> needed. It should be possible to teach py2app/macholib about this >> "feature" of the intel compiler, but you'll probably have to do >> that yourself. > > I tried fixing the .dylibs in my application bindle (made by py2app) > that were unable to find libguide.dylib > using for instance > > install_name_tool -change libguide.dylib @executable_path/../ > Frameworks/libguide.dylib /Users/dan/Desktop/bioimagexdsvn/trunk/ > dist/BioImageXD.app/Contents/MacOS/../Frameworks/ > libvtkGraphicsPythonD.5.1.dylib Hmm, this could turn out to be interesting :-). Could you check the license of the intel compiler, are you allowed to do this? BTW. A better fix would be to rewrite the install_name of the libguide.dylib in /opt/intel/cc/.../, then py2app would automaticly copy the library and rewrite the install_name. Ronald From dan at chalkie.org.uk Tue Jun 20 23:32:18 2006 From: dan at chalkie.org.uk (Dan White) Date: Wed, 21 Jun 2006 00:32:18 +0300 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> Message-ID: On 20 Jun 2006, at 20:40, Ronald Oussoren wrote: > > On 20-jun-2006, at 19:08, Dan White wrote: > >> >> On 15 Jun 2006, at 10:55, Ronald Oussoren wrote: >> >>> >>> On 15-jun-2006, at 9:28, Dan White wrote: >>> >>> >>>> >>>> >>>> So yes there are some DYLD_LIBRARY_PATH suff set. >>>> >>>> Maybe therein lies the problem...? >>>> Python probably doesn't know about that stuff? >>> >>> That might be the problem, and seems to indicate that Intel does >>> something completely wrong. Any use of the DYLD_* variables in a >>> production environment is an indication that something fishy is >>> going on. Unlike linux executables on osx contain the full path >>> to libraries they link to. If DYLD_LIBRARY_PATH is needed the >>> compiler doesn't include the full path to some libraries that are >>> needed. It should be possible to teach py2app/macholib about this >>> "feature" of the intel compiler, but you'll probably have to do >>> that yourself. >> >> I tried fixing the .dylibs in my application bindle (made by py2app) >> that were unable to find libguide.dylib >> using for instance >> >> install_name_tool -change libguide.dylib @executable_path/../ >> Frameworks/libguide.dylib /Users/dan/Desktop/bioimagexdsvn/trunk/ >> dist/BioImageXD.app/Contents/MacOS/../Frameworks/ >> libvtkGraphicsPythonD.5.1.dylib > > Hmm, this could turn out to be interesting :-). Could you check the > license of the intel compiler, are you allowed to do this? > > BTW. A better fix would be to rewrite the install_name of the > libguide.dylib in /opt/intel/cc/.../, then py2app would automaticly > copy the library and rewrite the install_name. what should i rewrite it to be? using install_name_tool -id ? what would make pyapp automatically copy the library and rewrite the install_name? cheers Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From rowen at cesmail.net Wed Jun 21 00:45:39 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Tue, 20 Jun 2006 15:45:39 -0700 Subject: [Pythonmac-SIG] py2app: hints for an easy console window for applets? Message-ID: Anyone have simple code to add a console window to drag-and-drop apps made from py2app (or, preferably, py2applet)? I would like stdout/stderr to show up on a visible window (rather than mixed in with console messages). -- Russell From bob at redivi.com Wed Jun 21 02:32:22 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 20 Jun 2006 17:32:22 -0700 Subject: [Pythonmac-SIG] py2app: hints for an easy console window for applets? In-Reply-To: References: Message-ID: <26F42654-B33A-4279-9AE0-2076623E0499@redivi.com> On Jun 20, 2006, at 3:45 PM, Russell E. Owen wrote: > Anyone have simple code to add a console window to drag-and-drop apps > made from py2app (or, preferably, py2applet)? I would like stdout/ > stderr > to show up on a visible window (rather than mixed in with console > messages). That's not trivial, you'd have to replace the executable stub with a script that opens a new terminal window instead. -bob From danielmcmanus at optonline.net Wed Jun 21 03:14:58 2006 From: danielmcmanus at optonline.net (Daniel McManus) Date: Tue, 20 Jun 2006 21:14:58 -0400 Subject: [Pythonmac-SIG] Converting Type 1 fonts for use with Mac OS X Version 10.4.6 Message-ID: <1994F687-265A-4DD7-BE50-40CFBAA0DC1D@optonline.net> >>> I have a large font library of PostScript Type 1 fonts that I >>> would like to convert so that I can utilize them on my new Mac. >>> >>> The operating system on the new computer is Mac OS X Version 10.4.6. >>> >>> I have purposely had a SCSI card installed on the new Mac so that >>> the hard drive that stores the fonts can be connected. >>> >>> The connection works and I can read all the fonts stored on my >>> old external hard drive on my new Mac. >>> >>> Please let me know if it is possible to convert these fonts so >>> that I can use them on my new Mac. And, lf I can, kindly tell me >>> what software I will need, if any, and any other info so I can >>> get started. >>> >>> Thank you for your attention. Any help will be greatly appreciated. >>> From ronaldoussoren at mac.com Wed Jun 21 08:14:36 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 21 Jun 2006 08:14:36 +0200 Subject: [Pythonmac-SIG] py2app: hints for an easy console window forapplets? In-Reply-To: <26F42654-B33A-4279-9AE0-2076623E0499@redivi.com> References: <26F42654-B33A-4279-9AE0-2076623E0499@redivi.com> Message-ID: <16526287.1150870476572.JavaMail.ronaldoussoren@mac.com> On Wednesday, June 21, 2006, at 02:32AM, Bob Ippolito wrote: >On Jun 20, 2006, at 3:45 PM, Russell E. Owen wrote: > >> Anyone have simple code to add a console window to drag-and-drop apps >> made from py2app (or, preferably, py2applet)? I would like stdout/ >> stderr >> to show up on a visible window (rather than mixed in with console >> messages). > >That's not trivial, you'd have to replace the executable stub with a >script that opens a new terminal window instead. Either that or something like the embedded python console example in pyobjc. Neither way is very simple. Ronald From ronaldoussoren at mac.com Wed Jun 21 08:29:14 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 21 Jun 2006 08:29:14 +0200 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> Message-ID: On 20-jun-2006, at 23:32, Dan White wrote: > > > what should i rewrite it to be? > using > install_name_tool -id ? > what would make pyapp automatically copy the library and rewrite > the install_name? If I understand things correctly the install_name of libguide.dylib is currently just libguide.dylib, whereas it should be /path/to/ libguide.dylib. The install_name is copied into any objects that link to the library (which is what you get to see when you use otool -vL). If the install_name of a linked-to library points to a library that py2app can find at that location that library will be copied into the application bundle and it's install_name gets rewritten to something relative to the executable in the application bundle. Now that I think a bit more about this issue, it might be possible to solve this using a py2app recipe. I don't really have time to work on this, even though I'd love to play with the Intel compiler to see if that would speed up Python. Ronald From dan at chalkie.org.uk Wed Jun 21 10:09:03 2006 From: dan at chalkie.org.uk (Dan White) Date: Wed, 21 Jun 2006 11:09:03 +0300 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> Message-ID: <3D1E0BC2-295D-493F-B44B-5A903B5A3C81@chalkie.org.uk> On 21 Jun 2006, at 09:29, Ronald Oussoren wrote: > > On 20-jun-2006, at 23:32, Dan White wrote: >> >> >> what should i rewrite it to be? >> using >> install_name_tool -id ? >> what would make pyapp automatically copy the library and rewrite >> the install_name? > > If I understand things correctly the install_name of libguide.dylib > is currently just libguide.dylib, whereas it should be /path/to/ > libguide.dylib. The install_name is copied into any objects that > link to the library (which is what you get to see when you use > otool -vL). > > If the install_name of a linked-to library points to a library that > py2app can find at that location that library will be copied into > the application bundle and it's install_name gets rewritten to > something relative to the executable in the application bundle. > > Now that I think a bit more about this issue, it might be possible > to solve this using a py2app recipe. I don't really have time to > work on this, even though I'd love to play with the Intel compiler > to see if that would speed up Python. OK, Now I unbderstand, thanks for clearinf htat up. So intel made a problem by not setting the install_name of libguide.dylib to the path where it is installed. I will hack it and see if py2app picks it up. I will also investigate the licence re redistribution of that library. At least with VTK c++ code compiled with intel compilers on a core duo intel MacBook Pro with flags -xP -parallel for full optimization lots of loops get vectorised, and it seems at least as fast if not faster than gcc code. I havent done any rigorous testing measuring performance times, but it seems fairly snappy so far. Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From dan at chalkie.org.uk Wed Jun 21 10:35:59 2006 From: dan at chalkie.org.uk (Dan White) Date: Wed, 21 Jun 2006 11:35:59 +0300 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> Message-ID: On 20 Jun 2006, at 20:40, Ronald Oussoren wrote: > > On 20-jun-2006, at 19:08, Dan White wrote: > >> >> On 15 Jun 2006, at 10:55, Ronald Oussoren wrote: >> >>> >>> On 15-jun-2006, at 9:28, Dan White wrote: >>> >>> >>>> >>>> >>>> So yes there are some DYLD_LIBRARY_PATH suff set. >>>> >>>> Maybe therein lies the problem...? >>>> Python probably doesn't know about that stuff? >>> >>> That might be the problem, and seems to indicate that Intel does >>> something completely wrong. Any use of the DYLD_* variables in a >>> production environment is an indication that something fishy is >>> going on. Unlike linux executables on osx contain the full path >>> to libraries they link to. If DYLD_LIBRARY_PATH is needed the >>> compiler doesn't include the full path to some libraries that are >>> needed. It should be possible to teach py2app/macholib about this >>> "feature" of the intel compiler, but you'll probably have to do >>> that yourself. >> >> I tried fixing the .dylibs in my application bindle (made by py2app) >> that were unable to find libguide.dylib >> using for instance >> >> install_name_tool -change libguide.dylib @executable_path/../ >> Frameworks/libguide.dylib /Users/dan/Desktop/bioimagexdsvn/trunk/ >> dist/BioImageXD.app/Contents/MacOS/../Frameworks/ >> libvtkGraphicsPythonD.5.1.dylib > > Hmm, this could turn out to be interesting :-). Could you check the > license of the intel compiler, are you allowed to do this? > > BTW. A better fix would be to rewrite the install_name of the > libguide.dylib in /opt/intel/cc/.../, then py2app would automaticly > copy the library and rewrite the install_name. here is the license from intel pages for the OS X intel compilers http://www.intel.com/cd/software/products/asmo-na/eng/compilers/cmac/ 267042.htm doesn't look good. Even the non profit license does not seem to allow redistribution of their materials. Which seems rather odd, since the libguide.dyli is no use to anyone who isnt using their compiers or binaries generated by them, so they only stand to gain by their redistribution with fast intel compiled binaries... big business..... i will ask for clarification regarding open source free software projects. Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From dan at chalkie.org.uk Wed Jun 21 10:41:49 2006 From: dan at chalkie.org.uk (Dan White) Date: Wed, 21 Jun 2006 11:41:49 +0300 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> Message-ID: <8B0C93CC-E5C0-4D75-A5DC-F6FA1B6AD351@chalkie.org.uk> On 21 Jun 2006, at 11:35, Dan White wrote: > > On 20 Jun 2006, at 20:40, Ronald Oussoren wrote: > >> >> On 20-jun-2006, at 19:08, Dan White wrote: >> >>> >>> On 15 Jun 2006, at 10:55, Ronald Oussoren wrote: >>> >>>> >>>> On 15-jun-2006, at 9:28, Dan White wrote: >>>> >>>> >>>>> >>>>> >>>>> So yes there are some DYLD_LIBRARY_PATH suff set. >>>>> >>>>> Maybe therein lies the problem...? >>>>> Python probably doesn't know about that stuff? >>>> >>>> That might be the problem, and seems to indicate that Intel does >>>> something completely wrong. Any use of the DYLD_* variables in a >>>> production environment is an indication that something fishy is >>>> going on. Unlike linux executables on osx contain the full path >>>> to libraries they link to. If DYLD_LIBRARY_PATH is needed the >>>> compiler doesn't include the full path to some libraries that >>>> are needed. It should be possible to teach py2app/macholib about >>>> this "feature" of the intel compiler, but you'll probably have >>>> to do that yourself. >>> >>> I tried fixing the .dylibs in my application bindle (made by py2app) >>> that were unable to find libguide.dylib >>> using for instance >>> >>> install_name_tool -change libguide.dylib @executable_path/../ >>> Frameworks/libguide.dylib /Users/dan/Desktop/bioimagexdsvn/trunk/ >>> dist/BioImageXD.app/Contents/MacOS/../Frameworks/ >>> libvtkGraphicsPythonD.5.1.dylib >> >> Hmm, this could turn out to be interesting :-). Could you check >> the license of the intel compiler, are you allowed to do this? >> >> BTW. A better fix would be to rewrite the install_name of the >> libguide.dylib in /opt/intel/cc/.../, then py2app would >> automaticly copy the library and rewrite the install_name. > > here is the license from intel pages for the OS X intel compilers > > http://www.intel.com/cd/software/products/asmo-na/eng/compilers/ > cmac/267042.htm > > doesn't look good. > Even the non profit license does not seem to allow redistribution > of their materials. > Which seems rather odd, since the libguide.dyli is no use to anyone > who isnt using their compiers > or binaries generated by them, > so they only stand to gain by their redistribution with fast intel > compiled binaries... > > > big business..... > > i will ask for clarification regarding open source free software > projects. > > Dan Actually on further inspection, there is a file with a list of redistrubutable files: List of Re-distributable files for the Intel(R) C++ Compiler for Mac OS: libguide.a libguide.dylib libguide_stats.a libguide_stats.dylib libimf.a libimf.dylib libirc.a libirc.dylib libirc_s.a libompstub.a libsvml.a libsvml.dylib libipgo.a so maybe that means it is fine to bundle libguide.dylib in a .app Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From ronaldoussoren at mac.com Wed Jun 21 10:42:41 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 21 Jun 2006 10:42:41 +0200 Subject: [Pythonmac-SIG] python 2.5b1 Message-ID: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> Python 2.5b1 was released today, get it while it's hot: Of particular interest to the mac community: * Includes the new icons * universal binary * IDLE L&F sucks less, you'll even be able to use IDLE as the default editor for .py/.pyw files (double-clicking works) There are some issues with this release in combination with 10.3.9, sadly enough I had some hardware problems with my 10.3 capable box and wasn't able to fix those problems (or even test on 10.3.9) until it was too late. Please build from source when you're running 10.3 for now, these issues will be resolved before the next beta. Ronald From ronaldoussoren at mac.com Wed Jun 21 10:49:14 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 21 Jun 2006 10:49:14 +0200 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> Message-ID: <1396776.1150879754794.JavaMail.ronaldoussoren@mac.com> On Wednesday, June 21, 2006, at 10:36AM, Dan White wrote: >> BTW. A better fix would be to rewrite the install_name of the >> libguide.dylib in /opt/intel/cc/.../, then py2app would automaticly >> copy the library and rewrite the install_name. > >here is the license from intel pages for the OS X intel compilers > >http://www.intel.com/cd/software/products/asmo-na/eng/compilers/cmac/ >267042.htm > >doesn't look good. >Even the non profit license does not seem to allow redistribution of >their materials. That depends. The license mentions redistributables which should be save to redistribute, a list of which should be included with the compiler package. >From what I understand I won't be able to use their compiler to build python and then use that python binary in a commercial setting unless I buy a license. If I understand this correctly this would make it impossible to use the intel compiler to build the "official" python binaries for intel macs. (the usual disclaimer applies: I'm not a lawyer and am not even vaguely familiar with US law) Ronald From dan at chalkie.org.uk Wed Jun 21 11:35:33 2006 From: dan at chalkie.org.uk (Dan White) Date: Wed, 21 Jun 2006 12:35:33 +0300 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included In-Reply-To: References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> Message-ID: <238AA653-7552-4905-86B4-93F52098932E@chalkie.org.uk> On 21 Jun 2006, at 09:29, Ronald Oussoren wrote: > > On 20-jun-2006, at 23:32, Dan White wrote: >> >> >> what should i rewrite it to be? >> using >> install_name_tool -id ? >> what would make pyapp automatically copy the library and rewrite >> the install_name? > > If I understand things correctly the install_name of libguide.dylib > is currently just libguide.dylib, whereas it should be /path/to/ > libguide.dylib. The install_name is copied into any objects that > link to the library (which is what you get to see when you use > otool -vL). > > If the install_name of a linked-to library points to a library that > py2app can find at that location that library will be copied into > the application bundle and it's install_name gets rewritten to > something relative to the executable in the application bundle. > > Now that I think a bit more about this issue, it might be possible > to solve this using a py2app recipe. I don't really have time to > work on this, even though I'd love to play with the Intel compiler > to see if that would speed up Python. Looks like py2app did manage to pick up the libguilde.dylib and put it in Frameworks, but it did not rewrite the install name: from the console after double clicking my .app 2006-06-21 12:22:39.222 BioImageXD[26632] BioImageXD Error 2006-06-21 12:22:39.222 BioImageXD[26632] An unexpected error has occurred during execution of the main script ImportError: Failure linking new module: /Users/dan/Desktop/ bioimagexdsvn/trunk/dist/BioImageXD.app/Contents/Resources/Python/lib- dynload/vtk/libvtkIOPython.so: Library not loaded: libguide.dylib Referenced from: /Users/dan/Desktop/bioimagexdsvn/trunk/dist/ BioImageXD.app/Contents/MacOS/../Frameworks/libvtkIOPythonD.5.1.dylib Reason: image not found and otool -L tells me: white:~/Desktop/bioimagexdsvn/trunk dan$ otool -L /Users/dan/Desktop/ bioimagexdsvn/trunk/dist/BioImageXD.app/Contents/Frameworks/ libguide.dylib /Users/dan/Desktop/bioimagexdsvn/trunk/dist/BioImageXD.app/Contents/ Frameworks/libguide.dylib: /opt/intel/cc/9.1.027/lib/libguide.dylib (compatibility version 4.0.0, current version 4.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3) should be @executable_path/../Frameworks/libguide.dylib right? otool -L for the dylib trying to see libguide: white:~/Desktop/bioimagexdsvn/trunk dan$ otool -L /Users/dan/Desktop/ bioimagexdsvn/trunk/dist/BioImageXD.app/Contents/Frameworks/ libvtkIOPythonD.5.1.dylib /Users/dan/Desktop/bioimagexdsvn/trunk/dist/BioImageXD.app/Contents/ Frameworks/libvtkIOPythonD.5.1.dylib: libvtkIOPythonD.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkIO.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkFilteringPythonD.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Python.framework/Versions/2.3/ Python (compatibility version 2.3.0, current version 2.3.5) libvtkDICOMParser.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkpng.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtktiff.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkzlib.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkjpeg.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkexpat.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkMPEG2Encode.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkFiltering.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkCommonPythonD.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtkCommon.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) libvtksys.5.1.dylib (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/AppKit.framework/Versions/C/ AppKit (compatibility version 45.0.0, current version 824.39.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) libguide.dylib (compatibility version 4.0.0, current version 4.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libmx.A.dylib (compatibility version 1.0.0, current version 1.0.0) white:~/Desktop/bioimagexdsvn/trunk dan$ should all these vtk*.dylib also have @executable_path/../Frameworks/libvtk* for their install names once py2app has put them in my .app bundle, since they are not system libraries, but are ones I have compiled with the intel compiler for use in my .app? Also should libguide.dylib also be listed here as @executable_path/../ Frameworks/libguide.dylib not just libguide.dylib? Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From layne.bilyeu at robbstucky.net Wed Jun 21 16:45:03 2006 From: layne.bilyeu at robbstucky.net (corporate user) Date: Wed, 21 Jun 2006 10:45:03 -0400 Subject: [Pythonmac-SIG] Converting Type 1 fonts for use with Mac OS X Version 10.4.6 In-Reply-To: References: Message-ID: My comments assume you are moving from an older Mac OS system. I brought all my Type1 PostScript fonts with me when we switched to OS X. The Apple Type Solution Server recognizes the fonts just fine. Watch your file permissions once they are in Darwin/OS X. Fonts do not need to be executable. They are data. Fonts should not be writable, you should not change a font.. OS X does have the problem of 'consolidated' font families confusing things. It takes some time to explain to a graphic designer why their family of WoodtypeOrnaments that worked fine under OS 8.6 doesn't behave properly under Mac OS X. They forget that they created this family from the free fonts that shipped with Illustrator 88, Photoshop 5.5, and some pieces that were taken from various jobs that passed by. (Bold from 1987, Italic from 1992, BoldOblique from the new vendor that bought out the original foundry, etc). Although these worked happily under Mac OS 8, the new font system utilizes far more of the metadata. Even slight variations in the spelling of attributes that were not utilized in pre-Darwin Mac OS will cause some problems for the ATS server. Hope this info helps somebody. From ronaldoussoren at mac.com Wed Jun 21 15:48:15 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 21 Jun 2006 15:48:15 +0200 Subject: [Pythonmac-SIG] Converting Type 1 fonts for use with Mac OS X Version 10.4.6 In-Reply-To: <1994F687-265A-4DD7-BE50-40CFBAA0DC1D@optonline.net> References: <1994F687-265A-4DD7-BE50-40CFBAA0DC1D@optonline.net> Message-ID: <6A292587-6071-4E95-B0FD-343170ACE321@mac.com> On 21-jun-2006, at 3:14, Daniel McManus wrote: >>>> I have a large font library of PostScript Type 1 fonts that I >>>> would like to convert so that I can utilize them on my new Mac. >>>> >>>> The operating system on the new computer is Mac OS X Version >>>> 10.4.6. >>>> >>>> I have purposely had a SCSI card installed on the new Mac so that >>>> the hard drive that stores the fonts can be connected. >>>> >>>> The connection works and I can read all the fonts stored on my >>>> old external hard drive on my new Mac. >>>> >>>> Please let me know if it is possible to convert these fonts so >>>> that I can use them on my new Mac. And, lf I can, kindly tell me >>>> what software I will need, if any, and any other info so I can >>>> get started. >>>> >>>> Thank you for your attention. Any help will be greatly appreciated. OSX has native support for type1 fonts, you should be able to install them like any other font. BTW. This topic is seriously off-topic for this list. Ronald From kent_quirk at cognitoy.com Thu Jun 22 05:11:42 2006 From: kent_quirk at cognitoy.com (Kent Quirk) Date: Wed, 21 Jun 2006 23:11:42 -0400 Subject: [Pythonmac-SIG] Building universal PyOpenGL Message-ID: <449A0A6E.9020904@cognitoy.com> Hi. I got my new MacBook and looked on pythonmac.org for prebuilt packages for universal python 2.4.3. I've got wxPython and it seems to work, but I also need PyOpenGL, and it's not listed up there. So I got the source and I'm trying to build it. The problem is that it's not building -- many of the source files fail with: /System/Library/Frameworks/Kernel.framework/Headers/sys/stat.h:225: error: field 'st_atimespec' has incomplete type /System/Library/Frameworks/Kernel.framework/Headers/sys/stat.h:226: error: field 'st_mtimespec' has incomplete type /System/Library/Frameworks/Kernel.framework/Headers/sys/stat.h:227: error: field 'st_ctimespec' has incomplete type The problem is that somewhere back in the stack of include files (within /Developer/SDKs/MacOSX10.4u.sdk/usr/include/unistd.h, included by Python.h) there's an include of select.h, which defines _TIMESPEC and the timespec struct...but it doesn't define user_timespec. stat.h expects to have user_timespec defined, but won't define it if _TIMESPEC has already been defined. I'm sure that's clear as mud...but basically, there's a bug somewhere, and it's fairly obvious what the general solution is (make sure that structure gets define). The trouble is, I don't know what the *right* answer is to fixing it. From some stuff I've found on the net, it seems like maybe unistd.h might want to include time.h instead of select.h...but I really don't know all the ramifications of the various issues. So...I guess what I'm looking for is advice on which direction to pursue. Is there a valid fix that can be made to PyOpenGL source that would address this? Should I submit a bug report and/or patch to the Python people? To Apple? I'd like to get to the point of a useful universal build of PyOpenGL. Advice? Kent From ronaldoussoren at mac.com Thu Jun 22 10:34:00 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 22 Jun 2006 10:34:00 +0200 Subject: [Pythonmac-SIG] Building universal PyOpenGL In-Reply-To: <449A0A6E.9020904@cognitoy.com> References: <449A0A6E.9020904@cognitoy.com> Message-ID: <433B331F-F4CF-4897-AD5A-59E406A92B9D@mac.com> On 22-jun-2006, at 5:11, Kent Quirk wrote: > Hi. I got my new MacBook and looked on pythonmac.org for prebuilt > packages for universal python 2.4.3. I've got wxPython and it seems to > work, but I also need PyOpenGL, and it's not listed up there. So I got > the source and I'm trying to build it. What happens when you build PyOpenGL for the system python? That would help in finding out who to blame for this ;-) Ronald From jonathan at jonathansaggau.com Thu Jun 22 11:31:07 2006 From: jonathan at jonathansaggau.com (Jonathan) Date: Thu, 22 Jun 2006 05:31:07 -0400 Subject: [Pythonmac-SIG] Embedded Quartz Composer and cocoa notifications Message-ID: Hi again, folks. I'm trying to setup notifications from an embedded Quartz Composer file similar to http://developer.apple.com/technotes/tn2005/tn2146.html#TNTAG8 In my app delegate I have: ... class QCPySightAppDelegate(NibClassBuilder.AutoBaseClass): def init(self): self = super(QCPySightAppDelegate, self).init() if not self: return None self._observeApp() return self def _observeApp(self): NSNotificationCenter.defaultCenter().\ addObserver_selector_name_object_(self, "applicationWillTerminate:", NSApplicationWillTerminateNotification, None) NSNotificationCenter.defaultCenter().\ addObserver_selector_name_object_(self, "applicationDidFinishLaunching:", NSApplicationWillTerminateNotification, None) def _unobserveApp(self): NSNotificationCenter.defaultCenter().removeObserver_name_object_(self, None, None) def _observePatchController(self): """Sets observing for value changes on the image output""" self.patchController.addObserver_forKeyPath_options_context_(self, u"patch.Image.value", 0, None) def _unobservePatchController(self): self.patchController.removeObserver_forKeyPath_(self, u" patch.Image.value") def observeValueForKeyPath_ofObject_change_context_(keyPath, object, change, context): NSLog("Object Changed") NSLog(type(object)) def applicationDidFinishLaunching_(self, notification): self._observePatchController() def applicationWillTerminate_(self, notification): """Cleanup here""" self._unobservePatchController() self._unobserveApp() ... I get this error: Traceback (most recent call last): File "/Volumes/Docs/Users/jonathan/svnCheckouts/main/scmac/trunk/QCPySight/QCPySightAppDelegate.py", line 54, in applicationDidFinishLaunching_ self._observePatchController() File "/Volumes/Docs/Users/jonathan/svnCheckouts/main/scmac/trunk/QCPySight/QCPySightAppDelegate.py", line 39, in _observePatchController self.patchController.addObserver_forKeyPath_options_context_(self, u" patch.Image.value", None, None) ValueError: depythonifying 'unsigned int', got 'NoneType' 2006-06-22 05:23:06.070 QCPySight[665] Exception raised during posting of notification. Ignored. exception: exceptions.ValueError: depythonifying 'unsigned int', got 'NoneType' I wonder if I'm translating the code in the tech note properly re: adding an observer. I'm pretty sure that I have the QC file setup properly and that the bindings are all kosher. Hoping that the code doesn't get unindented or otherwise weirdly broken by gmail.... -- Jonathan Saggau jonathansaggau.com This amusement engaged me so much that [friends] were obliged to force me from it; and thus it is with every inclination I give into, it continues to augment, till at length it becomes so powerful, that I lose sight of everything except the favorite amusement. - Rousseau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060622/36c72d12/attachment.html From jonathan at jonathansaggau.com Thu Jun 22 11:34:40 2006 From: jonathan at jonathansaggau.com (Jonathan) Date: Thu, 22 Jun 2006 05:34:40 -0400 Subject: [Pythonmac-SIG] Building universal PyOpenGL In-Reply-To: <433B331F-F4CF-4897-AD5A-59E406A92B9D@mac.com> References: <449A0A6E.9020904@cognitoy.com> <433B331F-F4CF-4897-AD5A-59E406A92B9D@mac.com> Message-ID: Not that it's likely to help in your situation, but I thought I would throw this out there for the google index: You can use GLUT / openGL in PyObjC through loading the included frameworks in OS X. JS On 6/22/06, Ronald Oussoren wrote: > > > On 22-jun-2006, at 5:11, Kent Quirk wrote: > > > Hi. I got my new MacBook and looked on pythonmac.org for prebuilt > > packages for universal python 2.4.3. I've got wxPython and it seems to > > work, but I also need PyOpenGL, and it's not listed up there. So I got > > the source and I'm trying to build it. > > What happens when you build PyOpenGL for the system python? That > would help in finding out who to blame for this ;-) > > Ronald > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > -- Jonathan Saggau jonathansaggau.com This amusement engaged me so much that [friends] were obliged to force me from it; and thus it is with every inclination I give into, it continues to augment, till at length it becomes so powerful, that I lose sight of everything except the favorite amusement. - Rousseau -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060622/eadca615/attachment.htm From ronaldoussoren at mac.com Thu Jun 22 11:40:07 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 22 Jun 2006 11:40:07 +0200 Subject: [Pythonmac-SIG] Embedded Quartz Composer and cocoa notifications In-Reply-To: References: Message-ID: <9FC41B1A-6022-42BB-AA9F-23B25DE90806@mac.com> On 22-jun-2006, at 11:31, Jonathan wrote: > > I get this error: > > Traceback (most recent call last): > File "/Volumes/Docs/Users/jonathan/svnCheckouts/main/scmac/trunk/ > QCPySight/QCPySightAppDelegate.py", line 54, in > applicationDidFinishLaunching_ > self._observePatchController() > File "/Volumes/Docs/Users/jonathan/svnCheckouts/main/scmac/trunk/ > QCPySight/QCPySightAppDelegate.py", line 39, in > _observePatchController > self.patchController.addObserver_forKeyPath_options_context _ > (self, u"patch.Image.value", None, None) > > ValueError: depythonifying 'unsigned int', got 'NoneType' > 2006-06-22 05:23:06.070 QCPySight[665] Exception raised during > posting of notification. Ignored. exception: > exceptions.ValueError: depythonifying 'unsigned int', got 'NoneType' > > I wonder if I'm translating the code in the tech note properly re: > adding an observer. I'm pretty sure that I have the QC file setup > properly and that the bindings are all kosher. The context is a void* in Objective-C, and should be an integer in Python. It isn't possible to use arbitrary objects as the context because as far as I know it is impossible to get memory management correct for that. Ronald From konrad.hinsen at laposte.net Thu Jun 22 12:15:15 2006 From: konrad.hinsen at laposte.net (Konrad Hinsen) Date: Thu, 22 Jun 2006 12:15:15 +0200 Subject: [Pythonmac-SIG] python 2.5b1 In-Reply-To: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> References: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> Message-ID: <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> On Jun 21, 2006, at 10:42, Ronald Oussoren wrote: > Python 2.5b1 was released today, get it while it's hot: > > Thanks for providing the binaries! I installed them this morning and everything seems to work fine. However, I wasn't very pleased to see that the installation modifies my ~/.profile to insert /Library/Frameworks/Python.framework/Versions/ Current/bin at the front of $PATH. I don't expect any software installation to mess around with my ~/.profile, and certainly not without telling me it did so. For me, the command-line edition of MacPython has always lived in / usr/local/bin, which I put on my PATH if I want MacPython to be used. I also have Fink python that some applications require, so I do need to play with $PATH to make everyone happy, and I don't appreciate MacPython making my many-python life even more difficult. Konrad. From kent_quirk at cognitoy.com Thu Jun 22 14:46:05 2006 From: kent_quirk at cognitoy.com (Kent Quirk) Date: Thu, 22 Jun 2006 08:46:05 -0400 Subject: [Pythonmac-SIG] Building universal PyOpenGL In-Reply-To: <433B331F-F4CF-4897-AD5A-59E406A92B9D@mac.com> References: <449A0A6E.9020904@cognitoy.com> <433B331F-F4CF-4897-AD5A-59E406A92B9D@mac.com> Message-ID: <449A910D.5070502@cognitoy.com> Ronald Oussoren wrote: > > On 22-jun-2006, at 5:11, Kent Quirk wrote: > >> Hi. I got my new MacBook and looked on pythonmac.org for prebuilt >> packages for universal python 2.4.3. I've got wxPython and it seems to >> work, but I also need PyOpenGL, and it's not listed up there. So I got >> the source and I'm trying to build it. > > What happens when you build PyOpenGL for the system python? That would > help in finding out who to blame for this ;-) > > Ronald > That has basically the same result; the gcc command line is different (naming the system python 2.3 frameworks instead of the 2.4) but the error messages and line numbers are the same. By the way, this error repeats maybe hundreds of times, seemingly once for each file being built. The build system seems to ignore the errors until after it's tried to build all of the files. From rsfinn at gmail.com Thu Jun 22 15:38:03 2006 From: rsfinn at gmail.com (Russell Finn) Date: Thu, 22 Jun 2006 09:38:03 -0400 Subject: [Pythonmac-SIG] python 2.5b1 In-Reply-To: <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> References: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> Message-ID: On 6/22/06, Konrad Hinsen wrote: > I wasn't very pleased to see that the installation modifies > my ~/.profile to insert /Library/Frameworks/Python.framework/Versions/ > Current/bin at the front of $PATH. I don't expect any software > installation to mess around with my ~/.profile, and certainly not > without telling me it did so. I guess this is one of the advantages of using tcsh instead of bash: my .profile (with three separate settings of $PATH for three different Python installations) is blissfully ignored... More seriously, it seems to me that an appropriately worded dialog box near the end of the installation might be preferable to automatically hacking people's .profiles. Then people like Konrad who know what they're doing can override the behavior, while people who blindly click "OK" without reading the message -- well, they're the ones that probably need their profiles updated for them. :-) I understand the motivation in making this change -- it tries to forestall the large number of questions we used to get here along the lines of "I just installed the new version of Python but my scripts aren't seeing it" -- but its covert nature always troubled me. Hardly anyone will think to click "Customize" and look in the package list to turn this behavior off (although maybe my publicizing that feature here will help). -- Russell Finn P.S. I do appreciate the hard work the maintainers have put in, and it's a pleasant change to see the latest Mac OS X installers available on python.org. From ronaldoussoren at mac.com Thu Jun 22 19:20:10 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 22 Jun 2006 19:20:10 +0200 Subject: [Pythonmac-SIG] python 2.5b1 In-Reply-To: <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> References: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> Message-ID: <1C2E8255-BEA3-492A-B78A-D40009992CB9@mac.com> On 22-jun-2006, at 12:15, Konrad Hinsen wrote: > On Jun 21, 2006, at 10:42, Ronald Oussoren wrote: > >> Python 2.5b1 was released today, get it while it's hot: >> >> > > Thanks for providing the binaries! > > I installed them this morning and everything seems to work fine. > > However, I wasn't very pleased to see that the installation > modifies my ~/.profile to insert /Library/Frameworks/ > Python.framework/Versions/Current/bin at the front of $PATH. I > don't expect any software installation to mess around with my > ~/.profile, and certainly not without telling me it did so. You can't please them all :-(. I'll add a warning to the readme text in the installer. You can turn this feature of during installation, the profile-editing step is a seperate package that you can disable using the 'Customize' button. This feature was discussed on this list a while ago when several people requested that this feature be added to the installer. The reason for that is that a lot of new users aren't terminal wizards and will be very surprised when the install python 2.4 or 2.5, open Terminal to play around with it and then can't find it on the shells search path. > > For me, the command-line edition of MacPython has always lived in / > usr/local/bin, which I put on my PATH if I want MacPython to be > used. I also have Fink python that some applications require, so I > do need to play with $PATH to make everyone happy, and I don't > appreciate MacPython making my many-python life even more difficult. The current installers only install a number of symlinks in /usr/ local/bin, the real cannonical installation location is inside the python framework. The reason for this is twofold. First of all this keeps the python installation nicely in one location, reducing the risk of interaction with other python installations (e.g. someone building a classic unix installation of python in the default location), but more importantly because distutils will by default install new scripts into the bin directory inside the framework. This confuses the heck out of most users that install new python packages from source, even long-time Python users. By placing the framework on the path thing "just work". Now that I've defended myself it's time to move forward again ;-). Why do some applications require Fink python? Is that a convenience issue or does Fink's python do something that the framework install cannot do? Or to phrase it differently, what should change to make you drop Fink or Darwinports for python stuff? And I mean that *very* broadly, I'd like to make MacPython the obvious choice for anyone that works with python on the mac. Ronald From ronaldoussoren at mac.com Thu Jun 22 19:24:05 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 22 Jun 2006 19:24:05 +0200 Subject: [Pythonmac-SIG] python 2.5b1 In-Reply-To: References: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> Message-ID: On 22-jun-2006, at 15:38, Russell Finn wrote: > On 6/22/06, Konrad Hinsen wrote: >> I wasn't very pleased to see that the installation modifies >> my ~/.profile to insert /Library/Frameworks/Python.framework/ >> Versions/ >> Current/bin at the front of $PATH. I don't expect any software >> installation to mess around with my ~/.profile, and certainly not >> without telling me it did so. > > I guess this is one of the advantages of using tcsh instead of bash: > my .profile (with three separate settings of $PATH for three different > Python installations) is blissfully ignored... You shouldn't have said that, this is a bug in the installer and now that you've told me this I'll fix it. (insert evil grin here). > > More seriously, it seems to me that an appropriately worded dialog box > near the end of the installation might be preferable to automatically > hacking people's .profiles. Then people like Konrad who know what > they're doing can override the behavior, while people who blindly > click "OK" without reading the message -- well, they're the ones that > probably need their profiles updated for them. :-) Apple's installer doesn't allow for custom user interaction from the installer, at least not without makeing it impossible to run the installer from the command-line (or through Remote Desktop). I will however add a note about this behaviour to the ReadMe message at the start of the installer, including instructions to turn this feature of. > > I understand the motivation in making this change -- it tries to > forestall the large number of questions we used to get here along the > lines of "I just installed the new version of Python but my scripts > aren't seeing it" -- but its covert nature always troubled me. Hardly > anyone will think to click "Customize" and look in the package list to > turn this behavior off (although maybe my publicizing that feature > here will help). > > -- Russell Finn > > P.S. I do appreciate the hard work the maintainers have put in, and > it's a pleasant change to see the latest Mac OS X installers available > on python.org. It is cool that OSX is a first-class citizen again. From konrad.hinsen at laposte.net Thu Jun 22 19:37:13 2006 From: konrad.hinsen at laposte.net (Konrad Hinsen) Date: Thu, 22 Jun 2006 19:37:13 +0200 Subject: [Pythonmac-SIG] python 2.5b1 In-Reply-To: <1C2E8255-BEA3-492A-B78A-D40009992CB9@mac.com> References: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> <1C2E8255-BEA3-492A-B78A-D40009992CB9@mac.com> Message-ID: <238C61D9-47F9-4B4F-B8CD-F44D79803DE4@laposte.net> On Jun 22, 2006, at 19:20, Ronald Oussoren wrote: > You can't please them all :-(. I'll add a warning to the readme > text in the installer. You can turn this feature of during > installation, the profile-editing step is a seperate package that > you can disable using the 'Customize' button. This feature was > discussed on this list OK, that's fine. I do occasionally read the readmes ;-) > The current installers only install a number of symlinks in /usr/ > local/bin, the real cannonical installation location is inside the > python framework. The reason for this is I noticed, and that makes sense. > installation of python in the default location), but more > importantly because distutils will by default install new scripts > into the bin directory inside the framework. This confuses the heck > out of most users that install new python packages from source, > even long-time Python users. By placing the framework on the path > thing "just work". That is a good argument. But if you want to change $PATH systemwide, why not put it in .MacOSX/environment.plist? That would have an effect in all shells and also in programs like Emacs that look for a python executable on $PATH. Moreover, it wouldn't bother me because my .profile redefines the path completely :-) > Now that I've defended myself it's time to move forward again ;-). > Why do some applications require Fink python? Is that a convenience > issue or does Fink's python do something that the framework install > cannot do? Or to phrase it differently, what should It's not so much the framework build as the fact that the binary installers have Tkinter set up for Tcl/Tk-Aqua. Fink python is set up for Tk/X11. Tcl-Aqua still has some bugs, and apparently also some more serious issues with multi-threading user interfaces. An example of a program that doesn't work with Tk-Aqua is PyMOL (pymol.sourceforge.net). > change to make you drop Fink or Darwinports for python stuff? And I > mean that *very* broadly, I'd like to make MacPython the obvious > choice for anyone that works with python on the mac. That's a good plan - I'd love to get rid of Fink if I could! Konrad. From ronaldoussoren at mac.com Thu Jun 22 20:10:43 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 22 Jun 2006 20:10:43 +0200 Subject: [Pythonmac-SIG] python 2.5b1 In-Reply-To: <238C61D9-47F9-4B4F-B8CD-F44D79803DE4@laposte.net> References: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> <1C2E8255-BEA3-492A-B78A-D40009992CB9@mac.com> <238C61D9-47F9-4B4F-B8CD-F44D79803DE4@laposte.net> Message-ID: <076B9C01-632B-477C-92D5-B1E4A29DF178@mac.com> On 22-jun-2006, at 19:37, Konrad Hinsen wrote: > On Jun 22, 2006, at 19:20, Ronald Oussoren wrote: > >> You can't please them all :-(. I'll add a warning to the readme >> text in the installer. You can turn this feature of during >> installation, the profile-editing step is a seperate package that >> you can disable using the 'Customize' button. This feature was >> discussed on this list > > OK, that's fine. I do occasionally read the readmes ;-) This is the readme at the start of the installer, you'll have to at least glance at it to install Python. > >> The current installers only install a number of symlinks in /usr/ >> local/bin, the real cannonical installation location is inside the >> python framework. The reason for this is > > I noticed, and that makes sense. > >> installation of python in the default location), but more >> importantly because distutils will by default install new scripts >> into the bin directory inside the framework. This confuses the >> heck out of most users that install new python packages from >> source, even long-time Python users. By placing the framework on >> the path thing "just work". > > That is a good argument. But if you want to change $PATH > systemwide, why not put it in .MacOSX/environment.plist? That would > have an effect in all shells and also in programs like Emacs that > look for a python executable on $PATH. Moreover, it wouldn't bother > me because my .profile redefines the path completely :-) We don't put it in ~/MacOSX/environment.plist because that file sucks. There's no way to update the value of PATH, you have to provide a complete replacement. This is too bad because I'd love to update the environment for all programs. Another disadvantage of environment.plist is that not many people know about it, using it would upset even more people that the ones that don't like updates to the shell profile. > >> Now that I've defended myself it's time to move forward again ;-). >> Why do some applications require Fink python? Is that a >> convenience issue or does Fink's python do something that the >> framework install cannot do? Or to phrase it differently, what should > > It's not so much the framework build as the fact that the binary > installers have Tkinter set up for Tcl/Tk-Aqua. Fink python is set > up for Tk/X11. Tcl-Aqua still has some bugs, and apparently also > some more serious issues with multi-threading user interfaces. > > An example of a program that doesn't work with Tk-Aqua is PyMOL > (pymol.sourceforge.net). If you multi-threading user interfaces are interfaces that update the GUI from multiple threads I'm not surprised that this doesn't work with the Aqua version of Tk. The native GUI model of OSX doesn't allow this either. Tk-Aqua also has some serious L&F issues, which is very annoying because we're shipping IDLE as the standard python IDE and because IDLE uses Tk it still looks bad even after some surgery to fix all issues that I could fix (move menu's around and implement file-open- event support). According to some Tcl/Tk sites you should use some other Tcl library to get a good native L&F, but that isn't wrapped yet and I definitely won't do that. > >> change to make you drop Fink or Darwinports for python stuff? And >> I mean that *very* broadly, I'd like to make MacPython the obvious >> choice for anyone that works with python on the mac. > > That's a good plan - I'd love to get rid of Fink if I could! I use DarwinPorts to install unix/x11 tools. Having someone else hunt down patches to make stuff work on darwin is much more convenient than doing it myself. But a seperate unix installation shouldn't be necessary to use Python. Ronald From rowen at cesmail.net Thu Jun 22 23:39:40 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Thu, 22 Jun 2006 14:39:40 -0700 Subject: [Pythonmac-SIG] Altering .profile during installation--a question Message-ID: As was recently discussed the 2.5b1 installer modifies .profile to put the framework python's bin directory on the path. But...what happens if one runs the installer again, or installs a later python. Does it somehow realize modification has already been done and need not be done again? If it realizes the modification has been done, how does it do that? (In particular, I have my .bash_profile put the following on my PATH: /Library/Frameworks/Python.framework/Versions/Current/bin Will the installer see that on PATH and realize I don't need .profile mucked with?) -- Russell From bob at redivi.com Thu Jun 22 23:50:33 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 22 Jun 2006 14:50:33 -0700 Subject: [Pythonmac-SIG] Altering .profile during installation--a question In-Reply-To: References: Message-ID: On Jun 22, 2006, at 2:39 PM, Russell E. Owen wrote: > As was recently discussed the 2.5b1 installer modifies .profile to put > the framework python's bin directory on the path. > > But...what happens if one runs the installer again, or installs a > later > python. Does it somehow realize modification has already been done and > need not be done again? > > If it realizes the modification has been done, how does it do that? > > (In particular, I have my .bash_profile put the following on my PATH: > /Library/Frameworks/Python.framework/Versions/Current/bin > Will the installer see that on PATH and realize I don't need .profile > mucked with?) I think it may add it again, but that's harmless. -bob From jmgore75 at gmail.com Fri Jun 23 09:09:17 2006 From: jmgore75 at gmail.com (Jeremy Gore) Date: Fri, 23 Jun 2006 03:09:17 -0400 Subject: [Pythonmac-SIG] psyco illegal hardware instruction Message-ID: I've been encountering strange illegal hardware errors with psyco. As far as I can tell, it doesn't like print statements (!) or raising to powers in my bound functions. I had seen about the powers issue, but print? That's news to me. I use a MacBook Pro with the pythonmac prebuilt universal python and psyco. Any hope this will be fixed? The psyco speed increases are a godsend for my purposes. I can work around it but it's kind of a pain. Jeremy From bob at redivi.com Fri Jun 23 09:50:04 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 23 Jun 2006 00:50:04 -0700 Subject: [Pythonmac-SIG] psyco illegal hardware instruction In-Reply-To: References: Message-ID: <59C67F21-5AC4-44CC-B1D4-F62467BB28E2@redivi.com> On Jun 23, 2006, at 12:09 AM, Jeremy Gore wrote: > I've been encountering strange illegal hardware errors with psyco. > As far as I can tell, it doesn't like print statements (!) or raising > to powers in my bound functions. I had seen about the powers issue, > but print? That's news to me. I use a MacBook Pro with the > pythonmac prebuilt universal python and psyco. > > Any hope this will be fixed? The psyco speed increases are a godsend > for my purposes. I can work around it but it's kind of a pain. psyco does not work correctly on OS X. There are previous threads discussing why (it's a stack alignment issue). Fixing it is not easy. -bob From robin.meier at free.fr Fri Jun 23 14:33:20 2006 From: robin.meier at free.fr (robin meier) Date: Fri, 23 Jun 2006 14:33:20 +0200 Subject: [Pythonmac-SIG] py2app error Message-ID: hello, i installed pyobjc from here http://pyobjc.sourceforge.net/software/ on my os 10.4.6 i then tried to run the py2app example "simple" which is in / developer/python/py2app/examples/simple by typing the command python setup.py py2app it starts and seems to go well, but then stops with the following error: /usr/bin/strip: for architecture i386 object: /Developer/Python/ py2app/Examples/simple/dist/hello.app/Contents/MacOS/hello malformed object (unknown flavor for flavor number 0 in LC_UNIXTHREAD command 14 can't byte swap it) stripping saved 2271688 bytes (2952104 / 5223792) what's wrong? any help appreciated. thanks in advance, robin From konrad.hinsen at laposte.net Fri Jun 23 17:45:06 2006 From: konrad.hinsen at laposte.net (Konrad Hinsen) Date: Fri, 23 Jun 2006 17:45:06 +0200 Subject: [Pythonmac-SIG] python 2.5b1 In-Reply-To: <076B9C01-632B-477C-92D5-B1E4A29DF178@mac.com> References: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> <1C2E8255-BEA3-492A-B78A-D40009992CB9@mac.com> <238C61D9-47F9-4B4F-B8CD-F44D79803DE4@laposte.net> <076B9C01-632B-477C-92D5-B1E4A29DF178@mac.com> Message-ID: On Jun 22, 2006, at 20:10, Ronald Oussoren wrote: > We don't put it in ~/MacOSX/environment.plist because that file > sucks. There's no way to update the value of PATH, you have to > provide a complete replacement. This is too bad because I'd love to > update the environment for all programs. If the file exists, you could take the path from it, add what you want, and put it back into the file. If the file does not exist, you would have to put the Python stuff plus the system default path in there to make sure that nothing else changes for the user. > Another disadvantage of environment.plist is that not many people > know about it, using it would upset even more people that the ones > that don't like updates to the shell profile. That's indeed a problem. > Tk-Aqua also has some serious L&F issues, which is very annoying > because we're shipping IDLE as the standard python IDE and because > IDLE uses Tk it still looks bad Indeed. I tend to prefer Tk with X11. Is it possible (with reasonable effort) to build the framework binaries with support for X11 rather than Aqua? Or, better yet, provide both in the binary and let the user choose at installation time? > I use DarwinPorts to install unix/x11 tools. Having someone else > hunt down patches to make stuff work on darwin is much more > convenient than doing it myself. But a seperate unix installation > shouldn't be necessary to use Python. Perhaps I should look at DarwinPorts... Konrad. From woklist at kyngchaos.com Fri Jun 23 18:43:52 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri, 23 Jun 2006 11:43:52 -0500 Subject: [Pythonmac-SIG] mod_python with universal 2.4.3? Message-ID: <8BA77998-F9DD-479B-AFB3-76F1B860F5AA@kyngchaos.com> Has anyone tried to build mod_python 2.7.11 for apache 1.3? I have 2 problems: - while it finds the universal Python 2.4.3 framework, it wants to link against /Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/config/libpython2.4.a. Which isn't in the universal Python distribution. Is there a dynamic python library to use, or what should be done to get this to work? - it doesn't build universal. It not being a python extension, I can understand this, and if the first problem is solved I can probably figure this out. ----- William Kyngesburye http://www.kyngchaos.com/ "Time is an illusion - lunchtime doubly so." - Ford Prefect From durin at sbcglobal.net Fri Jun 23 19:13:55 2006 From: durin at sbcglobal.net (Augie Fackler) Date: Fri, 23 Jun 2006 13:13:55 -0400 Subject: [Pythonmac-SIG] Visual Python using darwinports Message-ID: I've been working on getting Visual Python working through DarwinPorts, and I've gotten the thing to compile, but I've hit a snag and I'm not sure how to debug it. In particular, when I try to import visual, python dies thus: Python 2.4.3 (#1, Jun 20 2006, 14:17:56) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from visual import * Fatal Python error: Interpreter not initialized (version mismatch?) zsh: abort python When I check with otool -L on the .so that Visual Python installed, I see this: /opt/local/lib/python2.4/site-packages/cvisualmodule.so: /opt/local/Library/Frameworks/Python.framework/Versions/2.4/Python (compatibility version 2.4.0, current version 2.4.0) /opt/local/lib/libgtk-1.2.0.dylib (compatibility version 10.0.0, current version 10.1.0) /opt/local/lib/libgdk-1.2.0.dylib (compatibility version 10.0.0, current version 10.1.0) /opt/local/lib/libgmodule-1.2.0.dylib (compatibility version 1.0.0, current version 1.10.0) /opt/local/lib/libglib-1.2.0.dylib (compatibility version 1.0.0, current version 1.10.0) /opt/local/lib/libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0) /usr/X11R6/lib/libXext.6.dylib (compatibility version 6.4.0, current version 6.4.0) /usr/X11R6/lib/libX11.6.dylib (compatibility version 6.2.0, current version 6.2.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.5) /usr/X11R6/lib/libGL.1.dylib (compatibility version 1.2.0, current version 1.2.0) /usr/X11R6/lib/libGLU.1.dylib (compatibility version 1.3.0, current version 1.3.0) /opt/local/lib/libgthread-1.2.0.dylib (compatibility version 1.0.0, current version 1.10.0) /opt/local/lib/libboost_python-1_33_1.dylib (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Which tells me that I'm linking against (I think) the right framework for the interpreter to be initialized. Can anyone steer me in the right direction for debugging this? Thanks, Augie Fackler From python at blackslens.com Sun Jun 25 19:28:41 2006 From: python at blackslens.com (Black) Date: Sun, 25 Jun 2006 12:28:41 -0500 Subject: [Pythonmac-SIG] Building universal PyOpenGL In-Reply-To: <449A0A6E.9020904@cognitoy.com> References: <449A0A6E.9020904@cognitoy.com> Message-ID: <470D5CFD-502B-49B2-BFB1-3A305B0A0655@blackslens.com> I had exactly the same problem when I tried to compile PyOpenGL on my MacBook Pro. However, my searching on the Internet went a little better than yours. I found an older post on the PyOpenGL list that actually had fix. It turns out that the problem is that the wrong stat.h is being used. All you need to do is remove /System/Library/Frameworks/ Kernel.framework/Headers from the list of include_dirs in the darwin.cfg file in the config directory. I removed it and it compiled like a charm. It took me a little longer to get OpenGL and wxPython working happily together as the package on pythonmac has a broken glcanvas so I had to roll my own version. That only took me a little while because I did a configure/make/make install _before_ reading the READMEs and while I know better than that, I don't always pay attention to myself... On Jun 21, 2006, at 10:11 PM, Kent Quirk wrote: > Hi. I got my new MacBook and looked on pythonmac.org for prebuilt > packages for universal python 2.4.3. I've got wxPython and it seems to > work, but I also need PyOpenGL, and it's not listed up there. So I got > the source and I'm trying to build it. > > The problem is that it's not building -- many of the source files > fail with: > > /System/Library/Frameworks/Kernel.framework/Headers/sys/stat.h:225: > error: field 'st_atimespec' has incomplete type > /System/Library/Frameworks/Kernel.framework/Headers/sys/stat.h:226: > error: field 'st_mtimespec' has incomplete type > /System/Library/Frameworks/Kernel.framework/Headers/sys/stat.h:227: > error: field 'st_ctimespec' has incomplete type > > So...I guess what I'm looking for is advice on which direction to > pursue. Is there a valid fix that can be made to PyOpenGL source that > would address this? Should I submit a bug report and/or patch to the > Python people? To Apple? I'd like to get to the point of a useful > universal build of PyOpenGL. > > Advice? > > Kent > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From robin.meier at free.fr Mon Jun 26 00:54:36 2006 From: robin.meier at free.fr (robin meier) Date: Mon, 26 Jun 2006 00:54:36 +0200 Subject: [Pythonmac-SIG] numarray and py2app In-Reply-To: References: Message-ID: hello pythonistas, i have this python script which makes use of numarray and numarray.random_array. i manage to run python setup.py py2app -A and mange to create a distributable application when not loading the two numarray libraries. but when i run python setup.py py2app with the numarray libs, the process ends with /usr/bin/strip: for architecture i386 object: /somxmlsrc/dist/ SomXML.app/Contents/MacOS/SomXML malformed object (unknown flavor for flavor number 0 in LC_UNIXTHREAD command 14 can't byte swap it) anyone know why? what can i do to remedy this? thank you for your help, robin From bob at redivi.com Mon Jun 26 01:29:28 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 25 Jun 2006 16:29:28 -0700 Subject: [Pythonmac-SIG] numarray and py2app In-Reply-To: References: Message-ID: On Jun 25, 2006, at 3:54 PM, robin meier wrote: > hello pythonistas, > > i have this python script which makes use of numarray and > numarray.random_array. > i manage to run python setup.py py2app -A and mange to create a > distributable application when not loading the two numarray libraries. > but when i run python setup.py py2app with the numarray libs, the > process ends with py2app -A does not create redistributable applications. > /usr/bin/strip: for architecture i386 object: /somxmlsrc/dist/ > SomXML.app/Contents/MacOS/SomXML malformed object (unknown flavor for > flavor number 0 in LC_UNIXTHREAD command 14 can't byte swap it) > > anyone know why? what can i do to remedy this? > thank you for your help, Must be a bug in macholib I guess. If you can send me something that I can use to reproduce that problem I'll take a look at it eventually. -bob From hellzfury at gmail.com Tue Jun 27 01:04:48 2006 From: hellzfury at gmail.com (Matthew Strax-Haber) Date: Mon, 26 Jun 2006 19:04:48 -0400 Subject: [Pythonmac-SIG] Python on Intel Message-ID: I have a MacBook Pro running MacOS X 10.4.6. What version of Python can/should I install that can run as a Universal binary? I found one version at: http://www.python.org/ftp/python/2.4.3/Universal-MacPython-2.4.3.dmg I installed this. I remember that on my PPC laptop I had to then install something else on top of that so it wouldn't break Apple's version of Python. Should I do something similar on my Intel mac, or will it run just fine the way it is? Thank you in advance for the help, ~Matthew Strax-Haber From bob at redivi.com Tue Jun 27 01:36:03 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 26 Jun 2006 16:36:03 -0700 Subject: [Pythonmac-SIG] Python on Intel In-Reply-To: References: Message-ID: <03910395-2AD4-4155-B6CD-D122475994B6@redivi.com> On Jun 26, 2006, at 4:04 PM, Matthew Strax-Haber wrote: > I have a MacBook Pro running MacOS X 10.4.6. What version of Python > can/should I install that can run as a Universal binary? > > I found one version at: > http://www.python.org/ftp/python/2.4.3/Universal-MacPython-2.4.3.dmg > > I installed this. I remember that on my PPC laptop I had to then > install something else on top of that so it wouldn't break Apple's > version of Python. Should I do something similar on my Intel mac, or > will it run just fine the way it is? The most recent version is always here: http://pythonmac.org/packages/py24-fat/index.html The one at python.org may be out of date, I'm not sure. You don't need to install anything else. -bob From ronaldoussoren at mac.com Tue Jun 27 09:21:05 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 27 Jun 2006 09:21:05 +0200 Subject: [Pythonmac-SIG] Python on Intel In-Reply-To: <03910395-2AD4-4155-B6CD-D122475994B6@redivi.com> References: <03910395-2AD4-4155-B6CD-D122475994B6@redivi.com> Message-ID: <6A1F9D6D-46F4-4D2F-BE28-8A7526B00B35@mac.com> On 27-jun-2006, at 1:36, Bob Ippolito wrote: > > On Jun 26, 2006, at 4:04 PM, Matthew Strax-Haber wrote: > >> I have a MacBook Pro running MacOS X 10.4.6. What version of Python >> can/should I install that can run as a Universal binary? >> >> I found one version at: >> http://www.python.org/ftp/python/2.4.3/Universal-MacPython-2.4.3.dmg >> >> I installed this. I remember that on my PPC laptop I had to then >> install something else on top of that so it wouldn't break Apple's >> version of Python. Should I do something similar on my Intel mac, or >> will it run just fine the way it is? > > The most recent version is always here: > > http://pythonmac.org/packages/py24-fat/index.html > > The one at python.org may be out of date, I'm not sure. The one at python.org is current as well at the moment, but that's only because we haven't done updates to the universal build for a while. The major advantage of the pythonmac.org link is that you'll find binary installers for a number of usefull extensions as well. Ronald From ronaldoussoren at mac.com Tue Jun 27 16:51:01 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 27 Jun 2006 16:51:01 +0200 Subject: [Pythonmac-SIG] [Python-Dev] Problems building Python on OSX 10.4.6? In-Reply-To: <20060627143827.45945.qmail@web52303.mail.yahoo.com> References: <20060627143827.45945.qmail@web52303.mail.yahoo.com> Message-ID: <33D3C404-5295-4BE8-AE58-C9DAF1633A85@mac.com> Most, if not all, of this is deemed off-topic of python-dev, I'm continuing this conversation on the mac-sig. On 27-jun-2006, at 16:38, J. Jeffrey Close wrote: > > Hi Ronald, > > Thanks very much for the feedback. > > A few points and answers -- > >>>> > Which sources are you using? The 2.4.x tarballs don't support -- > enable-universalsdk (and yes, configure won't complain about unknown > or misspelled options, that's an entirely different subject). Those > SDKs also don't support mixing --prefix and --enable-framework, the > prefix argument will be ignored completely. Python 2.5 does support -- > enable-universalsdk and specifiying other prefixes when using -- > enable-framework. I have a patch that backports this to 2.4.x, but > haven't applied this yet because I haven't had time to fully test > this yet, hopefully I'll manage this week. > > BTW. --enable-framework --with-pydebug is all you need, the others > are either default or deduced from the platform information by > configure. > > And completely off-topic: please don't install your own build of > python as /usr/bin/python. IMHO this is conceptually bad, but more > importantly Apple uses python in some parts of the OS (PDF workflows > for example) and this change could well break that. > <<< > > [JJC] > OK, I may try 2.5, see if that helps. yes I was warned about /usr, > and actually wasn't using that anymore I'm glad to hear that. > >>>> > What version of the developer tools are you using? And are you > building on PPC or Intel? > > One way to work around the problems you're having is to install the > binary install of 2.4.3. > <<< > > [JJC] > The reason that I need the source build is that I am trying to > build mod_python, and the binary does not install the libpython. > 2.4.a library that mod_python needs. Building from source won't help with that. If you do a framework install you will not get a libpython*.a, or even a libpython*.dylib. Most if not all projects that require such a library are wrong and should add support code for OSX. I am however tempted to add a symlink inside the Python.framework to get rid of discussions about this. > > I'm using an Intel machine and another modification I have to do is > to edit the Makefile to change "arch_only" to i386 (apparently an > error in configure). Nah, it's a feature ;-). > >>>> > Obviously someone must have managed, there's a binary installer for > the OS :-). And before you nobody that ran into this problem found > it important enough to actually tell us about is. > Ronald > <<< > > Yes, the binary installer works great but as I mentioned, does not > install all needed dev pieces. And before me, MANY people have run > into this (do a google for some of the errors that I've mentioned, > like +"___eprintf" +"OS X" , or mod_python and OSX, and you will > find many. And yet you're the first one that actually mentions these issues at a venue where they may get resolved :-(. I'll see what I can do to get mod_python to build (but no promises at to when that will happen) As I mentioned above, building from source won't install more files than are installed right now, unless you use a normal unix install of python. Ronald From Chris.Barker at noaa.gov Wed Jun 28 00:16:38 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 27 Jun 2006 15:16:38 -0700 Subject: [Pythonmac-SIG] python 2.5b1 In-Reply-To: <076B9C01-632B-477C-92D5-B1E4A29DF178@mac.com> References: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> <1C2E8255-BEA3-492A-B78A-D40009992CB9@mac.com> <238C61D9-47F9-4B4F-B8CD-F44D79803DE4@laposte.net> <076B9C01-632B-477C-92D5-B1E4A29DF178@mac.com> Message-ID: <44A1AE46.2020904@noaa.gov> Ronald Oussoren wrote: > But a seperate unix installation shouldn't be > necessary to use Python. I've managed to keep my system Darwinports and fink free, but sometimes it's hard. It's apparently much easier to do a straight port of something that already works on Linux (and other *nixes) to fink, than to get it to compile and install right in native OS-X. It's not python itself -- MacPython does everything it needs to. the issue is python stuff that requires other *nix libs and packages. Many of these are available in fink, but not in an easy-to-install-and-use version for native OS-X. We can fix some of that by adding a LOT more packages to the pythonmac.org repository. Another issue is that Apple has not provided a packaging system for OS-X. There is no way to install a package you need, and have the system go and install all the dependencies for you. fink makes that easy. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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 Fri Jun 23 11:19:03 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 23 Jun 2006 11:19:03 +0200 Subject: [Pythonmac-SIG] Altering .profile during installation--a question In-Reply-To: References: Message-ID: On 22-jun-2006, at 23:50, Bob Ippolito wrote: > On Jun 22, 2006, at 2:39 PM, Russell E. Owen wrote: > >> As was recently discussed the 2.5b1 installer modifies .profile to >> put >> the framework python's bin directory on the path. >> >> But...what happens if one runs the installer again, or installs a >> later >> python. Does it somehow realize modification has already been done >> and >> need not be done again? >> >> If it realizes the modification has been done, how does it do that? >> >> (In particular, I have my .bash_profile put the following on my PATH: >> /Library/Frameworks/Python.framework/Versions/Current/bin >> Will the installer see that on PATH and realize I don't need .profile >> mucked with?) > > I think it may add it again, but that's harmless. The installer should notice that your PATH already contains the right directory and will not update your profile again. You can test this by using the .command file in /applications/macpython 2.5. That's the same script as used by the installer. Ronald From ronaldoussoren at mac.com Wed Jun 28 08:20:17 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 28 Jun 2006 08:20:17 +0200 Subject: [Pythonmac-SIG] python 2.5b1 In-Reply-To: <44A1AE46.2020904@noaa.gov> References: <3654766.1150879361941.JavaMail.ronaldoussoren@mac.com> <9C29886C-6B79-40E3-A43D-EE03A19B5F68@laposte.net> <1C2E8255-BEA3-492A-B78A-D40009992CB9@mac.com> <238C61D9-47F9-4B4F-B8CD-F44D79803DE4@laposte.net> <076B9C01-632B-477C-92D5-B1E4A29DF178@mac.com> <44A1AE46.2020904@noaa.gov> Message-ID: <9F3751A3-7152-4CC5-8B91-DCCC90E64917@mac.com> On 28-jun-2006, at 0:16, Christopher Barker wrote: > Ronald Oussoren wrote: >> But a seperate unix installation shouldn't be necessary to use >> Python. > > I've managed to keep my system Darwinports and fink free, but > sometimes it's hard. It's apparently much easier to do a straight > port of something that already works on Linux (and other *nixes) to > fink, than to get it to compile and install right in native OS-X. > > It's not python itself -- MacPython does everything it needs to. > the issue is python stuff that requires other *nix libs and > packages. Many of these are available in fink, but not in an easy- > to-install-and-use version for native OS-X. We can fix some of that > by adding a LOT more packages to the pythonmac.org repository. Feel free to suggest, and preferably supply additional packages. > > Another issue is that Apple has not provided a packaging system for > OS-X. There is no way to install a package you need, and have the > system go and install all the dependencies for you. fink makes that > easy. I never said it would be easy :-). Python eggs solve at least part of the packaging problems. I'd also like to get some build infrastructure going, I have a script that I use to build packages for things that I usse but that needs to be cleaned up before it can be reused. My idea for this is to have recipes that specify how to build packages (e.g. first build this version of libxml, then libxslt and then build an egg of lxml) and use that the fill the package repository at pythonmac.org. Any patches that are needed for building should be pushed up streams. Ronald From marc at precipice.org Wed Jun 28 08:51:02 2006 From: marc at precipice.org (Marc Hedlund) Date: Wed, 28 Jun 2006 01:51:02 -0500 (CDT) Subject: [Pythonmac-SIG] 40% size increase for Universal? Message-ID: I just did my first build of a Python app using the Universal Python 2.4.3 package, py2app-0.2.5-py2.4-macosx10.4.zip, wxPython2.6-osx-unicode-2.6.3.2rc2-universal10.4-py2.4.dmg, and pycrypto-2.0.1_py2.4.zip (which I found in the "Kitchen Sink" package at ). The resulting binary built on the first try, which is great. However, it went from 11.5 Megs (previous build on Mac/Intel, using 2.4.1 and non-universal packages) to about 16 Megs. Is that about par for the course? Any suggestions for paring it down? (The same binary on Windows/py2exe is about 5.5 Megs.) Thanks much. -M From bob at redivi.com Wed Jun 28 09:55:11 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 28 Jun 2006 00:55:11 -0700 Subject: [Pythonmac-SIG] 40% size increase for Universal? In-Reply-To: References: Message-ID: <23F65048-AE89-48F5-8348-BA1B816CBFCB@redivi.com> On Jun 27, 2006, at 11:51 PM, Marc Hedlund wrote: > > I just did my first build of a Python app using the Universal > Python 2.4.3 > package, py2app-0.2.5-py2.4-macosx10.4.zip, > wxPython2.6-osx-unicode-2.6.3.2rc2-universal10.4-py2.4.dmg, and > pycrypto-2.0.1_py2.4.zip (which I found in the "Kitchen Sink" > package at > ). > > The resulting binary built on the first try, which is great. > However, it > went from 11.5 Megs (previous build on Mac/Intel, using 2.4.1 and > non-universal packages) to about 16 Megs. Is that about par for the > course? Any suggestions for paring it down? (The same binary on > Windows/py2exe is about 5.5 Megs.) It's expected that a universal build should be roughly 2x the code size. You're not going to pare it down very much, but compression solves most of these problems because there's a lot of redundancy. You should really only be looking at the zipped or dmg'ed size of the executable. -bob From glassfordm at hotmail.com Wed Jun 28 19:02:04 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Wed, 28 Jun 2006 13:02:04 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 Message-ID: I've built a universal binary build of an application that runs great on the Tiger machines that I've tested it on (both PowerPC and Intel). However, when I try to run it on PowerPC 10.3.9 (which I've been led to believe should work from comments in the PyObjC svn log), I get this error: """ ImportError: Failure linking new module: /usr/lib/libbz2.1.0.dylib: dyld: /Volumes/GoombahDisk/Goombah.app/Contents/MacOS/Goombah can't open library: /usr/lib/libbz2.1.0.dylib (No such file or directory, errno = 2) """ When I investigate, /usr/lib/libbz2.1.0.dylib is present on the Tiger machine I've checked but not on the Panther machine where I'm having the problem, so that makes sense. The application does in fact use the bzip2 library; the error happens on an "import bz2" statement. And Py2App py2app is including bz2.so in MyApp.app/Contents/Resources/Python/lib-dynload. But apparently bz2.so links to /usr/lib/libbz2.1.0.dylib. The question is, how do I get py2app to include the necessary files to eliminate this dependency? Or what else can I do? Mike From bob at redivi.com Wed Jun 28 20:03:34 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 28 Jun 2006 11:03:34 -0700 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: References: Message-ID: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> On Jun 28, 2006, at 10:02 AM, Michael Glassford wrote: > I've built a universal binary build of an application that runs > great on > the Tiger machines that I've tested it on (both PowerPC and > Intel). > However, when I try to run it on PowerPC 10.3.9 (which I've been > led to > believe should work from comments in the PyObjC svn log), I get > this error: Python itself works on 10.3.9 as compiled universally. Not every single extension has been audited for compatibility, obviously. > """ > ImportError: Failure linking new module: /usr/lib/libbz2.1.0.dylib: > dyld: /Volumes/GoombahDisk/Goombah.app/Contents/MacOS/Goombah can't > open > library: /usr/lib/libbz2.1.0.dylib (No such file or directory, > errno = 2) > """ > > When I investigate, /usr/lib/libbz2.1.0.dylib is present on the Tiger > machine I've checked but not on the Panther machine where I'm > having the > problem, so that makes sense. The application does in fact use the > bzip2 > library; the error happens on an "import bz2" statement. And Py2App > py2app is including bz2.so in > MyApp.app/Contents/Resources/Python/lib-dynload. But apparently bz2.so > links to /usr/lib/libbz2.1.0.dylib. > > The question is, how do I get py2app to include the necessary files to > eliminate this dependency? Or what else can I do? There's nothing you can really do about this other than replace the bz2 extension with one that links statically and universally against your own copy of libbz2. For some reason Panther had a static libbz2 and Tiger made it dynamic. -bob From ronaldoussoren at mac.com Wed Jun 28 20:28:11 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 28 Jun 2006 20:28:11 +0200 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: References: Message-ID: On 28-jun-2006, at 19:02, Michael Glassford wrote: > I've built a universal binary build of an application that runs > great on > the Tiger machines that I've tested it on (both PowerPC and > Intel). > However, when I try to run it on PowerPC 10.3.9 (which I've been > led to > believe should work from comments in the PyObjC svn log), I get > this error: > > """ > ImportError: Failure linking new module: /usr/lib/libbz2.1.0.dylib: > dyld: /Volumes/GoombahDisk/Goombah.app/Contents/MacOS/Goombah can't > open > library: /usr/lib/libbz2.1.0.dylib (No such file or directory, > errno = 2) > """ > > When I investigate, /usr/lib/libbz2.1.0.dylib is present on the Tiger > machine I've checked but not on the Panther machine where I'm > having the > problem, so that makes sense. The application does in fact use the > bzip2 > library; the error happens on an "import bz2" statement. And Py2App > py2app is including bz2.so in > MyApp.app/Contents/Resources/Python/lib-dynload. But apparently bz2.so > links to /usr/lib/libbz2.1.0.dylib. > > The question is, how do I get py2app to include the necessary files to > eliminate this dependency? Or what else can I do? I just fixed this for Python 2.5. We'll have to include a staticly linked copy of libz22 in the installer, just like we're doing for bsddb. For 2.5 I'm doing the same with sqlite (new in 2.5) and zlib (2.5 uses functionality that isn't present in the Panther version of zlib). Its getting more and more clear that I can't get way with not updating the 2.4 installer :-(. Ronald From jordan.breeding at mac.com Wed Jun 28 20:44:28 2006 From: jordan.breeding at mac.com (Jordan Breeding) Date: Wed, 28 Jun 2006 13:44:28 -0500 Subject: [Pythonmac-SIG] Fwd: Re: python appscript is displaying warning/errors sometimes In-Reply-To: References: Message-ID: <15961016.1151520269041.JavaMail.jordan.breeding@mac.com> Hello, Do you think that the Python 2.4.3 Universal build could be having this effect with python and pythonw now combined? I don't see these messages all of the time but when I do it is a block of about 10 or so of them, and I usually only get the messages once per run of a script even when they do show up. I tried googling around and it seems like this message means something was marked autorelease in Cocoa somewhere but without a pool in place. Please let me know if you think you know what is going on but need more information. The problem might also be present in the 2.5b1 Universal, don't know yet because I don't have an appscript module for python built yet that will work with 2.5b1. Thanks, Jordan From: has To: Jordan Breeding Date: Wed Jun 28, 2006 11:31:03 AM CDT Subject: Re: python appscript is displaying warning/errors sometimes Hi, > I am using appscript in python to do some various tasks in iTunes. > The scripts are organized by task. One of the scripts makes some > zip files based on a playlist and then sends them. The problem I > have is that while the script does compete all of its takes I get > this set of messages sometimes: > > 2006-06-21 09:23:26.019 Python[21992] *** _NSAutoreleaseNoPool(): > Object 0x6fa480 of class NSCFString autoreleased with no pool in > place - just leaking > ... > > I am attaching a copy of the script with servernames, usernames, > and passwords blanked out. I know it probably isn't the greatest > code in the world but it seems to get the job done and I was just > wondering if you could easily spot the place that is leaking. Hmm, dunno; not very good on that stuff. If I had to guess, I'd say check the interpreter; I think it was rewritten recently to eliminate the python/pythonw dichotomy. I don't think any of the modules in your script are using Cocoa/CoreFoundation. Sorry I can't be more helpful. Regards, has From glassfordm at gmail.com Wed Jun 28 20:46:16 2006 From: glassfordm at gmail.com (Michael Glassford) Date: Wed, 28 Jun 2006 14:46:16 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> Message-ID: <44A2CE78.9080706@hotmail.com> Bob Ippolito wrote: > On Jun 28, 2006, at 10:02 AM, Michael Glassford wrote: > >> I've built a universal binary build of an application that runs >> great on >> the Tiger machines that I've tested it on (both PowerPC and >> Intel). >> However, when I try to run it on PowerPC 10.3.9 (which I've been >> led to >> believe should work from comments in the PyObjC svn log), I get >> this error: > > Python itself works on 10.3.9 as compiled universally. Not every > single extension has been audited for compatibility, obviously. Sure, I understand that. >> """ >> ImportError: Failure linking new module: /usr/lib/libbz2.1.0.dylib: >> dyld: /Volumes/GoombahDisk/Goombah.app/Contents/MacOS/Goombah can't >> open >> library: /usr/lib/libbz2.1.0.dylib (No such file or directory, >> errno = 2) >> """ >> >> When I investigate, /usr/lib/libbz2.1.0.dylib is present on the Tiger >> machine I've checked but not on the Panther machine where I'm >> having the >> problem, so that makes sense. The application does in fact use the >> bzip2 >> library; the error happens on an "import bz2" statement. And Py2App >> py2app is including bz2.so in >> MyApp.app/Contents/Resources/Python/lib-dynload. But apparently bz2.so >> links to /usr/lib/libbz2.1.0.dylib. >> >> The question is, how do I get py2app to include the necessary files to >> eliminate this dependency? Or what else can I do? > > There's nothing you can really do about this other than replace the > bz2 extension with one that links statically and universally against > your own copy of libbz2. I'd be glad to do this, but it's not clear to me how. Can you point me to any information? > For some reason Panther had a static libbz2 > and Tiger made it dynamic. I'd be just as willing to build on 10.3.9, if possible, but have had trouble getting this working as well. So far I haven't been able to build PyObjC; I've gotten as far as this error: """ ** using pyobjc source-deps py2app for building running build running build_py running build_ext Performing task: Generating wrappers & stubs /Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python Scripts/CodeGenerators/cocoa_generator.py building 'objc._objc' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c Modules/objc/alloc_hack.m -o build/temp.macosx-10.3-fat-2.4/Modules/objc/alloc_hack.o -DMACOSX -DAPPLE_RUNTIME -no-cpp-precomp -Wno-long-double -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wformat=2 -W -Wshadow -Wpointer-arith -Wmissing-declarations -Wnested-externs -Wno-long-long -Wno-import -Ibuild/codegen/ -Ilibffi-src/include In file included from /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/Python.h:81, from Modules/objc/pyobjc.h:15, from Modules/objc/alloc_hack.m:4: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/unicodeobject.h:118:21: wchar.h: No such file or directory In file included from Modules/objc/pyobjc-compat.h:10, from Modules/objc/pyobjc.h:17, from Modules/objc/alloc_hack.m:4: /usr/include/AvailabilityMacros.h:101:6: #error MAC_OS_X_VERSION_MAX_ALLOWED must be >= MAC_OS_X_VERSION_MIN_REQUIRED error: command 'gcc' failed with exit status 1 """ Mike From glassfordm at hotmail.com Wed Jun 28 20:46:16 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Wed, 28 Jun 2006 14:46:16 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> Message-ID: <44A2CE78.9080706@hotmail.com> Bob Ippolito wrote: > On Jun 28, 2006, at 10:02 AM, Michael Glassford wrote: > >> I've built a universal binary build of an application that runs >> great on >> the Tiger machines that I've tested it on (both PowerPC and >> Intel). >> However, when I try to run it on PowerPC 10.3.9 (which I've been >> led to >> believe should work from comments in the PyObjC svn log), I get >> this error: > > Python itself works on 10.3.9 as compiled universally. Not every > single extension has been audited for compatibility, obviously. Sure, I understand that. >> """ >> ImportError: Failure linking new module: /usr/lib/libbz2.1.0.dylib: >> dyld: /Volumes/GoombahDisk/Goombah.app/Contents/MacOS/Goombah can't >> open >> library: /usr/lib/libbz2.1.0.dylib (No such file or directory, >> errno = 2) >> """ >> >> When I investigate, /usr/lib/libbz2.1.0.dylib is present on the Tiger >> machine I've checked but not on the Panther machine where I'm >> having the >> problem, so that makes sense. The application does in fact use the >> bzip2 >> library; the error happens on an "import bz2" statement. And Py2App >> py2app is including bz2.so in >> MyApp.app/Contents/Resources/Python/lib-dynload. But apparently bz2.so >> links to /usr/lib/libbz2.1.0.dylib. >> >> The question is, how do I get py2app to include the necessary files to >> eliminate this dependency? Or what else can I do? > > There's nothing you can really do about this other than replace the > bz2 extension with one that links statically and universally against > your own copy of libbz2. I'd be glad to do this, but it's not clear to me how. Can you point me to any information? > For some reason Panther had a static libbz2 > and Tiger made it dynamic. I'd be just as willing to build on 10.3.9, if possible, but have had trouble getting this working as well. So far I haven't been able to build PyObjC; I've gotten as far as this error: """ ** using pyobjc source-deps py2app for building running build running build_py running build_ext Performing task: Generating wrappers & stubs /Library/Frameworks/Python.framework/Versions/2.4/Resources/Python.app/Contents/MacOS/Python Scripts/CodeGenerators/cocoa_generator.py building 'objc._objc' extension gcc -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g -O3 -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c Modules/objc/alloc_hack.m -o build/temp.macosx-10.3-fat-2.4/Modules/objc/alloc_hack.o -DMACOSX -DAPPLE_RUNTIME -no-cpp-precomp -Wno-long-double -g -Wall -Wstrict-prototypes -Wmissing-prototypes -Wformat=2 -W -Wshadow -Wpointer-arith -Wmissing-declarations -Wnested-externs -Wno-long-long -Wno-import -Ibuild/codegen/ -Ilibffi-src/include In file included from /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/Python.h:81, from Modules/objc/pyobjc.h:15, from Modules/objc/alloc_hack.m:4: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/unicodeobject.h:118:21: wchar.h: No such file or directory In file included from Modules/objc/pyobjc-compat.h:10, from Modules/objc/pyobjc.h:17, from Modules/objc/alloc_hack.m:4: /usr/include/AvailabilityMacros.h:101:6: #error MAC_OS_X_VERSION_MAX_ALLOWED must be >= MAC_OS_X_VERSION_MIN_REQUIRED error: command 'gcc' failed with exit status 1 """ Mike From glassfordm at gmail.com Wed Jun 28 20:50:37 2006 From: glassfordm at gmail.com (Michael Glassford) Date: Wed, 28 Jun 2006 14:50:37 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: References: Message-ID: <44A2CF7D.9020604@hotmail.com> Ronald Oussoren wrote: > On 28-jun-2006, at 19:02, Michael Glassford wrote: > >> I've built a universal binary build of an application that runs >> great on >> the Tiger machines that I've tested it on (both PowerPC and >> Intel). >> However, when I try to run it on PowerPC 10.3.9 (which I've been >> led to >> believe should work from comments in the PyObjC svn log), I get >> this error: >> >> """ >> ImportError: Failure linking new module: /usr/lib/libbz2.1.0.dylib: >> dyld: /Volumes/GoombahDisk/Goombah.app/Contents/MacOS/Goombah can't >> open >> library: /usr/lib/libbz2.1.0.dylib (No such file or directory, >> errno = 2) >> """ >> >> When I investigate, /usr/lib/libbz2.1.0.dylib is present on the Tiger >> machine I've checked but not on the Panther machine where I'm >> having the >> problem, so that makes sense. The application does in fact use the >> bzip2 >> library; the error happens on an "import bz2" statement. And Py2App >> py2app is including bz2.so in >> MyApp.app/Contents/Resources/Python/lib-dynload. But apparently bz2.so >> links to /usr/lib/libbz2.1.0.dylib. >> >> The question is, how do I get py2app to include the necessary files to >> eliminate this dependency? Or what else can I do? > > I just fixed this for Python 2.5. We'll have to include a staticly > linked copy of libz22 in the installer, just like we're doing for > bsddb. For 2.5 I'm doing the same with sqlite (new in 2.5) and zlib > (2.5 uses functionality that isn't present in the Panther version of > zlib). Any pointers on how I could hack something like this in? Unless... > Its getting more and more clear that I can't get way with not > updating the 2.4 installer :-(. Would you be thinking of doing this soon? :) Mike From glassfordm at hotmail.com Wed Jun 28 20:50:37 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Wed, 28 Jun 2006 14:50:37 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: References: Message-ID: <44A2CF7D.9020604@hotmail.com> Ronald Oussoren wrote: > On 28-jun-2006, at 19:02, Michael Glassford wrote: > >> I've built a universal binary build of an application that runs >> great on >> the Tiger machines that I've tested it on (both PowerPC and >> Intel). >> However, when I try to run it on PowerPC 10.3.9 (which I've been >> led to >> believe should work from comments in the PyObjC svn log), I get >> this error: >> >> """ >> ImportError: Failure linking new module: /usr/lib/libbz2.1.0.dylib: >> dyld: /Volumes/GoombahDisk/Goombah.app/Contents/MacOS/Goombah can't >> open >> library: /usr/lib/libbz2.1.0.dylib (No such file or directory, >> errno = 2) >> """ >> >> When I investigate, /usr/lib/libbz2.1.0.dylib is present on the Tiger >> machine I've checked but not on the Panther machine where I'm >> having the >> problem, so that makes sense. The application does in fact use the >> bzip2 >> library; the error happens on an "import bz2" statement. And Py2App >> py2app is including bz2.so in >> MyApp.app/Contents/Resources/Python/lib-dynload. But apparently bz2.so >> links to /usr/lib/libbz2.1.0.dylib. >> >> The question is, how do I get py2app to include the necessary files to >> eliminate this dependency? Or what else can I do? > > I just fixed this for Python 2.5. We'll have to include a staticly > linked copy of libz22 in the installer, just like we're doing for > bsddb. For 2.5 I'm doing the same with sqlite (new in 2.5) and zlib > (2.5 uses functionality that isn't present in the Panther version of > zlib). Any pointers on how I could hack something like this in? Unless... > Its getting more and more clear that I can't get way with not > updating the 2.4 installer :-(. Would you be thinking of doing this soon? :) Mike From bob at redivi.com Wed Jun 28 20:56:53 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 28 Jun 2006 11:56:53 -0700 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <44A2CE78.9080706@hotmail.com> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> Message-ID: <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> On Jun 28, 2006, at 11:46 AM, Michael Glassford wrote: > Bob Ippolito wrote: >> On Jun 28, 2006, at 10:02 AM, Michael Glassford wrote: >>> I've built a universal binary build of an application that runs >>> great on >>> the Tiger machines that I've tested it on (both PowerPC and >>> Intel). >>> However, when I try to run it on PowerPC 10.3.9 (which I've been >>> led to >>> believe should work from comments in the PyObjC svn log), I get >>> this error: >> Python itself works on 10.3.9 as compiled universally. Not every >> single extension has been audited for compatibility, obviously. > > Sure, I understand that. > >>> """ >>> ImportError: Failure linking new module: /usr/lib/libbz2.1.0.dylib: >>> dyld: /Volumes/GoombahDisk/Goombah.app/Contents/MacOS/Goombah >>> can't open >>> library: /usr/lib/libbz2.1.0.dylib (No such file or directory, >>> errno = 2) >>> """ >>> >>> When I investigate, /usr/lib/libbz2.1.0.dylib is present on the >>> Tiger >>> machine I've checked but not on the Panther machine where I'm >>> having the >>> problem, so that makes sense. The application does in fact use >>> the bzip2 >>> library; the error happens on an "import bz2" statement. And Py2App >>> py2app is including bz2.so in >>> MyApp.app/Contents/Resources/Python/lib-dynload. But apparently >>> bz2.so >>> links to /usr/lib/libbz2.1.0.dylib. >>> >>> The question is, how do I get py2app to include the necessary >>> files to >>> eliminate this dependency? Or what else can I do? >> There's nothing you can really do about this other than replace >> the bz2 extension with one that links statically and universally >> against your own copy of libbz2. > > I'd be glad to do this, but it's not clear to me how. Can you point > me to any information? The bz2 module is part of the Python distribution. The best route would be to download the Python source, extract the source for the bz2 extension and create a standalone setup.py for it. Tweak it such that it links to a copy of libbz2 that you've compiled statically and universally, and then replace your Python installation's bz2 with that one. It's not really trivial, but it's the only option you have unless someone else does it first. It sounds like Ronald will probably create another 2.4.3 installer in the future that fixes this and a few other issues, but I don't know when he'll get around to it (if ever, I don't speak for his free time). In your situation, I would just give up on 10.3 users until the issue with Python is resolved (which is either going to happen when 2.5 comes out, or when the 2.4.3 installer gets updated). -bob From bob at redivi.com Wed Jun 28 21:01:15 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 28 Jun 2006 12:01:15 -0700 Subject: [Pythonmac-SIG] Fwd: Re: python appscript is displaying warning/errors sometimes In-Reply-To: <15961016.1151520269041.JavaMail.jordan.breeding@mac.com> References: <15961016.1151520269041.JavaMail.jordan.breeding@mac.com> Message-ID: <3CDEC8AB-3764-4597-BDA4-016D0154C502@redivi.com> pythonw is and always has been a stub that launches a regular python interpreter. There is nothing special about it except for the path the regular interpreter is located at. The only thing it can do is enable WindowServer access; it shouldn't ever cause any issues (especially of this sort). In other words, it is absolutely not your problem. The script isn't attached. I doubt anyone will be able to help you on this without source code. You are correct about the message's meaning, but without source the cause can't be determined. -bob On Jun 28, 2006, at 11:44 AM, Jordan Breeding wrote: > Hello, > > Do you think that the Python 2.4.3 Universal build could be having > this effect with python and pythonw now combined? I don't see > these messages all of the time but when I do it is a block of about > 10 or so of them, and I usually only get the messages once per run > of a script even when they do show up. I tried googling around and > it seems like this message means something was marked autorelease > in Cocoa somewhere but without a pool in place. Please let me know > if you think you know what is going on but need more information. > The problem might also be present in the 2.5b1 Universal, don't > know yet because I don't have an appscript module for python built > yet that will work with 2.5b1. > > Thanks, > Jordan > > From: has > To: Jordan Breeding > Date: Wed Jun 28, 2006 11:31:03 AM CDT > Subject: Re: python appscript is displaying warning/errors sometimes > > Hi, > >> I am using appscript in python to do some various tasks in iTunes. >> The scripts are organized by task. One of the scripts makes some >> zip files based on a playlist and then sends them. The problem I >> have is that while the script does compete all of its takes I get >> this set of messages sometimes: >> >> 2006-06-21 09:23:26.019 Python[21992] *** _NSAutoreleaseNoPool(): >> Object 0x6fa480 of class NSCFString autoreleased with no pool in >> place - just leaking >> ... >> >> I am attaching a copy of the script with servernames, usernames, >> and passwords blanked out. I know it probably isn't the greatest >> code in the world but it seems to get the job done and I was just >> wondering if you could easily spot the place that is leaking. > > Hmm, dunno; not very good on that stuff. If I had to guess, I'd say > check the interpreter; I think it was rewritten recently to eliminate > the python/pythonw dichotomy. I don't think any of the modules in > your script are using Cocoa/CoreFoundation. Sorry I can't be more > helpful. > > Regards, > > has > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From jordan.breeding at mac.com Wed Jun 28 21:26:38 2006 From: jordan.breeding at mac.com (Jordan Breeding) Date: Wed, 28 Jun 2006 14:26:38 -0500 Subject: [Pythonmac-SIG] Fwd: Re: python appscript is displaying warning/errors sometimes In-Reply-To: <3CDEC8AB-3764-4597-BDA4-016D0154C502@redivi.com> References: <15961016.1151520269041.JavaMail.jordan.breeding@mac.com> <3CDEC8AB-3764-4597-BDA4-016D0154C502@redivi.com> Message-ID: <1179707.1151522798812.JavaMail.jordan.breeding@mac.com> Okay, I am attaching a copy of the current script. Usernames, passwords, and email addresses have been replaced with "****". This code might be a little rough, probably looks like c++ instead of pure python, etc. But it does work except for that I get those errors from time to time. I seem to get the errors regardless of whether I call python or pythonw. I am using the latest appscript (appscript installer 1.3.2) and Universal Python 2.4.3. Thanks for any help tracking down why these errors/warnings occur. Jordan On Wednesday, June 28, 2006, at 02:01PM, Bob Ippolito wrote: >pythonw is and always has been a stub that launches a regular python >interpreter. There is nothing special about it except for the path >the regular interpreter is located at. The only thing it can do is >enable WindowServer access; it shouldn't ever cause any issues >(especially of this sort). In other words, it is absolutely not your >problem. > >The script isn't attached. I doubt anyone will be able to help you on >this without source code. You are correct about the message's >meaning, but without source the cause can't be determined. > >-bob > >On Jun 28, 2006, at 11:44 AM, Jordan Breeding wrote: > >> Hello, >> >> Do you think that the Python 2.4.3 Universal build could be having >> this effect with python and pythonw now combined? I don't see >> these messages all of the time but when I do it is a block of about >> 10 or so of them, and I usually only get the messages once per run >> of a script even when they do show up. I tried googling around and >> it seems like this message means something was marked autorelease >> in Cocoa somewhere but without a pool in place. Please let me know >> if you think you know what is going on but need more information. >> The problem might also be present in the 2.5b1 Universal, don't >> know yet because I don't have an appscript module for python built >> yet that will work with 2.5b1. >> >> Thanks, >> Jordan >> >> From: has >> To: Jordan Breeding >> Date: Wed Jun 28, 2006 11:31:03 AM CDT >> Subject: Re: python appscript is displaying warning/errors sometimes >> >> Hi, >> >>> I am using appscript in python to do some various tasks in iTunes. >>> The scripts are organized by task. One of the scripts makes some >>> zip files based on a playlist and then sends them. The problem I >>> have is that while the script does compete all of its takes I get >>> this set of messages sometimes: >>> >>> 2006-06-21 09:23:26.019 Python[21992] *** _NSAutoreleaseNoPool(): >>> Object 0x6fa480 of class NSCFString autoreleased with no pool in >>> place - just leaking >>> ... >>> >>> I am attaching a copy of the script with servernames, usernames, >>> and passwords blanked out. I know it probably isn't the greatest >>> code in the world but it seems to get the job done and I was just >>> wondering if you could easily spot the place that is leaking. >> >> Hmm, dunno; not very good on that stuff. If I had to guess, I'd say >> check the interpreter; I think it was rewritten recently to eliminate >> the python/pythonw dichotomy. I don't think any of the modules in >> your script are using Cocoa/CoreFoundation. Sorry I can't be more >> helpful. >> >> Regards, >> >> has >> >> >> _______________________________________________ >> 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: archive_and_send.py Type: application/octet-stream Size: 15193 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060628/d6488f5c/attachment-0001.obj From ronaldoussoren at mac.com Wed Jun 28 21:54:08 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 28 Jun 2006 21:54:08 +0200 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <44A2CF7D.9020604@hotmail.com> References: <44A2CF7D.9020604@hotmail.com> Message-ID: <3090938A-329E-4C6C-89ED-CADD9855F37B@mac.com> On 28-jun-2006, at 20:50, Michael Glassford wrote: > Ronald Oussoren wrote: >> On 28-jun-2006, at 19:02, Michael Glassford wrote: >> >>> I've built a universal binary build of an application that runs >>> great on >>> the Tiger machines that I've tested it on (both PowerPC and >>> Intel). >>> However, when I try to run it on PowerPC 10.3.9 (which I've been >>> led to >>> believe should work from comments in the PyObjC svn log), I get >>> this error: >>> >>> """ >>> ImportError: Failure linking new module: /usr/lib/libbz2.1.0.dylib: >>> dyld: /Volumes/GoombahDisk/Goombah.app/Contents/MacOS/Goombah can't >>> open >>> library: /usr/lib/libbz2.1.0.dylib (No such file or directory, >>> errno = 2) >>> """ >>> >>> When I investigate, /usr/lib/libbz2.1.0.dylib is present on the >>> Tiger >>> machine I've checked but not on the Panther machine where I'm >>> having the >>> problem, so that makes sense. The application does in fact use the >>> bzip2 >>> library; the error happens on an "import bz2" statement. And Py2App >>> py2app is including bz2.so in >>> MyApp.app/Contents/Resources/Python/lib-dynload. But apparently >>> bz2.so >>> links to /usr/lib/libbz2.1.0.dylib. >>> >>> The question is, how do I get py2app to include the necessary >>> files to >>> eliminate this dependency? Or what else can I do? >> >> I just fixed this for Python 2.5. We'll have to include a staticly >> linked copy of libz22 in the installer, just like we're doing for >> bsddb. For 2.5 I'm doing the same with sqlite (new in 2.5) and zlib >> (2.5 uses functionality that isn't present in the Panther version of >> zlib). > > Any pointers on how I could hack something like this in? Unless... Download bz2 and install the library "somewhere", download the python2.4 sources and extract the sources for the bz2 module. Then write a setup.py that builds the bz2 extension and use that to replace the one that's on your system. Don't forget to add '-Wl,- search_paths_first' to the extra_link_args, otherwise ld will prefer dylibs over static libraries and will hence pick up the system bz2 no matter what. > >> Its getting more and more clear that I can't get way with not >> updating the 2.4 installer :-(. > > Would you be thinking of doing this soon? :) Not this week, I've spent way too much time on an annoying problem in the x86 port of PyObjC and want to do some python hacking for change. I'll be happy if I manage to test a backport of the universal python changes to the official python 2.4 tree and check that in this week, and even that will probably have to wait. Ronald > > > Mike > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Wed Jun 28 22:00:59 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 28 Jun 2006 22:00:59 +0200 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> Message-ID: <1E1E9D7C-1FD4-4A4E-BAE5-397F0648E735@mac.com> On 28-jun-2006, at 20:56, Bob Ippolito wrote: > > > It's not really trivial, but it's the only option you have unless > someone else does it first. It sounds like Ronald will probably > create another 2.4.3 installer in the future that fixes this and a > few other issues, but I don't know when he'll get around to it (if > ever, I don't speak for his free time). I'm doing this in my free time, I'm hoping to do a new release before 2.4.4 gets out but don't promise anything. > > In your situation, I would just give up on 10.3 users until the issue > with Python is resolved (which is either going to happen when 2.5 > comes out, or when the 2.4.3 installer gets updated). And if you want support for 10.3 actually testing the 2.5 installer would be nice. I do some testing on 10.3, but as all my systems run 10.4 and I don't have a business-need for supporting 10.3 it doesn't get a much attention as it should. To do that you'll have to build it from source on a 10.4.x system with xcode 2.3 and the 10.4u SDK installed. Just run Mac/BuildScript/ build-installer.py to create a dmg containing the installer. Ronald From ronaldoussoren at mac.com Wed Jun 28 22:08:36 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 28 Jun 2006 22:08:36 +0200 Subject: [Pythonmac-SIG] Is anyone using IDLE? Message-ID: Hi, Are there any users of IDLE on OSX? I'm guessing the answer is no, as if just fixed a problem where opening the debugger window would completely hose IDLE (probably a TkAqua bug), but you never know :-). If there are people that are interested in IDLE on OSX I'd be very grateful if some of them would have a look at IDLE in 2.5b1 (or rather IDLE in the current trunk). There are two problems that need some loving: 1) Key-bindings don't work properly (CMD-Q works most of the time as does CMD-N, but CMD-W doesn't) 2) Several windows (such as the path browser) don't have a menu of their own and therefore revert to the default Wish/Tk menu Beta 2, and the final release of 2.5, or getting closer fast and I don't know if I'll have time to look at these issues, but IMHO both of these need to be fixed if we want to some kind of python IDE in the default python distribution (with the first issue being the most crusial). Ronald P.S. And don't start proposing other IDE's, that's a non-starter. From bob at redivi.com Wed Jun 28 22:23:18 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 28 Jun 2006 13:23:18 -0700 Subject: [Pythonmac-SIG] Fwd: Re: python appscript is displaying warning/errors sometimes In-Reply-To: <1179707.1151522798812.JavaMail.jordan.breeding@mac.com> References: <15961016.1151520269041.JavaMail.jordan.breeding@mac.com> <3CDEC8AB-3764-4597-BDA4-016D0154C502@redivi.com> <1179707.1151522798812.JavaMail.jordan.breeding@mac.com> Message-ID: <7FDAADE1-F64C-4A36-A42B-FE0841F0ACA1@redivi.com> I don't see anything in this script that could directly cause those warnings. It's got to be something in appscript calls into... If you run it under GDB with a breakpoint on _NSAutoreleaseNoPool you might be able to track it down. If you could reproduce the issue in such a way that it was easy to reproduce then someone else would probably look at it, but in its current state I don't think this script is going to work very well on anyone else's machine. CoreFoundation doesn't have autorelease pools and could never trigger this message on its own. There *must* be some Foundation-based Objective-C code involved somewhere along the way. No such code is in Python, but it's possible that there is some such dependency in something appscript is using. -bob On Jun 28, 2006, at 12:26 PM, Jordan Breeding wrote: > Okay, I am attaching a copy of the current script. Usernames, > passwords, and email addresses have been replaced with "****". > This code might be a little rough, probably looks like c++ instead > of pure python, etc. But it does work except for that I get those > errors from time to time. I seem to get the errors regardless of > whether I call python or pythonw. I am using the latest appscript > (appscript installer 1.3.2) and Universal Python 2.4.3. Thanks for > any help tracking down why these errors/warnings occur. > > Jordan > > On Wednesday, June 28, 2006, at 02:01PM, Bob Ippolito > wrote: > >> pythonw is and always has been a stub that launches a regular python >> interpreter. There is nothing special about it except for the path >> the regular interpreter is located at. The only thing it can do is >> enable WindowServer access; it shouldn't ever cause any issues >> (especially of this sort). In other words, it is absolutely not your >> problem. >> >> The script isn't attached. I doubt anyone will be able to help you on >> this without source code. You are correct about the message's >> meaning, but without source the cause can't be determined. >> >> -bob >> >> On Jun 28, 2006, at 11:44 AM, Jordan Breeding wrote: >> >>> Hello, >>> >>> Do you think that the Python 2.4.3 Universal build could be having >>> this effect with python and pythonw now combined? I don't see >>> these messages all of the time but when I do it is a block of about >>> 10 or so of them, and I usually only get the messages once per run >>> of a script even when they do show up. I tried googling around and >>> it seems like this message means something was marked autorelease >>> in Cocoa somewhere but without a pool in place. Please let me know >>> if you think you know what is going on but need more information. >>> The problem might also be present in the 2.5b1 Universal, don't >>> know yet because I don't have an appscript module for python built >>> yet that will work with 2.5b1. >>> >>> Thanks, >>> Jordan >>> >>> From: has >>> To: Jordan Breeding >>> Date: Wed Jun 28, 2006 11:31:03 AM CDT >>> Subject: Re: python appscript is displaying warning/errors sometimes >>> >>> Hi, >>> >>>> I am using appscript in python to do some various tasks in iTunes. >>>> The scripts are organized by task. One of the scripts makes some >>>> zip files based on a playlist and then sends them. The problem I >>>> have is that while the script does compete all of its takes I get >>>> this set of messages sometimes: >>>> >>>> 2006-06-21 09:23:26.019 Python[21992] *** _NSAutoreleaseNoPool(): >>>> Object 0x6fa480 of class NSCFString autoreleased with no pool in >>>> place - just leaking >>>> ... >>>> >>>> I am attaching a copy of the script with servernames, usernames, >>>> and passwords blanked out. I know it probably isn't the greatest >>>> code in the world but it seems to get the job done and I was just >>>> wondering if you could easily spot the place that is leaking. >>> >>> Hmm, dunno; not very good on that stuff. If I had to guess, I'd say >>> check the interpreter; I think it was rewritten recently to >>> eliminate >>> the python/pythonw dichotomy. I don't think any of the modules in >>> your script are using Cocoa/CoreFoundation. Sorry I can't be more >>> helpful. >>> >>> Regards, >>> >>> has >>> >>> >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >> >> >> >> From glassfordm at hotmail.com Wed Jun 28 23:22:10 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Wed, 28 Jun 2006 17:22:10 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> Message-ID: Bob Ippolito wrote: > In your situation, I would just give up on 10.3 users until the issue > with Python is resolved (which is either going to happen when 2.5 > comes out, or when the 2.4.3 installer gets updated). OK, thanks for the help. I guess this is the solution we'll go with for now (actually, we'll stick with a PowerPC build for Panther users and a universal binary build for Tiger users). Mike From glassfordm at hotmail.com Wed Jun 28 23:23:13 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Wed, 28 Jun 2006 17:23:13 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <3090938A-329E-4C6C-89ED-CADD9855F37B@mac.com> References: <44A2CF7D.9020604@hotmail.com> <3090938A-329E-4C6C-89ED-CADD9855F37B@mac.com> Message-ID: Ronald Oussoren wrote: > On 28-jun-2006, at 20:50, Michael Glassford wrote: > >> Ronald Oussoren wrote: >>> Its getting more and more clear that I can't get way with not >>> updating the 2.4 installer :-(. >> Would you be thinking of doing this soon? :) > > Not this week, I've spent way too much time on an annoying problem in > the x86 port of PyObjC and want to do some python hacking for change. > I'll be happy if I manage to test a backport of the universal python > changes to the official python 2.4 tree and check that in this week, > and even that will probably have to wait. As I indicated in my reply to Bob, we'll stick with a non-universal binary build for Panther users and a universal binary build for Tiger users for now. Thanks for the help. Mike From jordan.breeding at mac.com Thu Jun 29 02:42:02 2006 From: jordan.breeding at mac.com (Jordan Breeding) Date: Wed, 28 Jun 2006 19:42:02 -0500 Subject: [Pythonmac-SIG] Fwd: Re: python appscript is displaying warning/errors sometimes In-Reply-To: <7FDAADE1-F64C-4A36-A42B-FE0841F0ACA1@redivi.com> References: <15961016.1151520269041.JavaMail.jordan.breeding@mac.com> <3CDEC8AB-3764-4597-BDA4-016D0154C502@redivi.com> <1179707.1151522798812.JavaMail.jordan.breeding@mac.com> <7FDAADE1-F64C-4A36-A42B-FE0841F0ACA1@redivi.com> Message-ID: <314206C3-E378-4966-9465-1C22C9ECBCBC@mac.com> Okay, so this is going to be a bit long, I didn't know if you would want the short stack trace or the full stack trace so I will just put the full one. To reproduce the problem I ran my script with a certain track list, the program completed and never triggered the breakpoint. Then I cleared all of the transfered files, reset everything on the iTunes side and started it again. It got to generating the end of the first file, and right before starting to generate the second zip file the breakpoint triggered, here is the backtrace: Breakpoint 1, 0x92a0abac in _NSAutoreleaseNoPool () (gdb) bt full #0 0x92a0abac in _NSAutoreleaseNoPool () No symbol table info available. #1 0x9291c4c0 in -[NSObject autorelease] () No symbol table info available. #2 0x9292fedc in _NSSoftLinkingLoadFrameworkImage () No symbol table info available. #3 0x9292fe44 in _NSSoftLinkingGetFrameworkFuncPtr () No symbol table info available. #4 0x9292fda4 in _NS_AEInstallEventHandler () No symbol table info available. #5 0x9292fad0 in -[NSAppleEventManager setEventHandler:andSelector:forEventClass:andEventID:] () No symbol table info available. #6 0x059be320 in DFPatch::Initialize () No symbol table info available. #7 0x059c9c30 in SCPatchInit () No symbol table info available. #8 0x0141455c in SCLoadPatchBundle () No symbol table info available. #9 0x01415438 in BundleLoader::ReceiveMessage () No symbol table info available. #10 0x0141512c in SCPatchMessenger::ReceiveCallback () No symbol table info available. #11 0x90823104 in __CFMessagePortPerform () No symbol table info available. #12 0x907e9734 in __CFRunLoopDoSource1 () No symbol table info available. #13 0x907dbe4c in __CFRunLoopRun () No symbol table info available. #14 0x907db47c in CFRunLoopRunSpecific () No symbol table info available. #15 0x931e6740 in RunCurrentEventLoopInMode () No symbol table info available. #16 0x932cae5c in GetNextEventMatchingMask () No symbol table info available. #17 0x932cac10 in WNEInternal () No symbol table info available. #18 0x933e3080 in _AEWNE () No symbol table info available. #19 0x914fc584 in aeSend () No symbol table info available. #20 0x9329438c in AESend () No symbol table info available. #21 0x0100ace0 in AEDesc_AESend (_self=0x5b88ae8, _args=0x5b6ee18) at src/_AEmodule.c:635 _save = (PyThreadState *) 0x600230 _res = (PyObject *) 0x0 _err = 103 reply = { descriptorType = 1634039412, dataHandle = 0x67ed94 } sendMode = 3 sendPriority = 0 timeOutInTicks = -1 #22 0x0028b7fc in PyEval_EvalFrame (f=0x606ab0) at /Volumes/Data/ Users/ronald/Universal/python24-fat/Python/ceval.c:3563 callargs = (PyObject *) 0x5b6ee18 tstate = (PyThreadState *) 0x600230 pfunc = (PyObject **) 0x606c10 w = (PyObject *) 0x6cfe80 sp = (PyObject **) 0x606c14 stack_pointer = (PyObject **) 0x3 next_instr = (unsigned char *) 0x9291c4c0 "\200\001" opcode = 6292016 oparg = 6319120 why = WHY_NOT err = 0 x = (PyObject *) 0x3 v = (PyObject *) 0x5b06d28 w = (PyObject *) 0x600230 u = (PyObject *) 0x6cfe80 t = (PyObject *) 0x600230 stream = (PyObject *) 0x5b06d28 fastlocals = (PyObject **) 0x606bfc freevars = (PyObject **) 0x606c10 retval = (PyObject *) 0x0 tstate = (PyThreadState *) 0x600230 co = (PyCodeObject *) 0xddb20 instr_ub = -1 instr_lb = 0 instr_prev = -1 first_instr = (unsigned char *) 0x67e44 "t" names = (PyObject *) 0xdc260 consts = (PyObject *) 0xdb1b8 #23 0x0028b984 in PyEval_EvalFrame (f=0x613b00) at /Volumes/Data/ Users/ronald/Universal/python24-fat/Python/ceval.c:3645 f = (PyFrameObject *) 0x606ab0 tstate = (PyThreadState *) 0x600230 fastlocals = (PyObject **) 0x9291c4c0 stack = (PyObject **) 0xa291b704 co = (PyCodeObject *) 0x6cfe80 nd = -1835940672 globals = (PyObject *) 0x68 argdefs = (PyObject *) 0x90a3c628 d = (PyObject **) 0x90a3c628 n = 2 pfunc = (PyObject **) 0x613c60 w = (PyObject *) 0x6cfe80 sp = (PyObject **) 0x613c6c stack_pointer = (PyObject **) 0x2 next_instr = (unsigned char *) 0x9291c4c0 "\200\001" opcode = 6292016 oparg = 6372448 why = WHY_NOT err = 0 x = (PyObject *) 0x2 v = (PyObject *) 0x594830 w = (PyObject *) 0x600230 u = (PyObject *) 0x6cfe80 t = (PyObject *) 0x600230 stream = (PyObject *) 0x594830 fastlocals = (PyObject **) 0x613c4c freevars = (PyObject **) 0x613c60 retval = (PyObject *) 0x0 tstate = (PyThreadState *) 0x600230 co = (PyCodeObject *) 0x591ee0 instr_ub = -1 instr_lb = 0 instr_prev = -1 first_instr = (unsigned char *) 0x631f54 "t" names = (PyObject *) 0xade40 consts = (PyObject *) 0xddab0 #24 0x0028b984 in PyEval_EvalFrame (f=0x614ba0) at /Volumes/Data/ Users/ronald/Universal/python24-fat/Python/ceval.c:3645 f = (PyFrameObject *) 0x613b00 tstate = (PyThreadState *) 0x600230 fastlocals = (PyObject **) 0x9291c4c0 stack = (PyObject **) 0xa291b704 co = (PyCodeObject *) 0x6cfe80 nd = -1835940672 globals = (PyObject *) 0x68 argdefs = (PyObject *) 0x90a3c628 d = (PyObject **) 0x90a3c628 n = 1 pfunc = (PyObject **) 0x614d00 w = (PyObject *) 0x6cfe80 sp = (PyObject **) 0x614d08 stack_pointer = (PyObject **) 0x1 next_instr = (unsigned char *) 0x9291c4c0 "\200\001" opcode = 6292016 oparg = 6376704 why = WHY_NOT err = 0 x = (PyObject *) 0x1 v = (PyObject *) 0x5947b0 w = (PyObject *) 0x600230 u = (PyObject *) 0x6cfe80 t = (PyObject *) 0x600230 stream = (PyObject *) 0x5947b0 fastlocals = (PyObject **) 0x614cec freevars = (PyObject **) 0x614d00 retval = (PyObject *) 0x0 tstate = (PyThreadState *) 0x600230 co = (PyCodeObject *) 0xd9460 instr_ub = -1 instr_lb = 0 instr_prev = -1 first_instr = (unsigned char *) 0xbc9b4 "|\004" names = (PyObject *) 0xa9c48 consts = (PyObject *) 0xd7c88 #25 0x0028da5c in PyEval_EvalCodeEx (co=0xd9460, globals=0xa293ab98, locals=0x9291c4c0, args=0x614d00, argcount=3, kws=0x1, kwcount=1, defs=0xda3cc, defcount=4, closure=0x0) at /Volumes/Data/Users/ronald/ Universal/python24-fat/Python/ceval.c:2736 f = (PyFrameObject *) 0x614ba0 retval = (PyObject *) 0xda3dc fastlocals = (PyObject **) 0x614cec freevars = (PyObject **) 0x614d00 tstate = (PyThreadState *) 0x600230 x = (PyObject *) 0x6661f0 u = (PyObject *) 0xda3dc defcount = 4 closure = (PyObject *) 0x0 #26 0x0022bf40 in function_call (func=0x596170, arg=0x5b760d0, kw=0x1) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ funcobject.c:548 result = (PyObject *) 0xd9460 argdefs = (PyObject *) 0xd9460 d = (PyObject **) 0xda3cc k = (PyObject **) 0x696280 nk = 1 nd = 4 #27 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ abstract.c:1795 result = (PyObject *) 0x5b760d0 call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> #28 0x00217324 in instancemethod_call (func=0x6cfe80, arg=0x5b760d0, kw=0x5b8f150) at /Volumes/Data/Users/ronald/Universal/python24-fat/ Objects/classobject.c:2447 self = (PyObject *) 0x5b6eee0 class = (PyObject *) 0x2 result = (PyObject *) 0x5b6eee0 #29 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ abstract.c:1795 result = (PyObject *) 0x104abc0 call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> #30 0x00286578 in PyEval_CallObjectWithKeywords (func=0xaf710, arg=0x104abc0, kw=0x5b8f150) at /Volumes/Data/Users/ronald/Universal/ python24-fat/Python/ceval.c:3430 result = (PyObject *) 0x5b8f150 #31 0x00219b88 in PyInstance_New (klass=0x6cfe80, arg=0x104abc0, kw=0x5b8f150) at /Volumes/Data/Users/ronald/Universal/python24-fat/ Objects/classobject.c:575 res = (PyObject *) 0xaf710 inst = (PyInstanceObject *) 0x5b6eee0 init = (PyObject *) 0xaf710 initstr = (PyObject *) 0x5680 #32 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ abstract.c:1795 result = (PyObject *) 0x104abc0 call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> #33 0x0028ba98 in PyEval_EvalFrame (f=0x180be10) at /Volumes/Data/ Users/ronald/Universal/python24-fat/Python/ceval.c:3771 callargs = (PyObject *) 0x104abc0 kwdict = (PyObject *) 0x5b8f150 nk = 96006480 func = (PyObject *) 0x1042060 pfunc = (PyObject **) 0x180bf88 w = (PyObject *) 0x6cfe80 sp = (PyObject **) 0x180bf8c stack_pointer = (PyObject **) 0x2 next_instr = (unsigned char *) 0x9291c4c0 "\200\001" opcode = 96006480 oparg = 25214856 why = WHY_NOT err = 0 x = (PyObject *) 0x2 v = (PyObject *) 0x1042060 w = (PyObject *) 0x5b8f150 u = (PyObject *) 0x6cfe80 t = (PyObject *) 0x5b8f150 stream = (PyObject *) 0x1042060 fastlocals = (PyObject **) 0x180bf5c freevars = (PyObject **) 0x180bf88 retval = (PyObject *) 0x0 tstate = (PyThreadState *) 0x600230 co = (PyCodeObject *) 0xc5ae0 instr_ub = -1 instr_lb = 0 instr_prev = -1 first_instr = (unsigned char *) 0x623394 "t" names = (PyObject *) 0xdb58 consts = (PyObject *) 0xc65a0 #34 0x0028da5c in PyEval_EvalCodeEx (co=0xc5ae0, globals=0xa293ab98, locals=0x9291c4c0, args=0x180bf74, argcount=2, kws=0x0, kwcount=0, defs=0x105a6fc, defcount=5, closure=0x0) at /Volumes/Data/Users/ ronald/Universal/python24-fat/Python/ceval.c:2736 f = (PyFrameObject *) 0x180be10 retval = (PyObject *) 0x105a710 fastlocals = (PyObject **) 0x180bf5c freevars = (PyObject **) 0x180bf88 tstate = (PyThreadState *) 0x600230 x = (PyObject *) 0x6661f0 u = (PyObject *) 0x105a710 defcount = 5 closure = (PyObject *) 0x0 #35 0x0022bf40 in function_call (func=0x105f8b0, arg=0x5b06cd8, kw=0x0) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ funcobject.c:548 result = (PyObject *) 0xc5ae0 argdefs = (PyObject *) 0xc5ae0 d = (PyObject **) 0x105a6fc k = (PyObject **) 0x0 nk = 0 nd = 5 #36 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ abstract.c:1795 result = (PyObject *) 0x5b06cd8 call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> #37 0x00217324 in instancemethod_call (func=0x6cfe80, arg=0x5b06cd8, kw=0x0) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ classobject.c:2447 self = (PyObject *) 0x5b095d0 class = (PyObject *) 0x1 result = (PyObject *) 0x5b095d0 #38 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ abstract.c:1795 result = (PyObject *) 0xaf6e8 call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> #39 0x00259730 in slot_tp_init (self=0x6cfe80, args=0x5b095b0, kwds=0x0) at /Volumes/Data/Users/ronald/Universal/python24-fat/ Objects/typeobject.c:4759 init_str = (PyObject *) 0x5680 meth = (PyObject *) 0xaf6e8 res = (PyObject *) 0x5b095b0 #40 0x0025c428 in type_call (type=0x63f9b0, args=0x5b095b0, kwds=0x0) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ typeobject.c:435 obj = (PyObject *) 0x5b095d0 #41 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/Objects/ abstract.c:1795 result = (PyObject *) 0x5b095b0 call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> #42 0x0028ba98 in PyEval_EvalFrame (f=0x6c8f20) at /Volumes/Data/ Users/ronald/Universal/python24-fat/Python/ceval.c:3771 callargs = (PyObject *) 0x5b095b0 kwdict = (PyObject *) 0x0 nk = 0 func = (PyObject *) 0x63f9b0 pfunc = (PyObject **) 0x6c9074 w = (PyObject *) 0x6cfe80 sp = (PyObject **) 0x6c9078 stack_pointer = (PyObject **) 0x1 next_instr = (unsigned char *) 0x9291c4c0 "\200\001" opcode = 0 oparg = 7114868 why = WHY_NOT err = 0 x = (PyObject *) 0x1 v = (PyObject *) 0x63f9b0 w = (PyObject *) 0x0 u = (PyObject *) 0x6cfe80 t = (PyObject *) 0x0 stream = (PyObject *) 0x63f9b0 fastlocals = (PyObject **) 0x6c906c freevars = (PyObject **) 0x6c9074 retval = (PyObject *) 0x0 tstate = (PyThreadState *) 0x600230 co = (PyCodeObject *) 0xe1b20 instr_ub = -1 instr_lb = 0 instr_prev = -1 first_instr = (unsigned char *) 0x4b544 "t" names = (PyObject *) 0x50ea0 consts = (PyObject *) 0xe1af0 #43 0x0028b984 in PyEval_EvalFrame (f=0x608800) at /Volumes/Data/ Users/ronald/Universal/python24-fat/Python/ceval.c:3645 f = (PyFrameObject *) 0x6c8f20 tstate = (PyThreadState *) 0x600230 fastlocals = (PyObject **) 0x9291c4c0 stack = (PyObject **) 0xa291b704 co = (PyCodeObject *) 0x6cfe80 nd = -1835940672 globals = (PyObject *) 0x68 argdefs = (PyObject *) 0x90a3c628 d = (PyObject **) 0x90a3c628 n = 2 pfunc = (PyObject **) 0x608950 w = (PyObject *) 0x6cfe80 sp = (PyObject **) 0x60895c stack_pointer = (PyObject **) 0x2 next_instr = (unsigned char *) 0x9291c4c0 "\200\001" opcode = 6292016 oparg = 6326608 why = WHY_NOT err = 0 x = (PyObject *) 0x2 v = (PyObject *) 0x105fb70 w = (PyObject *) 0x600230 u = (PyObject *) 0x6cfe80 t = (PyObject *) 0x600230 stream = (PyObject *) 0x105fb70 fastlocals = (PyObject **) 0x60894c freevars = (PyObject **) 0x60894c retval = (PyObject *) 0x0 tstate = (PyThreadState *) 0x600230 co = (PyCodeObject *) 0xe1da0 instr_ub = -1 instr_lb = 0 instr_prev = -1 first_instr = (unsigned char *) 0x184c414 "d" names = (PyObject *) 0x1840610 consts = (PyObject *) 0x60ad60 #44 0x0028da5c in PyEval_EvalCodeEx (co=0xe1da0, globals=0xa293ab98, locals=0x9291c4c0, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at /Volumes/Data/Users/ronald/ Universal/python24-fat/Python/ceval.c:2736 f = (PyFrameObject *) 0x608800 retval = (PyObject *) 0x0 fastlocals = (PyObject **) 0x60894c freevars = (PyObject **) 0x60894c tstate = (PyThreadState *) 0x600230 x = (PyObject *) 0x6661f0 u = (PyObject *) 0x0 defcount = 0 closure = (PyObject *) 0x0 #45 0x0028dbe4 in PyEval_EvalCode (co=0x6cfe80, globals=0xa293ab98, locals=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/ Python/ceval.c:484 No locals. #46 0x002b5ba8 in PyRun_FileExFlags (fp=0xa000db44, filename=0xbffff809 "/Users/jordan/ruby_testing/ archive_and_send_appscript_alternate_local.py", start=-1602514356, globals=0x1fa50, locals=0x1fa50, closeit=1, flags=0xe1da0) at / Volumes/Data/Users/ronald/Universal/python24-fat/Python/pythonrun.c:1265 co = (PyCodeObject *) 0xe1da0 v = (PyObject *) 0xe230 n = (node *) 0xe230 #47 0x002b5dbc in PyRun_SimpleFileExFlags (fp=0xa000db44, filename=0xbffff809 "/Users/jordan/ruby_testing/ archive_and_send_appscript_alternate_local.py", closeit=1, flags=0xbffff54c) at /Volumes/Data/Users/ronald/Universal/python24- fat/Python/pythonrun.c:860 d = (PyObject *) 0x1fa50 v = (PyObject *) 0x0 ext = 0xbffff84d "l.py" #48 0x002c0bfc in Py_Main (argc=-2147483648, argv=0xbffff6b0) at / Volumes/Data/Users/ronald/Universal/python24-fat/Modules/main.c:501 c = 7143040 sts = -1610605668 command = 0x0 filename = 0xa293ab98 "\220?\200\b\220?H\224\220?\\\210\220? \222?\220??" module = 0x0 fp = (FILE *) 0xa000db44 p = 0x6cfe80 "?{\226t" inspect = 0 unbuffered = 3211608 skipfirstline = 0 stdin_is_interactive = 1 help = -1073743863 version = 1 saw_inspect_flag = 536870912 saw_unbuffered_flag = -1073744564 cf = { cf_flags = 0 } #49 0x0000257c in _call_objcInit () at /SourceCache/Csu/Csu-58/crt.c:361 i = 3221223100 count = 3221223088 _dyld_image_count_fn = (unsigned int (*)()) 0x8fe07364 <__dyld__Z20_dyld_mod_term_funcsv> _dyld_get_image_name_fn = (const char *(*)()) 0 _dyld_get_image_header_fn = (const void *(*)()) 0 NSLookupSymbolInImage_fn = (const void *(*)()) 0 NSAddressOfSymbol_fn = (void *(*)()) 0xbffff6a8 #50 0x00002424 in _start (argc=2, argv=0xbffff6b0, envp=0xbffff6bc) at /SourceCache/Csu/Csu-58/crt.c:205 p = 0xa291b704 "\220" q = (char **) 0xffffffff term = (void (*)()) 0 (gdb) On Jun 28, 2006, at 15:23 , Bob Ippolito wrote: > I don't see anything in this script that could directly cause those > warnings. It's got to be something in appscript calls into... > > If you run it under GDB with a breakpoint on _NSAutoreleaseNoPool > you might be able to track it down. If you could reproduce the > issue in such a way that it was easy to reproduce then someone else > would probably look at it, but in its current state I don't think > this script is going to work very well on anyone else's machine. > > CoreFoundation doesn't have autorelease pools and could never > trigger this message on its own. There *must* be some Foundation- > based Objective-C code involved somewhere along the way. No such > code is in Python, but it's possible that there is some such > dependency in something appscript is using. > > -bob > > On Jun 28, 2006, at 12:26 PM, Jordan Breeding wrote: > >> Okay, I am attaching a copy of the current script. Usernames, >> passwords, and email addresses have been replaced with "****". >> This code might be a little rough, probably looks like c++ instead >> of pure python, etc. But it does work except for that I get those >> errors from time to time. I seem to get the errors regardless of >> whether I call python or pythonw. I am using the latest appscript >> (appscript installer 1.3.2) and Universal Python 2.4.3. Thanks >> for any help tracking down why these errors/warnings occur. >> >> Jordan >> >> On Wednesday, June 28, 2006, at 02:01PM, Bob Ippolito >> wrote: >> >>> pythonw is and always has been a stub that launches a regular python >>> interpreter. There is nothing special about it except for the path >>> the regular interpreter is located at. The only thing it can do is >>> enable WindowServer access; it shouldn't ever cause any issues >>> (especially of this sort). In other words, it is absolutely not your >>> problem. >>> >>> The script isn't attached. I doubt anyone will be able to help >>> you on >>> this without source code. You are correct about the message's >>> meaning, but without source the cause can't be determined. >>> >>> -bob >>> >>> On Jun 28, 2006, at 11:44 AM, Jordan Breeding wrote: >>> >>>> Hello, >>>> >>>> Do you think that the Python 2.4.3 Universal build could be having >>>> this effect with python and pythonw now combined? I don't see >>>> these messages all of the time but when I do it is a block of about >>>> 10 or so of them, and I usually only get the messages once per run >>>> of a script even when they do show up. I tried googling around and >>>> it seems like this message means something was marked autorelease >>>> in Cocoa somewhere but without a pool in place. Please let me know >>>> if you think you know what is going on but need more information. >>>> The problem might also be present in the 2.5b1 Universal, don't >>>> know yet because I don't have an appscript module for python built >>>> yet that will work with 2.5b1. >>>> >>>> Thanks, >>>> Jordan >>>> >>>> From: has >>>> To: Jordan Breeding >>>> Date: Wed Jun 28, 2006 11:31:03 AM CDT >>>> Subject: Re: python appscript is displaying warning/errors >>>> sometimes >>>> >>>> Hi, >>>> >>>>> I am using appscript in python to do some various tasks in iTunes. >>>>> The scripts are organized by task. One of the scripts makes some >>>>> zip files based on a playlist and then sends them. The problem I >>>>> have is that while the script does compete all of its takes I get >>>>> this set of messages sometimes: >>>>> >>>>> 2006-06-21 09:23:26.019 Python[21992] *** _NSAutoreleaseNoPool(): >>>>> Object 0x6fa480 of class NSCFString autoreleased with no pool in >>>>> place - just leaking >>>>> ... >>>>> >>>>> I am attaching a copy of the script with servernames, usernames, >>>>> and passwords blanked out. I know it probably isn't the greatest >>>>> code in the world but it seems to get the job done and I was just >>>>> wondering if you could easily spot the place that is leaking. >>>> >>>> Hmm, dunno; not very good on that stuff. If I had to guess, I'd say >>>> check the interpreter; I think it was rewritten recently to >>>> eliminate >>>> the python/pythonw dichotomy. I don't think any of the modules in >>>> your script are using Cocoa/CoreFoundation. Sorry I can't be more >>>> helpful. >>>> >>>> Regards, >>>> >>>> has >>>> >>>> >>>> _______________________________________________ >>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >>> >>> >>> > From bob at redivi.com Thu Jun 29 02:47:34 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 28 Jun 2006 17:47:34 -0700 Subject: [Pythonmac-SIG] Fwd: Re: python appscript is displaying warning/errors sometimes In-Reply-To: <314206C3-E378-4966-9465-1C22C9ECBCBC@mac.com> References: <15961016.1151520269041.JavaMail.jordan.breeding@mac.com> <3CDEC8AB-3764-4597-BDA4-016D0154C502@redivi.com> <1179707.1151522798812.JavaMail.jordan.breeding@mac.com> <7FDAADE1-F64C-4A36-A42B-FE0841F0ACA1@redivi.com> <314206C3-E378-4966-9465-1C22C9ECBCBC@mac.com> Message-ID: You have some kind of haxie-like-thing (an InputManager maybe) installed. That haxie is broken and causing those messages. Nothing to see here, not a bug in appscript or Python. -bob On Jun 28, 2006, at 5:42 PM, Jordan Breeding wrote: > Okay, so this is going to be a bit long, I didn't know if you would > want the short stack trace or the full stack trace so I will just > put the full one. To reproduce the problem I ran my script with a > certain track list, the program completed and never triggered the > breakpoint. Then I cleared all of the transfered files, reset > everything on the iTunes side and started it again. It got to > generating the end of the first file, and right before starting to > generate the second zip file the breakpoint triggered, here is the > backtrace: > > Breakpoint 1, 0x92a0abac in _NSAutoreleaseNoPool () > (gdb) bt full > #0 0x92a0abac in _NSAutoreleaseNoPool () > No symbol table info available. > #1 0x9291c4c0 in -[NSObject autorelease] () > No symbol table info available. > #2 0x9292fedc in _NSSoftLinkingLoadFrameworkImage () > No symbol table info available. > #3 0x9292fe44 in _NSSoftLinkingGetFrameworkFuncPtr () > No symbol table info available. > #4 0x9292fda4 in _NS_AEInstallEventHandler () > No symbol table info available. > #5 0x9292fad0 in -[NSAppleEventManager > setEventHandler:andSelector:forEventClass:andEventID:] () > No symbol table info available. > #6 0x059be320 in DFPatch::Initialize () > No symbol table info available. > #7 0x059c9c30 in SCPatchInit () > No symbol table info available. > #8 0x0141455c in SCLoadPatchBundle () > No symbol table info available. > #9 0x01415438 in BundleLoader::ReceiveMessage () > No symbol table info available. > #10 0x0141512c in SCPatchMessenger::ReceiveCallback () > No symbol table info available. > #11 0x90823104 in __CFMessagePortPerform () > No symbol table info available. > #12 0x907e9734 in __CFRunLoopDoSource1 () > No symbol table info available. > #13 0x907dbe4c in __CFRunLoopRun () > No symbol table info available. > #14 0x907db47c in CFRunLoopRunSpecific () > No symbol table info available. > #15 0x931e6740 in RunCurrentEventLoopInMode () > No symbol table info available. > #16 0x932cae5c in GetNextEventMatchingMask () > No symbol table info available. > #17 0x932cac10 in WNEInternal () > No symbol table info available. > #18 0x933e3080 in _AEWNE () > No symbol table info available. > #19 0x914fc584 in aeSend () > No symbol table info available. > #20 0x9329438c in AESend () > No symbol table info available. > #21 0x0100ace0 in AEDesc_AESend (_self=0x5b88ae8, _args=0x5b6ee18) > at src/_AEmodule.c:635 > _save = (PyThreadState *) 0x600230 > _res = (PyObject *) 0x0 > _err = 103 > reply = { > descriptorType = 1634039412, > dataHandle = 0x67ed94 > } > sendMode = 3 > sendPriority = 0 > timeOutInTicks = -1 > #22 0x0028b7fc in PyEval_EvalFrame (f=0x606ab0) at /Volumes/Data/ > Users/ronald/Universal/python24-fat/Python/ceval.c:3563 > callargs = (PyObject *) 0x5b6ee18 > tstate = (PyThreadState *) 0x600230 > pfunc = (PyObject **) 0x606c10 > w = (PyObject *) 0x6cfe80 > sp = (PyObject **) 0x606c14 > stack_pointer = (PyObject **) 0x3 > next_instr = (unsigned char *) 0x9291c4c0 "\200\001" > opcode = 6292016 > oparg = 6319120 > why = WHY_NOT > err = 0 > x = (PyObject *) 0x3 > v = (PyObject *) 0x5b06d28 > w = (PyObject *) 0x600230 > u = (PyObject *) 0x6cfe80 > t = (PyObject *) 0x600230 > stream = (PyObject *) 0x5b06d28 > fastlocals = (PyObject **) 0x606bfc > freevars = (PyObject **) 0x606c10 > retval = (PyObject *) 0x0 > tstate = (PyThreadState *) 0x600230 > co = (PyCodeObject *) 0xddb20 > instr_ub = -1 > instr_lb = 0 > instr_prev = -1 > first_instr = (unsigned char *) 0x67e44 "t" > names = (PyObject *) 0xdc260 > consts = (PyObject *) 0xdb1b8 > #23 0x0028b984 in PyEval_EvalFrame (f=0x613b00) at /Volumes/Data/ > Users/ronald/Universal/python24-fat/Python/ceval.c:3645 > f = (PyFrameObject *) 0x606ab0 > tstate = (PyThreadState *) 0x600230 > fastlocals = (PyObject **) 0x9291c4c0 > stack = (PyObject **) 0xa291b704 > co = (PyCodeObject *) 0x6cfe80 > nd = -1835940672 > globals = (PyObject *) 0x68 > argdefs = (PyObject *) 0x90a3c628 > d = (PyObject **) 0x90a3c628 > n = 2 > pfunc = (PyObject **) 0x613c60 > w = (PyObject *) 0x6cfe80 > sp = (PyObject **) 0x613c6c > stack_pointer = (PyObject **) 0x2 > next_instr = (unsigned char *) 0x9291c4c0 "\200\001" > opcode = 6292016 > oparg = 6372448 > why = WHY_NOT > err = 0 > x = (PyObject *) 0x2 > v = (PyObject *) 0x594830 > w = (PyObject *) 0x600230 > u = (PyObject *) 0x6cfe80 > t = (PyObject *) 0x600230 > stream = (PyObject *) 0x594830 > fastlocals = (PyObject **) 0x613c4c > freevars = (PyObject **) 0x613c60 > retval = (PyObject *) 0x0 > tstate = (PyThreadState *) 0x600230 > co = (PyCodeObject *) 0x591ee0 > instr_ub = -1 > instr_lb = 0 > instr_prev = -1 > first_instr = (unsigned char *) 0x631f54 "t" > names = (PyObject *) 0xade40 > consts = (PyObject *) 0xddab0 > #24 0x0028b984 in PyEval_EvalFrame (f=0x614ba0) at /Volumes/Data/ > Users/ronald/Universal/python24-fat/Python/ceval.c:3645 > f = (PyFrameObject *) 0x613b00 > tstate = (PyThreadState *) 0x600230 > fastlocals = (PyObject **) 0x9291c4c0 > stack = (PyObject **) 0xa291b704 > co = (PyCodeObject *) 0x6cfe80 > nd = -1835940672 > globals = (PyObject *) 0x68 > argdefs = (PyObject *) 0x90a3c628 > d = (PyObject **) 0x90a3c628 > n = 1 > pfunc = (PyObject **) 0x614d00 > w = (PyObject *) 0x6cfe80 > sp = (PyObject **) 0x614d08 > stack_pointer = (PyObject **) 0x1 > next_instr = (unsigned char *) 0x9291c4c0 "\200\001" > opcode = 6292016 > oparg = 6376704 > why = WHY_NOT > err = 0 > x = (PyObject *) 0x1 > v = (PyObject *) 0x5947b0 > w = (PyObject *) 0x600230 > u = (PyObject *) 0x6cfe80 > t = (PyObject *) 0x600230 > stream = (PyObject *) 0x5947b0 > fastlocals = (PyObject **) 0x614cec > freevars = (PyObject **) 0x614d00 > retval = (PyObject *) 0x0 > tstate = (PyThreadState *) 0x600230 > co = (PyCodeObject *) 0xd9460 > instr_ub = -1 > instr_lb = 0 > instr_prev = -1 > first_instr = (unsigned char *) 0xbc9b4 "|\004" > names = (PyObject *) 0xa9c48 > consts = (PyObject *) 0xd7c88 > #25 0x0028da5c in PyEval_EvalCodeEx (co=0xd9460, > globals=0xa293ab98, locals=0x9291c4c0, args=0x614d00, argcount=3, > kws=0x1, kwcount=1, defs=0xda3cc, defcount=4, closure=0x0) at / > Volumes/Data/Users/ronald/Universal/python24-fat/Python/ceval.c:2736 > f = (PyFrameObject *) 0x614ba0 > retval = (PyObject *) 0xda3dc > fastlocals = (PyObject **) 0x614cec > freevars = (PyObject **) 0x614d00 > tstate = (PyThreadState *) 0x600230 > x = (PyObject *) 0x6661f0 > u = (PyObject *) 0xda3dc > defcount = 4 > closure = (PyObject *) 0x0 > #26 0x0022bf40 in function_call (func=0x596170, arg=0x5b760d0, > kw=0x1) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/funcobject.c:548 > result = (PyObject *) 0xd9460 > argdefs = (PyObject *) 0xd9460 > d = (PyObject **) 0xda3cc > k = (PyObject **) 0x696280 > nk = 1 > nd = 4 > #27 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, > kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/abstract.c:1795 > result = (PyObject *) 0x5b760d0 > call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> > #28 0x00217324 in instancemethod_call (func=0x6cfe80, > arg=0x5b760d0, kw=0x5b8f150) at /Volumes/Data/Users/ronald/ > Universal/python24-fat/Objects/classobject.c:2447 > self = (PyObject *) 0x5b6eee0 > class = (PyObject *) 0x2 > result = (PyObject *) 0x5b6eee0 > #29 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, > kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/abstract.c:1795 > result = (PyObject *) 0x104abc0 > call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> > #30 0x00286578 in PyEval_CallObjectWithKeywords (func=0xaf710, > arg=0x104abc0, kw=0x5b8f150) at /Volumes/Data/Users/ronald/ > Universal/python24-fat/Python/ceval.c:3430 > result = (PyObject *) 0x5b8f150 > #31 0x00219b88 in PyInstance_New (klass=0x6cfe80, arg=0x104abc0, > kw=0x5b8f150) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/classobject.c:575 > res = (PyObject *) 0xaf710 > inst = (PyInstanceObject *) 0x5b6eee0 > init = (PyObject *) 0xaf710 > initstr = (PyObject *) 0x5680 > #32 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, > kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/abstract.c:1795 > result = (PyObject *) 0x104abc0 > call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> > #33 0x0028ba98 in PyEval_EvalFrame (f=0x180be10) at /Volumes/Data/ > Users/ronald/Universal/python24-fat/Python/ceval.c:3771 > callargs = (PyObject *) 0x104abc0 > kwdict = (PyObject *) 0x5b8f150 > nk = 96006480 > func = (PyObject *) 0x1042060 > pfunc = (PyObject **) 0x180bf88 > w = (PyObject *) 0x6cfe80 > sp = (PyObject **) 0x180bf8c > stack_pointer = (PyObject **) 0x2 > next_instr = (unsigned char *) 0x9291c4c0 "\200\001" > opcode = 96006480 > oparg = 25214856 > why = WHY_NOT > err = 0 > x = (PyObject *) 0x2 > v = (PyObject *) 0x1042060 > w = (PyObject *) 0x5b8f150 > u = (PyObject *) 0x6cfe80 > t = (PyObject *) 0x5b8f150 > stream = (PyObject *) 0x1042060 > fastlocals = (PyObject **) 0x180bf5c > freevars = (PyObject **) 0x180bf88 > retval = (PyObject *) 0x0 > tstate = (PyThreadState *) 0x600230 > co = (PyCodeObject *) 0xc5ae0 > instr_ub = -1 > instr_lb = 0 > instr_prev = -1 > first_instr = (unsigned char *) 0x623394 "t" > names = (PyObject *) 0xdb58 > consts = (PyObject *) 0xc65a0 > #34 0x0028da5c in PyEval_EvalCodeEx (co=0xc5ae0, > globals=0xa293ab98, locals=0x9291c4c0, args=0x180bf74, argcount=2, > kws=0x0, kwcount=0, defs=0x105a6fc, defcount=5, closure=0x0) at / > Volumes/Data/Users/ronald/Universal/python24-fat/Python/ceval.c:2736 > f = (PyFrameObject *) 0x180be10 > retval = (PyObject *) 0x105a710 > fastlocals = (PyObject **) 0x180bf5c > freevars = (PyObject **) 0x180bf88 > tstate = (PyThreadState *) 0x600230 > x = (PyObject *) 0x6661f0 > u = (PyObject *) 0x105a710 > defcount = 5 > closure = (PyObject *) 0x0 > #35 0x0022bf40 in function_call (func=0x105f8b0, arg=0x5b06cd8, > kw=0x0) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/funcobject.c:548 > result = (PyObject *) 0xc5ae0 > argdefs = (PyObject *) 0xc5ae0 > d = (PyObject **) 0x105a6fc > k = (PyObject **) 0x0 > nk = 0 > nd = 5 > #36 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, > kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/abstract.c:1795 > result = (PyObject *) 0x5b06cd8 > call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> > #37 0x00217324 in instancemethod_call (func=0x6cfe80, > arg=0x5b06cd8, kw=0x0) at /Volumes/Data/Users/ronald/Universal/ > python24-fat/Objects/classobject.c:2447 > self = (PyObject *) 0x5b095d0 > class = (PyObject *) 0x1 > result = (PyObject *) 0x5b095d0 > #38 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, > kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/abstract.c:1795 > result = (PyObject *) 0xaf6e8 > call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> > #39 0x00259730 in slot_tp_init (self=0x6cfe80, args=0x5b095b0, > kwds=0x0) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/typeobject.c:4759 > init_str = (PyObject *) 0x5680 > meth = (PyObject *) 0xaf6e8 > res = (PyObject *) 0x5b095b0 > #40 0x0025c428 in type_call (type=0x63f9b0, args=0x5b095b0, > kwds=0x0) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/typeobject.c:435 > obj = (PyObject *) 0x5b095d0 > #41 0x0020d5a4 in PyObject_Call (func=0x6cfe80, arg=0xa293ab98, > kw=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Objects/abstract.c:1795 > result = (PyObject *) 0x5b095b0 > call = (ternaryfunc) 0x9291c4c0 <-[NSObject autorelease]+24> > #42 0x0028ba98 in PyEval_EvalFrame (f=0x6c8f20) at /Volumes/Data/ > Users/ronald/Universal/python24-fat/Python/ceval.c:3771 > callargs = (PyObject *) 0x5b095b0 > kwdict = (PyObject *) 0x0 > nk = 0 > func = (PyObject *) 0x63f9b0 > pfunc = (PyObject **) 0x6c9074 > w = (PyObject *) 0x6cfe80 > sp = (PyObject **) 0x6c9078 > stack_pointer = (PyObject **) 0x1 > next_instr = (unsigned char *) 0x9291c4c0 "\200\001" > opcode = 0 > oparg = 7114868 > why = WHY_NOT > err = 0 > x = (PyObject *) 0x1 > v = (PyObject *) 0x63f9b0 > w = (PyObject *) 0x0 > u = (PyObject *) 0x6cfe80 > t = (PyObject *) 0x0 > stream = (PyObject *) 0x63f9b0 > fastlocals = (PyObject **) 0x6c906c > freevars = (PyObject **) 0x6c9074 > retval = (PyObject *) 0x0 > tstate = (PyThreadState *) 0x600230 > co = (PyCodeObject *) 0xe1b20 > instr_ub = -1 > instr_lb = 0 > instr_prev = -1 > first_instr = (unsigned char *) 0x4b544 "t" > names = (PyObject *) 0x50ea0 > consts = (PyObject *) 0xe1af0 > #43 0x0028b984 in PyEval_EvalFrame (f=0x608800) at /Volumes/Data/ > Users/ronald/Universal/python24-fat/Python/ceval.c:3645 > f = (PyFrameObject *) 0x6c8f20 > tstate = (PyThreadState *) 0x600230 > fastlocals = (PyObject **) 0x9291c4c0 > stack = (PyObject **) 0xa291b704 > co = (PyCodeObject *) 0x6cfe80 > nd = -1835940672 > globals = (PyObject *) 0x68 > argdefs = (PyObject *) 0x90a3c628 > d = (PyObject **) 0x90a3c628 > n = 2 > pfunc = (PyObject **) 0x608950 > w = (PyObject *) 0x6cfe80 > sp = (PyObject **) 0x60895c > stack_pointer = (PyObject **) 0x2 > next_instr = (unsigned char *) 0x9291c4c0 "\200\001" > opcode = 6292016 > oparg = 6326608 > why = WHY_NOT > err = 0 > x = (PyObject *) 0x2 > v = (PyObject *) 0x105fb70 > w = (PyObject *) 0x600230 > u = (PyObject *) 0x6cfe80 > t = (PyObject *) 0x600230 > stream = (PyObject *) 0x105fb70 > fastlocals = (PyObject **) 0x60894c > freevars = (PyObject **) 0x60894c > retval = (PyObject *) 0x0 > tstate = (PyThreadState *) 0x600230 > co = (PyCodeObject *) 0xe1da0 > instr_ub = -1 > instr_lb = 0 > instr_prev = -1 > first_instr = (unsigned char *) 0x184c414 "d" > names = (PyObject *) 0x1840610 > consts = (PyObject *) 0x60ad60 > #44 0x0028da5c in PyEval_EvalCodeEx (co=0xe1da0, > globals=0xa293ab98, locals=0x9291c4c0, args=0x0, argcount=0, > kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at /Volumes/ > Data/Users/ronald/Universal/python24-fat/Python/ceval.c:2736 > f = (PyFrameObject *) 0x608800 > retval = (PyObject *) 0x0 > fastlocals = (PyObject **) 0x60894c > freevars = (PyObject **) 0x60894c > tstate = (PyThreadState *) 0x600230 > x = (PyObject *) 0x6661f0 > u = (PyObject *) 0x0 > defcount = 0 > closure = (PyObject *) 0x0 > #45 0x0028dbe4 in PyEval_EvalCode (co=0x6cfe80, globals=0xa293ab98, > locals=0x68) at /Volumes/Data/Users/ronald/Universal/python24-fat/ > Python/ceval.c:484 > No locals. > #46 0x002b5ba8 in PyRun_FileExFlags (fp=0xa000db44, > filename=0xbffff809 "/Users/jordan/ruby_testing/ > archive_and_send_appscript_alternate_local.py", start=-1602514356, > globals=0x1fa50, locals=0x1fa50, closeit=1, flags=0xe1da0) at / > Volumes/Data/Users/ronald/Universal/python24-fat/Python/pythonrun.c: > 1265 > co = (PyCodeObject *) 0xe1da0 > v = (PyObject *) 0xe230 > n = (node *) 0xe230 > #47 0x002b5dbc in PyRun_SimpleFileExFlags (fp=0xa000db44, > filename=0xbffff809 "/Users/jordan/ruby_testing/ > archive_and_send_appscript_alternate_local.py", closeit=1, > flags=0xbffff54c) at /Volumes/Data/Users/ronald/Universal/python24- > fat/Python/pythonrun.c:860 > d = (PyObject *) 0x1fa50 > v = (PyObject *) 0x0 > ext = 0xbffff84d "l.py" > #48 0x002c0bfc in Py_Main (argc=-2147483648, argv=0xbffff6b0) at / > Volumes/Data/Users/ronald/Universal/python24-fat/Modules/main.c:501 > c = 7143040 > sts = -1610605668 > command = 0x0 > filename = 0xa293ab98 "\220?\200\b\220?H\224\220?\\\210\220? > \222?\220??" > module = 0x0 > fp = (FILE *) 0xa000db44 > p = 0x6cfe80 "?{\226t" > inspect = 0 > unbuffered = 3211608 > skipfirstline = 0 > stdin_is_interactive = 1 > help = -1073743863 > version = 1 > saw_inspect_flag = 536870912 > saw_unbuffered_flag = -1073744564 > cf = { > cf_flags = 0 > } > #49 0x0000257c in _call_objcInit () at /SourceCache/Csu/Csu-58/ > crt.c:361 > i = 3221223100 > count = 3221223088 > _dyld_image_count_fn = (unsigned int (*)()) 0x8fe07364 > <__dyld__Z20_dyld_mod_term_funcsv> > _dyld_get_image_name_fn = (const char *(*)()) 0 > _dyld_get_image_header_fn = (const void *(*)()) 0 > NSLookupSymbolInImage_fn = (const void *(*)()) 0 > NSAddressOfSymbol_fn = (void *(*)()) 0xbffff6a8 > #50 0x00002424 in _start (argc=2, argv=0xbffff6b0, envp=0xbffff6bc) > at /SourceCache/Csu/Csu-58/crt.c:205 > p = 0xa291b704 "\220" > q = (char **) 0xffffffff > term = (void (*)()) 0 > (gdb) > > On Jun 28, 2006, at 15:23 , Bob Ippolito wrote: > >> I don't see anything in this script that could directly cause >> those warnings. It's got to be something in appscript calls into... >> >> If you run it under GDB with a breakpoint on _NSAutoreleaseNoPool >> you might be able to track it down. If you could reproduce the >> issue in such a way that it was easy to reproduce then someone >> else would probably look at it, but in its current state I don't >> think this script is going to work very well on anyone else's >> machine. >> >> CoreFoundation doesn't have autorelease pools and could never >> trigger this message on its own. There *must* be some Foundation- >> based Objective-C code involved somewhere along the way. No such >> code is in Python, but it's possible that there is some such >> dependency in something appscript is using. >> >> -bob >> >> On Jun 28, 2006, at 12:26 PM, Jordan Breeding wrote: >> >>> Okay, I am attaching a copy of the current script. Usernames, >>> passwords, and email addresses have been replaced with "****". >>> This code might be a little rough, probably looks like c++ >>> instead of pure python, etc. But it does work except for that I >>> get those errors from time to time. I seem to get the errors >>> regardless of whether I call python or pythonw. I am using the >>> latest appscript (appscript installer 1.3.2) and Universal Python >>> 2.4.3. Thanks for any help tracking down why these errors/ >>> warnings occur. >>> >>> Jordan >>> >>> On Wednesday, June 28, 2006, at 02:01PM, Bob Ippolito >>> wrote: >>> >>>> pythonw is and always has been a stub that launches a regular >>>> python >>>> interpreter. There is nothing special about it except for the path >>>> the regular interpreter is located at. The only thing it can do is >>>> enable WindowServer access; it shouldn't ever cause any issues >>>> (especially of this sort). In other words, it is absolutely not >>>> your >>>> problem. >>>> >>>> The script isn't attached. I doubt anyone will be able to help >>>> you on >>>> this without source code. You are correct about the message's >>>> meaning, but without source the cause can't be determined. >>>> >>>> -bob >>>> >>>> On Jun 28, 2006, at 11:44 AM, Jordan Breeding wrote: >>>> >>>>> Hello, >>>>> >>>>> Do you think that the Python 2.4.3 Universal build could be having >>>>> this effect with python and pythonw now combined? I don't see >>>>> these messages all of the time but when I do it is a block of >>>>> about >>>>> 10 or so of them, and I usually only get the messages once per run >>>>> of a script even when they do show up. I tried googling around >>>>> and >>>>> it seems like this message means something was marked autorelease >>>>> in Cocoa somewhere but without a pool in place. Please let me >>>>> know >>>>> if you think you know what is going on but need more information. >>>>> The problem might also be present in the 2.5b1 Universal, don't >>>>> know yet because I don't have an appscript module for python built >>>>> yet that will work with 2.5b1. >>>>> >>>>> Thanks, >>>>> Jordan >>>>> >>>>> From: has >>>>> To: Jordan Breeding >>>>> Date: Wed Jun 28, 2006 11:31:03 AM CDT >>>>> Subject: Re: python appscript is displaying warning/errors >>>>> sometimes >>>>> >>>>> Hi, >>>>> >>>>>> I am using appscript in python to do some various tasks in >>>>>> iTunes. >>>>>> The scripts are organized by task. One of the scripts makes some >>>>>> zip files based on a playlist and then sends them. The problem I >>>>>> have is that while the script does compete all of its takes I get >>>>>> this set of messages sometimes: >>>>>> >>>>>> 2006-06-21 09:23:26.019 Python[21992] *** _NSAutoreleaseNoPool(): >>>>>> Object 0x6fa480 of class NSCFString autoreleased with no pool in >>>>>> place - just leaking >>>>>> ... >>>>>> >>>>>> I am attaching a copy of the script with servernames, usernames, >>>>>> and passwords blanked out. I know it probably isn't the greatest >>>>>> code in the world but it seems to get the job done and I was just >>>>>> wondering if you could easily spot the place that is leaking. >>>>> >>>>> Hmm, dunno; not very good on that stuff. If I had to guess, I'd >>>>> say >>>>> check the interpreter; I think it was rewritten recently to >>>>> eliminate >>>>> the python/pythonw dichotomy. I don't think any of the modules in >>>>> your script are using Cocoa/CoreFoundation. Sorry I can't be more >>>>> helpful. >>>>> >>>>> Regards, >>>>> >>>>> has >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>>>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>>> >>>> >>>> >>>> >> > From njriley at uiuc.edu Thu Jun 29 03:00:05 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Wed, 28 Jun 2006 20:00:05 -0500 Subject: [Pythonmac-SIG] Fwd: Re: python appscript is displaying warning/errors sometimes In-Reply-To: References: <15961016.1151520269041.JavaMail.jordan.breeding@mac.com> <3CDEC8AB-3764-4597-BDA4-016D0154C502@redivi.com> <1179707.1151522798812.JavaMail.jordan.breeding@mac.com> <7FDAADE1-F64C-4A36-A42B-FE0841F0ACA1@redivi.com> <314206C3-E378-4966-9465-1C22C9ECBCBC@mac.com> Message-ID: <20060629010005.GA24800@uiuc.edu> On Wed, Jun 28, 2006 at 05:47:34PM -0700, Bob Ippolito wrote: > You have some kind of haxie-like-thing (an InputManager maybe) > installed. That haxie is broken and causing those messages. > > #6 0x059be320 in DFPatch::Initialize () > > No symbol table info available. Looks like SCPatch/Default Folder X. Report it as a bug. -- Nicholas Riley | From glassfordm at hotmail.com Thu Jun 29 17:20:27 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Thu, 29 Jun 2006 11:20:27 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> Message-ID: Bob Ippolito wrote: > The bz2 module is part of the Python distribution. The best route > would be to download the Python source, extract the source for the > bz2 extension and create a standalone setup.py for it. Tweak it such > that it links to a copy of libbz2 that you've compiled statically and > universally, and then replace your Python installation's bz2 with > that one. > > It's not really trivial, but it's the only option you have unless > someone else does it first. It sounds like Ronald will probably > create another 2.4.3 installer in the future that fixes this and a > few other issues, but I don't know when he'll get around to it (if > ever, I don't speak for his free time). > > In your situation, I would just give up on 10.3 users until the issue > with Python is resolved (which is either going to happen when 2.5 > comes out, or when the 2.4.3 installer gets updated). A last question to help me understand things. At http://undefined.org/python/py2app.html, I read that, among other things, py2app will "Make the application bundle standalone" like this: """ o Since a typical Python application may have C library dependencies, such as the Python interpreter itself, wxWidgets, etc. a second dependency resolution pass occurs on the application bundle. o Scan the application bundle for all Mach-O files (executables, shared libraries, plugins, extensions, etc.). o Read the load commands from every Mach-O file (using macholib) and build a dependency graph. o Copy in every dependent dylib (shared library) and framework that is not already in the application bundle. Note that dylibs and frameworks in vendor locations (/System and /usr - except for /usr/local) are NOT included in your application bundle. This can include the Python interpreter, if you are using a Python interpreter shipped with Mac OS X. Thus your application may be "tightly bound" to a particular major version of Mac OS X if you are using the vendor Python. o Rewrite the Mach-O load commands such that the libraries know that they have moved inside of an application bundle (i.e. using @executable_path relative ids). o Strip every Mach-O file of extraneous information (debugging symbols, etc.) to save space. This may be disabled with --no-strip. """ My particular question is about the "Copy in every dependent dylib..." and "Rewrite the Mach-O load commands such that the libraries know that they have moved inside of an application bundle..." steps. Why do these steps not apply in the case of the bz2 library that I'm having trouble with? Mike From bob at redivi.com Thu Jun 29 17:54:16 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 29 Jun 2006 08:54:16 -0700 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> Message-ID: On Jun 29, 2006, at 8:20 AM, Michael Glassford wrote: > Bob Ippolito wrote: >> The bz2 module is part of the Python distribution. The best route >> would be to download the Python source, extract the source for the >> bz2 extension and create a standalone setup.py for it. Tweak it such >> that it links to a copy of libbz2 that you've compiled statically and >> universally, and then replace your Python installation's bz2 with >> that one. >> >> It's not really trivial, but it's the only option you have unless >> someone else does it first. It sounds like Ronald will probably >> create another 2.4.3 installer in the future that fixes this and a >> few other issues, but I don't know when he'll get around to it (if >> ever, I don't speak for his free time). >> >> In your situation, I would just give up on 10.3 users until the issue >> with Python is resolved (which is either going to happen when 2.5 >> comes out, or when the 2.4.3 installer gets updated). > > A last question to help me understand things. > > At http://undefined.org/python/py2app.html, I read that, among other > things, py2app will "Make the application bundle standalone" like > this: > > """ > o Since a typical Python application may have C library dependencies, > such as the Python interpreter itself, wxWidgets, etc. a second > dependency resolution pass occurs on the application bundle. > o Scan the application bundle for all Mach-O files (executables, > shared > libraries, plugins, extensions, etc.). > o Read the load commands from every Mach-O file (using macholib) and > build a dependency graph. > o Copy in every dependent dylib (shared library) and framework that is > not already in the application bundle. Note that dylibs and frameworks > in vendor locations (/System and /usr - except for /usr/local) are NOT > included in your application bundle. This can include the Python > interpreter, if you are using a Python interpreter shipped with Mac OS > X. Thus your application may be "tightly bound" to a particular major > version of Mac OS X if you are using the vendor Python. > o Rewrite the Mach-O load commands such that the libraries know that > they have moved inside of an application bundle (i.e. using > @executable_path relative ids). > o Strip every Mach-O file of extraneous information (debugging > symbols, > etc.) to save space. This may be disabled with --no-strip. > """ > > My particular question is about the "Copy in every dependent dylib..." > and "Rewrite the Mach-O load commands such that the libraries know > that > they have moved inside of an application bundle..." steps. Why do > these > steps not apply in the case of the bz2 library that I'm having > trouble with? """ > Note that dylibs and frameworks > in vendor locations (/System and /usr - except for /usr/local) are NOT > included in your application bundle. """ -bob From glassfordm at hotmail.com Thu Jun 29 18:11:00 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Thu, 29 Jun 2006 12:11:00 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> Message-ID: Bob Ippolito wrote: > On Jun 29, 2006, at 8:20 AM, Michael Glassford wrote: > >> Bob Ippolito wrote: >>> The bz2 module is part of the Python distribution. The best route >>> would be to download the Python source, extract the source for the >>> bz2 extension and create a standalone setup.py for it. Tweak it such >>> that it links to a copy of libbz2 that you've compiled statically and >>> universally, and then replace your Python installation's bz2 with >>> that one. >>> >>> It's not really trivial, but it's the only option you have unless >>> someone else does it first. It sounds like Ronald will probably >>> create another 2.4.3 installer in the future that fixes this and a >>> few other issues, but I don't know when he'll get around to it (if >>> ever, I don't speak for his free time). >>> >>> In your situation, I would just give up on 10.3 users until the issue >>> with Python is resolved (which is either going to happen when 2.5 >>> comes out, or when the 2.4.3 installer gets updated). >> A last question to help me understand things. >> >> At http://undefined.org/python/py2app.html, I read that, among other >> things, py2app will "Make the application bundle standalone" like >> this: >> >> """ >> o Since a typical Python application may have C library dependencies, >> such as the Python interpreter itself, wxWidgets, etc. a second >> dependency resolution pass occurs on the application bundle. >> o Scan the application bundle for all Mach-O files (executables, >> shared >> libraries, plugins, extensions, etc.). >> o Read the load commands from every Mach-O file (using macholib) and >> build a dependency graph. >> o Copy in every dependent dylib (shared library) and framework that is >> not already in the application bundle. Note that dylibs and frameworks >> in vendor locations (/System and /usr - except for /usr/local) are NOT >> included in your application bundle. This can include the Python >> interpreter, if you are using a Python interpreter shipped with Mac OS >> X. Thus your application may be "tightly bound" to a particular major >> version of Mac OS X if you are using the vendor Python. >> o Rewrite the Mach-O load commands such that the libraries know that >> they have moved inside of an application bundle (i.e. using >> @executable_path relative ids). >> o Strip every Mach-O file of extraneous information (debugging >> symbols, >> etc.) to save space. This may be disabled with --no-strip. >> """ >> >> My particular question is about the "Copy in every dependent dylib..." >> and "Rewrite the Mach-O load commands such that the libraries know >> that >> they have moved inside of an application bundle..." steps. Why do >> these >> steps not apply in the case of the bz2 library that I'm having >> trouble with? > > """ >> Note that dylibs and frameworks >> in vendor locations (/System and /usr - except for /usr/local) are NOT >> included in your application bundle. > """ I did see that, but interpreted the "except for /usr/local" to mean: Note that dylibs and frameworks in vendor locations (/System and /usr) are not included--except that those in /usr/local are. Oops, looking back, I see my mistake: I was remembering the bz2 file I was having problems with as being in /usr/local, but it's actually in /usr/lib. Sorry for the noise. Mike From Chris.Barker at noaa.gov Thu Jun 29 21:04:07 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 29 Jun 2006 12:04:07 -0700 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> Message-ID: <44A42427.6030600@noaa.gov> Michael Glassford wrote: >> """ >>> Note that dylibs and frameworks >>> in vendor locations (/System and /usr - except for /usr/local) are NOT >>> included in your application bundle. >> """ Would it be hard to put a little hack in Py2App to include that particular lib, even though it is in /usr? Or better yet, a way to pass in a list of libs you want included regardless of their location. Of course, this assumes that the lib you get with 10.4 will work on 10.3.9... -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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 glassfordm at hotmail.com Thu Jun 29 21:04:21 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Thu, 29 Jun 2006 15:04:21 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <1E1E9D7C-1FD4-4A4E-BAE5-397F0648E735@mac.com> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> <1E1E9D7C-1FD4-4A4E-BAE5-397F0648E735@mac.com> Message-ID: Ronald Oussoren wrote: > On 28-jun-2006, at 20:56, Bob Ippolito wrote: > >> >> It's not really trivial, but it's the only option you have unless >> someone else does it first. It sounds like Ronald will probably >> create another 2.4.3 installer in the future that fixes this and a >> few other issues, but I don't know when he'll get around to it (if >> ever, I don't speak for his free time). > > I'm doing this in my free time, I'm hoping to do a new release before > 2.4.4 gets out but don't promise anything. > >> In your situation, I would just give up on 10.3 users until the issue >> with Python is resolved (which is either going to happen when 2.5 >> comes out, or when the 2.4.3 installer gets updated). > > And if you want support for 10.3 actually testing the 2.5 installer > would be nice. I do some testing on 10.3, but as all my systems run > 10.4 and I don't have a business-need for supporting 10.3 it doesn't > get a much attention as it should. > > To do that you'll have to build it from source on a 10.4.x system > with xcode 2.3 and the 10.4u SDK installed. Just run Mac/BuildScript/ > build-installer.py to create a dmg containing the installer. It's not entirely clear if the "2.5 installer" you mention above means PyObjC or Python. If the former, I tried it (using the Python 2.5 installer here: http://www.python.org/ftp/python/2.5/python-2.5b1-macosx2006-06-20.dmg) and it isn't working. I built it on an Intel Mac Mini, and when I run it on 10.3.9 I see this: """ 'import site' failed; use -v for traceback Traceback (most recent call last): File "/Volumes/MyAppDisk/MyApp.app/Contents/Resources/__boot__.py", line 4, in _chdir_resource() File "/Volumes/MyAppDisk/MyApp.app/Contents/Resources/__boot__.py", line 2, in _chdir_resource import os zipimport.ZipImportError: can't decompress data; zlib not available """ If you need me to build Python 2.5, I'll go back and try that. Mike From bob at redivi.com Thu Jun 29 23:23:18 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 29 Jun 2006 14:23:18 -0700 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <44A42427.6030600@noaa.gov> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> <44A42427.6030600@noaa.gov> Message-ID: <566636E2-F203-41D3-897F-2F46FBEEB2C5@redivi.com> On Jun 29, 2006, at 12:04 PM, Christopher Barker wrote: > Michael Glassford wrote: >>> """ >>>> Note that dylibs and frameworks >>>> in vendor locations (/System and /usr - except for /usr/local) >>>> are NOT >>>> included in your application bundle. >>> """ > > Would it be hard to put a little hack in Py2App to include that > particular lib, even though it is in /usr? > > Or better yet, a way to pass in a list of libs you want included > regardless of their location. > > Of course, this assumes that the lib you get with 10.4 will work on > 10.3.9... I'm not going to do that. -bob From mcovill at mac.com Fri Jun 30 20:54:22 2006 From: mcovill at mac.com (Mike Covill) Date: Fri, 30 Jun 2006 14:54:22 -0400 Subject: [Pythonmac-SIG] Launching a python app with an associated document Message-ID: Does anyone have experience creating a pure python app (no Cocoa integration) which is associated with a document extension? We would like to be able to launch our application by double-clicking an associated document (associated using CFBundleDocumentTypes in the info.plist) and having the data in the document loaded into the python app. I have added the following code to our setup.py file: plist = dict( CFBundleDocumentTypes = [ dict( CFBundleTypeExtensions=["madf",], CFBundleTypeName="myApp Data File", CFBundleTypeRole="Editor", CFBundleTypeIconFile='myAppDocument.icns', ), ] ) py2app_options = dict(..., plist=plist, ) the application now launches when we double-click on the document, but I have yet to find how we might feed the contents of the document to an appropriate reader function inside our app. We had a look at the sys.argv list passed in to main.py thinking the name of the document might be in there but this doesn't seem to be the case. We also checked os.environ. Thanks for any help or pointers to relevant info, Mike -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060630/95dbae61/attachment.htm From glassfordm at hotmail.com Fri Jun 30 21:26:37 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Fri, 30 Jun 2006 15:26:37 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <566636E2-F203-41D3-897F-2F46FBEEB2C5@redivi.com> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> <44A42427.6030600@noaa.gov> <566636E2-F203-41D3-897F-2F46FBEEB2C5@redivi.com> Message-ID: Bob Ippolito wrote: > On Jun 29, 2006, at 12:04 PM, Christopher Barker wrote: > >> Michael Glassford wrote: >>>> """ >>>>> Note that dylibs and frameworks >>>>> in vendor locations (/System and /usr - except for /usr/local) >>>>> are NOT >>>>> included in your application bundle. >>>> """ >> Would it be hard to put a little hack in Py2App to include that >> particular lib, even though it is in /usr? >> >> Or better yet, a way to pass in a list of libs you want included >> regardless of their location. >> >> Of course, this assumes that the lib you get with 10.4 will work on >> 10.3.9... > > I'm not going to do that. Is that because it's a bad idea, or too much work for the benefit that would come from it, or why? Mike From bob at redivi.com Fri Jun 30 21:48:47 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 30 Jun 2006 12:48:47 -0700 Subject: [Pythonmac-SIG] Launching a python app with an associated document In-Reply-To: References: Message-ID: <516246EF-A711-4CF8-B30E-18FE5C1F708F@redivi.com> On Jun 30, 2006, at 11:54 AM, Mike Covill wrote: > Does anyone have experience creating a pure python app (no Cocoa > integration) which is associated with a document extension? > > We would like to be able to launch our application by double- > clicking an associated document (associated using > CFBundleDocumentTypes in the info.plist) and having the data in the > document loaded into the python app. I have added the following > code to our setup.py file: > > plist = dict( > CFBundleDocumentTypes = [ > dict( > CFBundleTypeExtensions=["madf",], > CFBundleTypeName="myApp Data File", > CFBundleTypeRole="Editor", > CFBundleTypeIconFile='myAppDocument.icns', > ), > ] > ) > > py2app_options = dict(..., > plist=plist, > ) > > the application now launches when we double-click on the document, > but I have yet to find how we might feed the contents of the > document to an appropriate reader function inside our app. We had > a look at the sys.argv list passed in to main.py thinking the name > of the document might be in there but this doesn't seem to be the > case. We also checked os.environ. You want to use the argv_emulation option. OS X sends the list of documents to open via Apple Events. -bob -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060630/63adf4cf/attachment.html From bob at redivi.com Fri Jun 30 21:49:35 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 30 Jun 2006 12:49:35 -0700 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> <44A42427.6030600@noaa.gov> <566636E2-F203-41D3-897F-2F46FBEEB2C5@redivi.com> Message-ID: On Jun 30, 2006, at 12:26 PM, Michael Glassford wrote: > Bob Ippolito wrote: >> On Jun 29, 2006, at 12:04 PM, Christopher Barker wrote: >> >>> Michael Glassford wrote: >>>>> """ >>>>>> Note that dylibs and frameworks >>>>>> in vendor locations (/System and /usr - except for /usr/local) >>>>>> are NOT >>>>>> included in your application bundle. >>>>> """ >>> Would it be hard to put a little hack in Py2App to include that >>> particular lib, even though it is in /usr? >>> >>> Or better yet, a way to pass in a list of libs you want included >>> regardless of their location. >>> >>> Of course, this assumes that the lib you get with 10.4 will work on >>> 10.3.9... >> >> I'm not going to do that. > > Is that because it's a bad idea, or too much work for the benefit that > would come from it, or why? It's a bad idea, and redistributing components of OS X isn't legal anyway. -bob From Chris.Barker at noaa.gov Fri Jun 30 22:50:36 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 30 Jun 2006 13:50:36 -0700 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> <44A42427.6030600@noaa.gov> <566636E2-F203-41D3-897F-2F46FBEEB2C5@redivi.com> Message-ID: <44A58E9C.704@noaa.gov> Bob Ippolito wrote: >>>> Would it be hard to put a little hack in Py2App to include that >>>> particular lib, even though it is in /usr? >>>> >>>> Or better yet, a way to pass in a list of libs you want included >>>> regardless of their location. > It's a bad idea, and redistributing components of OS X isn't legal > anyway. OK, I understand the legal issues -- darn it! However. This is a problem, and there appears to be no solution, other than: 1) Don't support 10.3.9 or 2) Wait for Ronald, out of the goodness of his heart, in his free time, to hack the Python build and put out a new version. I'm guessing that this may not be the ONLY lib that has this problem -- it's just the the one that's been discovered. Also, it seems possible that a user might have a similar problem with a lib that isn't Apple's. While I understand that the legal issues are such that we shouldn't include that lib be default, having a hook so that the user could specify libs they wanted included by hand would be helpful. In this case, it wouldn't be a big deal to build your own copy of the bz2 lib and include that. Could you just copy such a lib into your bundle after the fact? If so -- where? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (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 glassfordm at hotmail.com Fri Jun 30 23:07:24 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Fri, 30 Jun 2006 17:07:24 -0400 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <44A58E9C.704@noaa.gov> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> <44A42427.6030600@noaa.gov> <566636E2-F203-41D3-897F-2F46FBEEB2C5@redivi.com> <44A58E9C.704@noaa.gov> Message-ID: Christopher Barker wrote: > Bob Ippolito wrote: >>>>> Would it be hard to put a little hack in Py2App to include that >>>>> particular lib, even though it is in /usr? >>>>> >>>>> Or better yet, a way to pass in a list of libs you want included >>>>> regardless of their location. > >> It's a bad idea, and redistributing components of OS X isn't legal >> anyway. > > OK, I understand the legal issues -- darn it! > > However. This is a problem, and there appears to be no solution, other than: > > 1) Don't support 10.3.9 > > or > > 2) Wait for Ronald, out of the goodness of his heart, in his free time, > to hack the Python build and put out a new version. Or, as we're considering, have separate Panther and Tiger builds until Python 2.5 (which is supposed to have this fix already in it) is released. It's scheduled for August, I believe. I agree, though, that it would be nice if there were a way for "mere mortals" to deal with problem libraries on their own. > > I'm guessing that this may not be the ONLY lib that has this problem -- > it's just the the one that's been discovered. Also, it seems possible > that a user might have a similar problem with a lib that isn't Apple's. > > While I understand that the legal issues are such that we shouldn't > include that lib be default, having a hook so that the user could > specify libs they wanted included by hand would be helpful. In this > case, it wouldn't be a big deal to build your own copy of the bz2 lib > and include that. > > Could you just copy such a lib into your bundle after the fact? If so -- > where? > > -Chris Mike From bob at redivi.com Fri Jun 30 23:08:20 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 30 Jun 2006 14:08:20 -0700 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <44A58E9C.704@noaa.gov> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> <44A42427.6030600@noaa.gov> <566636E2-F203-41D3-897F-2F46FBEEB2C5@redivi.com> <44A58E9C.704@noaa.gov> Message-ID: <0A03F107-8498-4D7A-815D-9E6ADF116D4D@redivi.com> On Jun 30, 2006, at 1:50 PM, Christopher Barker wrote: > Bob Ippolito wrote: >>>>> Would it be hard to put a little hack in Py2App to include that >>>>> particular lib, even though it is in /usr? >>>>> >>>>> Or better yet, a way to pass in a list of libs you want included >>>>> regardless of their location. > >> It's a bad idea, and redistributing components of OS X isn't legal >> anyway. > > OK, I understand the legal issues -- darn it! > > However. This is a problem, and there appears to be no solution, > other than: > > 1) Don't support 10.3.9 > > or > > 2) Wait for Ronald, out of the goodness of his heart, in his free > time, > to hack the Python build and put out a new version. Or someone else can build one. Doesn't have to be Ronald. > I'm guessing that this may not be the ONLY lib that has this > problem -- > it's just the the one that's been discovered. Also, it seems possible > that a user might have a similar problem with a lib that isn't > Apple's. If there are other libs then maybe they'll get found someday and a bug would get filed. If someone really cared about 10.3, they'd go through and test everything with the universal build. If a lib that isn't Apple's is living in /usr/lib or /System then someone screwed up. > While I understand that the legal issues are such that we shouldn't > include that lib be default, having a hook so that the user could > specify libs they wanted included by hand would be helpful. In this > case, it wouldn't be a big deal to build your own copy of the bz2 lib > and include that. I'm still not going to do it. Stuff that ships with the OS shouldn't get redistributed. If you really really want to do it bad enough, you can figure it out. > Could you just copy such a lib into your bundle after the fact? If > so -- > where? You'd still need to install_name_tool over the lib and the extension, and there's a chance it might not work. I'm not going to walk through the steps, the right solution is just to get the bz2 extension built correctly against a third party (preferably static) lib. -bob From noah.gift at gmail.com Fri Jun 30 23:30:10 2006 From: noah.gift at gmail.com (Noah Gift) Date: Fri, 30 Jun 2006 17:30:10 -0400 Subject: [Pythonmac-SIG] writing a python module for the OS X Directory Access API Message-ID: I am currently writing a python module that wraps up the dscl tool up into python. Would this be a good open source project to post? I am pretty new to python and would love to work on an opensource project with smart people! The basic idea is that you can directly interact with the OS X specific Directory Access API through Python. Probably going to put a mod_python/PSP front end to it. That way new account creation would be even easier than using the phpmyldapadmin tool Noah Gift From woklist at kyngchaos.com Fri Jun 30 23:33:39 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri, 30 Jun 2006 16:33:39 -0500 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <44A58E9C.704@noaa.gov> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> <44A42427.6030600@noaa.gov> <566636E2-F203-41D3-897F-2F46FBEEB2C5@redivi.com> <44A58E9C.704@noaa.gov> Message-ID: <703FB886-3133-4C3D-B120-410B1D7EE706@kyngchaos.com> On Jun 30, 2006, at 3:50 PM, Christopher Barker wrote: > I'm guessing that this may not be the ONLY lib that has this > problem -- > it's just the the one that's been discovered. Also, it seems possible > that a user might have a similar problem with a lib that isn't > Apple's. > Here's a list of Panther-Tiger incompatibilities I came up with when working out Panther-compatible Tiger builds (not quite exhaustive, mainly stuff that directly affected what I was doing): ? libSystem - some new symbols in tiger. fdatasync (have declaration, but not function in Tiger) getpeereid ___stdoutp _statvfs Solution: use alternate functions somehow (ie postgres configure detects getpeereid and uses something else if not found) ? libncurses & friends libncurses.5.dylib in panther, back compat copy in tiger libncurses.5.4.dylib in tiger, compat ver 5.4.0 solution: force stuff to build with older lib linklib = /usr/lib/libncurses.5.dylib /usr/lib/libpanel.5.dylib /usr/lib/libmenu.5.dylib /usr/lib/libform.5.dylib ? libtermcap is a symlink to libncurses, so same problem & solution ? libbz2 static-only in panther, dynamic-only in Tiger, but same version solution: provide own libbz2, or link with libbz2.a in the 10.3.9 SDK ? libcurl.3 v2 in panther, Tiger has v2 symlinked to v3 Solution: provide own libcurl, or link to libcurl in 10.3.9 SDK (headers also) ? LDAP fw same version, but ber_pvt_opt_on is in tiger copy solution: use LDAP framework from 10.3.9 SDK had to do this for PHP, but haven't tested it yet ----- William Kyngesburye http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy From bob at redivi.com Fri Jun 30 23:51:00 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 30 Jun 2006 14:51:00 -0700 Subject: [Pythonmac-SIG] Universal binary build of py2app application won't run on 10.3.9 In-Reply-To: <703FB886-3133-4C3D-B120-410B1D7EE706@kyngchaos.com> References: <41367AA3-2351-4E5E-8E64-FFB61B4D8176@redivi.com> <44A2CE78.9080706@hotmail.com> <9EA1A2B0-77D5-4429-A94F-996D682B6CEC@redivi.com> <44A42427.6030600@noaa.gov> <566636E2-F203-41D3-897F-2F46FBEEB2C5@redivi.com> <44A58E9C.704@noaa.gov> <703FB886-3133-4C3D-B120-410B1D7EE706@kyngchaos.com> Message-ID: <2C09B694-E30D-4156-B802-71DE5620237B@redivi.com> On Jun 30, 2006, at 2:33 PM, William Kyngesburye wrote: > On Jun 30, 2006, at 3:50 PM, Christopher Barker wrote: > >> I'm guessing that this may not be the ONLY lib that has this >> problem -- >> it's just the the one that's been discovered. Also, it seems possible >> that a user might have a similar problem with a lib that isn't >> Apple's. >> > > Here's a list of Panther-Tiger incompatibilities I came up with when > working out Panther-compatible Tiger builds (not quite exhaustive, > mainly stuff that directly affected what I was doing): > > ? libSystem - some new symbols in tiger. > ? libncurses & friends > ? libtermcap I think the current build accommodates for these differences already by providing a static ncurses and by using some weak linking stuff for the new POSIX functionality. > ? libbz2 This is a known issue now. > ? libcurl.3 > ? LDAP fw Pretty sure Python doesn't link to either of these. -bob