From shane.holloway at ieee.org Tue Jan 2 07:50:00 2007 From: shane.holloway at ieee.org (Shane Holloway) Date: Mon, 1 Jan 2007 23:50:00 -0700 Subject: [Pythonmac-SIG] cyptes problem on MacOS X In-Reply-To: References: Message-ID: <5D1B2EB6-DD4E-42D8-81E6-026EED910F86@ieee.org> Russel, Sorry I have been away from this list a while. I have been using ctypes on Mac OSX with both PPC and Intel for about a year and a half now. They work great, as I am regularly interfacing with Quicktime, CoreVideo, and CoreImage, as well as the OpenGL and OpenAL frameworks. We have even been working with the Freetype2 libraries, and some various 3rd party vendor libraries. I think the problem you are having is more about interfacing with C var-args in the printf function, and less a platform problem. (None of the APIs I work with use varargs) We are having great success interfacing with system libraries using ctypes. Numpy makes a great ally when working with large quantities of data. The hardest part of your work will be interfacing with C++ code, mainly because C++ name mangling for methods is not standardized. Your best bet is to look for their external facing API, which are usually exposed in non-name-mangled C. The GCCXML (compiled from latest source) project does a pretty good job of finding mangled C++ entry points for various compiler toolchains, but your milage may vary. Hope that helps a bit, -Shane Holloway On Dec 11, 2006, at 1:20 PM, Russell E. Owen wrote: > I've been trying out ctypes (from MacPython 2.5) on MacOS X on a > PPC Mac > and have run into a problem. I hope I'm just doing something > stupid, but > it seems to match the tutorial so I'm really puzzled: > > import ctypes > libc = ctypes.CDLL("libc.dylib") > libc.printf("int=%d float=%f double=%f\n", ctypes.c_int(1), > ctypes.c_float(2.0), ctypes.c_double(3.0)); > > results in: > int=1 float=-1.996124 double=0.000000 > > I realize the docs doesn't actually claim to handle dylib files, but > I've seen at least some info on the web that claims it works. One site > suggested the need for ctypes.RTLD_GLOBAL to CDLL but adding it > made no > difference. > > On a related subject...assuming I can get this to work...does anyone > have any idea how the speed of ctypes relates to programming a > python C > extension or using SWIG? This is mostly for use with NumPy and > interfacing python to C/C++-based heavy duty astronomical image > processing code. > > Other suggestions are welcome. We'll mostly be interfacing to C++ so > I've considered trying out Boost, but it hasn't had an update in years > which worries me. Robustness, ease of use and speed are all major > requirements. Linux and MacOS X are the main platforms. > > -- Russell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From mas63 at cornell.edu Tue Jan 2 20:18:06 2007 From: mas63 at cornell.edu (Mike Solomon) Date: Tue, 2 Jan 2007 11:18:06 -0800 Subject: [Pythonmac-SIG] problem running py2app bundle referencing PyLucene Message-ID: Hey all, I'm a long-time python wrangler, but I've recently been doing more development for deployment on the Mac. I've been trying to get py2app to build a wrapper around a small Python server that uses PyLucene. Unfortunately, I've hit a few snags. When I build, I supply the following environment parameters to the location where I have the PyLucene.py, _PyLucene.so and required *dylib files. export DYLD_LIBRARY_PATH=~/Projects/dtsearch/lib export PYTHONPATH=~/Projects/dtsearch/lib; setup.py py2app seems to run without a problem and correctly tracks down the dependencies. However, when a I run a new terminal, without those environment variables, I get this spew: [msolomon]beast:~/Projects/dtsearch> dist/dtserv.app/Contents/MacOS/ dtserv Traceback (most recent call last): File "/Users/msolomon/Projects/dtsearch/dist/dtserv.app/Contents/ Resources/__boot__.py", line 137, in ? _run('dtserv.py') File "/Users/msolomon/Projects/dtsearch/dist/dtserv.app/Contents/ Resources/__boot__.py", line 134, in _run execfile(path, globals(), globals()) File "/Users/msolomon/Projects/dtsearch/dist/dtserv.app/Contents/ Resources/dtserv.py", line 17, in ? import dtsearch File "dtsearch.pyc", line 10, in ? File "search.pyc", line 7, in ? File "PyLucene.pyc", line 33, in ? ImportError: Failure linking new module: /Users/msolomon/Projects/ dtsearch/dist/dtserv.app/Contents/Resources/lib/python2.4/lib-dynload/ _PyLucene.so: Library not loaded: /opt/local/lib/gcc41/libgcj.7.dylib Referenced from: /Users/msolomon/Projects/dtsearch/dist/dtserv.app/ Contents/Resources/lib/python2.4/lib-dynload/_PyLucene.so Reason: image not found 2007-01-01 20:07:06.127 dtserv[8407] dtserv Error 2007-01-01 20:07:06.130 dtserv[8407] dtserv Error An unexpected error has occurred during execution of the main script ImportError: Failure linking new module: /Users/msolomon/Projects/ dtsearch/dist/dtserv.app/Contents/Resources/lib/python2.4/lib-dynload/ _PyLucene.so: Library not loaded: /opt/local/lib/gcc41/libgcj.7.dylib Referenced from: /Users/msolomon/Projects/dtsearch/dist/dtserv.app/ Contents/Resources/lib/python2.4/lib-dynload/_PyLucene.so Reason: image not found Now, the _PyLucene.so want to link against these libs, none of which exists at these paths (nor have they ever, on my machine). /opt/local/lib/gcc41/libgcj.7.dylib (compatibility version 8.0.0, current version 8.0.0) /opt/local/lib/gcc41/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/gcc41/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.8.0) So, normally, I have to export they correct DYLD_LIBRARY_PATH, so I added those variables back in. Now I get this: [msolomon]beast:~/Projects/dtsearch> dist/dtserv.app/Contents/MacOS/ dtserv Fatal Python error: Interpreter not initialized (version mismatch?) Abort trap I've spent several hours hunting through the bootstrap and a few other bits, but I didn't have a good intuitive feel for where the problem is. Is there something simple that I'm missing? Any help would be appreciated. Thanks, -Mike From davidh at digitalfish.com Tue Jan 2 20:13:50 2007 From: davidh at digitalfish.com (David Hill) Date: Tue, 2 Jan 2007 13:13:50 -0600 Subject: [Pythonmac-SIG] Problem with pygame and py2app Message-ID: Hi, I've been working on a small pygame app and I've just now started trying to build a Mac OS X application bundle out of it. When I run "python setup.py py2app" with no additional options, I get a verbose set of output ending with: > linking /Volumes/Storage/Users/davidh/Documents/workspace/Haul/src/ > dist/Haul.app/Contents/Frameworks/SDL.framework/Versions/Current -> A > Thinning /Volumes/Storage/Users/davidh/Documents/workspace/Haul/src/ > dist/Haul.app/Contents/Frameworks/SDL_image.framework/Versions/A/ > SDL_image to ppc, i386 > /usr/bin/lipo: -extract ppc specified but fat file: /Volumes/ > Storage/Users/davidh/Documents/workspace/Haul/src/dist/Haul.app/ > Contents/Frameworks/SDL_image.framework/Versions/A/SDL_image does > not contain that architecture > Traceback (most recent call last): > File "setup.py", line 25, in ? > app=[ > File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ > python2.4/distutils/core.py", line 149, in setup > dist.run_commands() > File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ > python2.4/distutils/dist.py", line 946, in run_commands > self.run_command(cmd) > File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ > python2.4/distutils/dist.py", line 966, in run_command > cmd_obj.run() > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/Py2App/py2app/build_app.py", line 389, in run > self._run() > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/Py2App/py2app/build_app.py", line 510, in _run > self.run_normal() > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/Py2App/py2app/build_app.py", line 570, in > run_normal > self.create_binaries(py_files, pkgdirs, extensions, loader_files) > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/Py2App/py2app/build_app.py", line 672, in > create_binaries > platfiles = mm.run() > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/Py2App/macholib/MachOStandalone.py", line > 153, in run > thin_to_archs(filename, nodearchs) > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/Py2App/macholib/util.py", line 146, in > thin_to_archs > raise ValueError, 'Error %d returned by: %s' % (retval, ''.join > (["'%s'" % arg for arg in command])) > ValueError: Error 1 returned by: '/usr/bin/lipo''/Volumes/Storage/ > Users/davidh/Documents/workspace/Haul/src/dist/Haul.app/Contents/ > Frameworks/SDL_image.framework/Versions/A/SDL_image''-output''/tmp/ > tmp1vFdMt''-extract''ppc''-extract''i386' The main problem seems to be that SDL_image doesn't contain the ppc architecture. If I run "file " I get the following: > /Volumes/Storage/Users/davidh/Documents/workspace/Haul/src/dist/ > Haul.app/Contents/Frameworks/SDL_image.framework/Versions/A/ > SDL_image: Mach-O universal binary with 2 architectures > /Volumes/Storage/Users/davidh/Documents/workspace/Haul/src/dist/ > Haul.app/Contents/Frameworks/SDL_image.framework/Versions/A/ > SDL_image (for architecture i386): Mach-O dynamically linked > shared library ppc > /Volumes/Storage/Users/davidh/Documents/workspace/Haul/src/dist/ > Haul.app/Contents/Frameworks/SDL_image.framework/Versions/A/ > SDL_image (for architecture cputype (0) cpusubtype (0)): Mach-O > universal binary with 2 architectures which seems very strange to me. If it has two architectures, I would have expected ppc and i386, not "cputype (0) cpusubtype (0)" as it says above. Did I somehow get my SDL installation messed up? I seem to have installed python 2.4.4, pyobjc 1.4, and pygame-1.8.0pre- py2.4. Perhaps that pre-py2.4 is my problem? I'm running on a Mac Pro with 10.4.8 and I'd like to be able to build a universal .app for this project. If it is necessary to reinstall python, pygame, pyobjc, and SDL, which versions should I use? Every time I look for the most recent matching versions, I seem to find python 2.5 but no associated pygame or pyobjc. I'm also unsure as to whether or not it is healthy to move on to python 2.5 if nothing else has been rebuilt yet. Please help! What should I have installed on my Mac Pro to develop on 10.4.8 and build universal binaries? I'm not using any python 2.5 specific features yet but I wouldn't mind moving in that direction eventually. Thanks, Dave From Chris.Barker at noaa.gov Fri Jan 5 01:05:26 2007 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 04 Jan 2007 16:05:26 -0800 Subject: [Pythonmac-SIG] So what can we do to clean up the wiki? In-Reply-To: <17815.20896.33046.900341@montanaro.dyndns.org> References: <17815.20896.33046.900341@montanaro.dyndns.org> Message-ID: <459D9646.8040600@noaa.gov> Just as a note, I've been very happy with the TRAC Wiki's I've used. I don't know how much of a pain it would be to switch to a new system, but it is nice. The SciPy Wiki is pretty nice too -- I'm not sure what' they are using. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Fri Jan 5 02:21:03 2007 From: bob at redivi.com (Bob Ippolito) Date: Thu, 4 Jan 2007 17:21:03 -0800 Subject: [Pythonmac-SIG] So what can we do to clean up the wiki? In-Reply-To: <459D9646.8040600@noaa.gov> References: <17815.20896.33046.900341@montanaro.dyndns.org> <459D9646.8040600@noaa.gov> Message-ID: <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> On 1/4/07, Christopher Barker wrote: > Just as a note, > > I've been very happy with the TRAC Wiki's I've used. I don't know how > much of a pain it would be to switch to a new system, but it is nice. > > The SciPy Wiki is pretty nice too -- I'm not sure what' they are using. If someone here knows how to migrate MoinMoin to trac that'd be a potential solution, but trac is also subject to spam... -bob From uche at ogbuji.net Fri Jan 5 02:44:01 2007 From: uche at ogbuji.net (Uche Ogbuji) Date: Thu, 04 Jan 2007 18:44:01 -0700 Subject: [Pythonmac-SIG] So what can we do to clean up the wiki? In-Reply-To: <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> References: <17815.20896.33046.900341@montanaro.dyndns.org> <459D9646.8040600@noaa.gov> <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> Message-ID: <459DAD61.9000902@ogbuji.net> Bob Ippolito wrote: > On 1/4/07, Christopher Barker wrote: > >> Just as a note, >> >> I've been very happy with the TRAC Wiki's I've used. I don't know how >> much of a pain it would be to switch to a new system, but it is nice. >> >> The SciPy Wiki is pretty nice too -- I'm not sure what' they are using. >> > > If someone here knows how to migrate MoinMoin to trac that'd be a > potential solution, but trac is also subject to spam... > Personally I have had more joy with Moin than Trac. I've had 2 open community projects derailed by problems with Trac flakiness. And I agree with Bob that Trac is not all that spam-proof. I think it's all stuff they're working on, but I'm partial admin on a Moin wiki and I've seen evidence of its spam prevention. For sure more unscientific intuition than anything else, so I guess the best choice is probably any system someone could actually commit to admin. -- Uche Ogbuji Work: The Kadomo Group, Inc. http://uche.ogbuji.net http://kadomo.com http://copia.ogbuji.net Lead dev at http://4Suite.org Articles: http://uche.ogbuji.net/tech/publications/ From bob at redivi.com Fri Jan 5 03:17:08 2007 From: bob at redivi.com (Bob Ippolito) Date: Thu, 4 Jan 2007 18:17:08 -0800 Subject: [Pythonmac-SIG] So what can we do to clean up the wiki? In-Reply-To: <2CD0A9D5-3634-4694-A991-ADDCEA3FD707@higginsandmacfarlane.com> References: <17815.20896.33046.900341@montanaro.dyndns.org> <459D9646.8040600@noaa.gov> <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> <2CD0A9D5-3634-4694-A991-ADDCEA3FD707@higginsandmacfarlane.com> Message-ID: <6a36e7290701041817t61a04516yc7c08e92dc4839a1@mail.gmail.com> On 1/4/07, Graham Higgins wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > On 5 Jan 2007, at 01:21, Bob Ippolito wrote: > > > If someone here knows how to migrate MoinMoin to trac that'd be a > > potential solution, but trac is also subject to spam... > > Moin's neat. It'll run as a WSGI-callable and has an external auth > facility which would probably pick up trac auth. > I said migrate, not integrate. Trac does the same thing (external auth, WSGI callable). I personally don't care whether it's Moin or Trac because I don't have time to babysit it whichever solution we end up with. We need a person to manage things, software isn't going to fix this problem with any permanence. -bob From kw at codebykevin.com Sat Jan 6 00:12:18 2007 From: kw at codebykevin.com (Kevin Walzer) Date: Fri, 05 Jan 2007 18:12:18 -0500 Subject: [Pythonmac-SIG] Shareware application using Tkinter Message-ID: <459EDB52.5060801@codebykevin.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I know there aren't a lot of Tkinter developers on this list, but I wanted to say that I've released a shareware program that makes use of Python/Tkinter: http://www.codebykevin.com/packetstream.html (there's a screenshot there) This app makes use of some recent advances in Tk/Tkinter development, including the Tile theming extension, which greatly improves the look and feel of Tk on OS X. If you pay attention to some of the specifics of the platform you are targeting (this app is for Mac OS X users) and to other points of application design, such as icons (I find the Tango set to be very polished and well-suited for the Mac; it doesn't scream "Linux"), then I think it's quite possible to make a nice, polished, native, professional-looking application with Tkinter. Thanks to various folks on this list who have helped me greatly with improving my Python and Tkinter chops, including Ronald Oussoren, Bop Ippolito, and Russell Owen. - -- Kevin Walzer Code by Kevin http://www.codebykevin.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFnttREsLm8HXyq4sRAo+kAJ9An/w+u06iOewFOG8zlE7J6WLFXACfZpOx a1JPYUKOiYN4fibTivaDl+I= =WgQJ -----END PGP SIGNATURE----- From daniellord at mac.com Sun Jan 7 00:42:25 2007 From: daniellord at mac.com (Daniel Lord) Date: Sat, 6 Jan 2007 15:42:25 -0800 Subject: [Pythonmac-SIG] gmpy universal build (static)? In-Reply-To: <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> References: <17815.20896.33046.900341@montanaro.dyndns.org> <459D9646.8040600@noaa.gov> <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> Message-ID: <02275A1D-1099-4FAE-AD8D-B1CC5CEBD5D4@mac.com> gmpy universal build (static) I struggled with it for a while, but was finally able to build both gmp and then gmpy as static universal libraries on my Macbook Pro. Dynamic libs are still problematic but I'll try that next. Is this something new or is this 'old hat' and no one cares. The reason I asked is Alex Martelli told me he struggled with it briefly a while back (liek a year ago ;-) and gave up. I finally found some spare cycles (rare for me) and tackled it. I hope I didn't 'reinvent the wheel'. But even so, the exercise was fun fo someone who gets far too little time at development these days. Make check runs fine on the gmp build. The question I have for this what is available as a check for gmpy so I can test this out on Intel and PPC systems to make sure I built it right. Then I'll package it up for distribution. Unless of course, I have indeed 'reinvented the wheel'. In which case I'll just shuffle off quietly...never mind...move along...nothing to see here... From rblove at houston.rr.com Sun Jan 7 19:39:36 2007 From: rblove at houston.rr.com (Robert Love) Date: Sun, 7 Jan 2007 12:39:36 -0600 Subject: [Pythonmac-SIG] Question on Python 2.5 and CoreGraphics Message-ID: <4EAB8EF6-F8A7-4461-BC32-2F18F1F3A540@houston.rr.com> Back in 2005 I had a python script that did some simple image manipulation with CoreGraphics. Since then I have upgraded to python 2.5 and the script no longer works. I think you all tried to explain this to me when I upgraded but didn't follow what was being said. I'm running a PPC machine with 10.4. which python /Library/Frameworks/Python.framework/Versions/Current/bin/python and ls -l /Library/Frameworks/Python.framework/Versions/Current/bin/python lrwxr-xr-x 1 root admin 9 Sep 22 23:58 /Library/Frameworks/ Python.framework/Versions/Current/bin/python -> python2.5 running the script python mine.py arguments Traceback (most recent call last): File "mine.py", line 8, in from CoreGraphics import * ImportError: No module named CoreGraphics If I use python2.3 mine.py arguments it works as expected. which python2.3 /usr/bin/python2.3 Is there a way to use CoreGraphics with python 2.5? Do I need to install more? Link libraries? From bob at redivi.com Sun Jan 7 19:47:39 2007 From: bob at redivi.com (Bob Ippolito) Date: Sun, 7 Jan 2007 10:47:39 -0800 Subject: [Pythonmac-SIG] Question on Python 2.5 and CoreGraphics In-Reply-To: <4EAB8EF6-F8A7-4461-BC32-2F18F1F3A540@houston.rr.com> References: <4EAB8EF6-F8A7-4461-BC32-2F18F1F3A540@houston.rr.com> Message-ID: <6a36e7290701071047k17f9566drcde81ab4eb200d02@mail.gmail.com> On 1/7/07, Robert Love wrote: > Back in 2005 I had a python script that did some simple image > manipulation with CoreGraphics. Since then I have upgraded to python > 2.5 and the script no longer works. I think you all tried to > explain this to me when I upgraded but didn't follow what was being > said. CoreGraphics is a proprietary extension distributed (only) by Apple. Source is not available, and it can not be used with any distribution of Python except the one that ships with Mac OS X. -bob From delza at livingcode.org Sun Jan 7 20:04:11 2007 From: delza at livingcode.org (Dethe Elza) Date: Sun, 7 Jan 2007 11:04:11 -0800 Subject: [Pythonmac-SIG] Question on Python 2.5 and CoreGraphics In-Reply-To: <4EAB8EF6-F8A7-4461-BC32-2F18F1F3A540@houston.rr.com> References: <4EAB8EF6-F8A7-4461-BC32-2F18F1F3A540@houston.rr.com> Message-ID: <94961DFD-5AA9-48D5-928D-ADB0505B86A1@livingcode.org> CoreGraphics wrapped by Apple using the built-in Python (Python 2.3 in Tiger). The binding itself is binary and proprietary, so it can only be used with the built-in Python. NodeBox, which appears to be a clone of DrawBot (which was inspired by Processing, etc.) has a library for CoreImage. Robert Kern wrote a wrapper for CoreGraphics which is part of Kiva (http://code.enthought.com/kiva/). He split it off as a standalone package, but the URL I have for that no longer works (problems at Starship Python). I have a copy of an early version (version 0.0.0) which I can send you if you like. I believe it uses Pyrex to build the extension. HTH --Dethe On 7-Jan-07, at 10:39 AM, Robert Love wrote: > Back in 2005 I had a python script that did some simple image > manipulation with CoreGraphics. Since then I have upgraded to python > 2.5 and the script no longer works. I think you all tried to > explain this to me when I upgraded but didn't follow what was being > said. > > I'm running a PPC machine with 10.4. > > which python > /Library/Frameworks/Python.framework/Versions/Current/bin/python > > and > > ls -l /Library/Frameworks/Python.framework/Versions/Current/bin/ > python > lrwxr-xr-x 1 root admin 9 Sep 22 23:58 /Library/Frameworks/ > Python.framework/Versions/Current/bin/python -> python2.5 > > running the script > > python mine.py arguments > Traceback (most recent call last): > File "mine.py", line 8, in > from CoreGraphics import * > ImportError: No module named CoreGraphics > > If I use > > python2.3 mine.py arguments > > it works as expected. > > which python2.3 > /usr/bin/python2.3 > > > Is there a way to use CoreGraphics with python 2.5? Do I need to > install more? Link libraries? > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig "There's a little bit of God in every truck driver and a little bit of truck driver in every God." -- Blayne Horner From daniel at brightfire.com Sun Jan 7 05:19:46 2007 From: daniel at brightfire.com (Daniel Lord) Date: Sat, 6 Jan 2007 20:19:46 -0800 Subject: [Pythonmac-SIG] gmpy update: gmp tests all pass, failure on 14 gmpy tests Message-ID: I need some guidance here. On first blush it doesn't make sense that the gmp checks pass but 14 gmpy tests fail. Is that a problem with the API adaptation or a case of the gmp test not covering all functionality (not likely in my view) gmp is properly installed as a universal static binary and 'make check' passes completely. But gmpy fails 14 tests: ********************************************************************** 4 items had failures: 2 of 4 in gmpy_test_cvr 1 of 48 in gmpy_test_mpf.__test__.elemop 4 of 12 in gmpy_test_mpq.__test__.newdiv 7 of 25 in gmpy_test_rnd.__test__.rand 1072 tests in 34 items. 1058 passed and 14 failed. ***Test Failed*** 14 failures. I don't know enough about gmpy to venture a guess as to why. If anybody has any ideas, let me know.otherwise I'll shelve it until I get some more time to dig more deeply. From ronaldoussoren at mac.com Tue Jan 9 09:45:03 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 9 Jan 2007 09:45:03 +0100 Subject: [Pythonmac-SIG] gmpy universal build (static)? In-Reply-To: <02275A1D-1099-4FAE-AD8D-B1CC5CEBD5D4@mac.com> References: <17815.20896.33046.900341@montanaro.dyndns.org> <459D9646.8040600@noaa.gov> <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> <02275A1D-1099-4FAE-AD8D-B1CC5CEBD5D4@mac.com> Message-ID: On 7 Jan, 2007, at 0:42, Daniel Lord wrote: > > Then I'll package it up for distribution. If you do that please also post patches and/or instructions on how to build the software. I don't want a second pyOpenGL: there is a for that package on pythonmac.org but nobody has a clue about how that was build and getting it to build is more than a quick tweak (that is, I haven't been able to get it to work with small tweaks but maybe I've just tweaked the wrong knobs). Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070109/3bf8a386/attachment.bin From daniellord at mac.com Tue Jan 9 12:04:25 2007 From: daniellord at mac.com (Daniel Lord) Date: Tue, 9 Jan 2007 03:04:25 -0800 Subject: [Pythonmac-SIG] gmpy universal build (static)? In-Reply-To: References: <17815.20896.33046.900341@montanaro.dyndns.org> <459D9646.8040600@noaa.gov> <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> <02275A1D-1099-4FAE-AD8D-B1CC5CEBD5D4@mac.com> Message-ID: Ronald, Yes I will. You raise a very good point about reproducibility. I'll build a binary distro for those who want to keep it simple. But I will also include an archive containing instruction, shell scripts, env vars, and steps required to 'curl' the source and build it from scratch. It requires just a bit of tweaking the CFLAGS and LDFLAGS ( for gmp) and a one-line patch for the gmpy distro in cvs (1.02) That would be an ideal things to also put in the Wiki were it not in such sorry state. I'd like to help with the Wiki, but I don't have the requisite time to learn is admin nor do the content justice right now. Daniel On Jan 9, 2007, at 0:45, Ronald Oussoren wrote: > > On 7 Jan, 2007, at 0:42, Daniel Lord wrote: > >> >> Then I'll package it up for distribution. > > If you do that please also post patches and/or instructions on how > to build the software. > > I don't want a second pyOpenGL: there is a for that package on > pythonmac.org but nobody has a clue about how that was build and > getting it to build is more than a quick tweak (that is, I haven't > been able to get it to work with small tweaks but maybe I've just > tweaked the wrong knobs). > > Ronald From ronaldoussoren at mac.com Tue Jan 9 12:32:11 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 9 Jan 2007 12:32:11 +0100 Subject: [Pythonmac-SIG] gmpy universal build (static)? In-Reply-To: References: <17815.20896.33046.900341@montanaro.dyndns.org> <459D9646.8040600@noaa.gov> <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> <02275A1D-1099-4FAE-AD8D-B1CC5CEBD5D4@mac.com> Message-ID: On 9 Jan, 2007, at 12:04, Daniel Lord wrote: > Ronald, > Yes I will. You raise a very good point about reproducibility. > I'll build a binary distro for those who want to keep it simple. > But I will also include an archive containing instruction, shell > scripts, env vars, and steps required to 'curl' the source and > build it from scratch. IMHO this is the more important one for software that doesn't build out of the box, binary packages are nice to have but it should be possible to rebuild those without reinventing the wheel every time. What I'd like to see is a collection of binary packages that are created from a set of recipies (somewhat like what DarwinPorts does, but without sucking in a second installation of unix). That way it should be possible to (mostly) automaticly rebuild the binary packages when new versions of software are released, and when a new version of Python is released. In an ideal world we'd have the same set of software available for python 2.4, python 2.5 and Apple's python installation. The only way to get there is by using a toolset that does most of the work, manually building software and checking that everything still works is too much work. > It requires just a bit of tweaking the CFLAGS and LDFLAGS ( for > gmp) and a one-line patch for the gmpy distro in cvs (1.02) > > That would be an ideal things to also put in the Wiki were it not > in such sorry state. > I'd like to help with the Wiki, but I don't have the requisite time > to learn is admin nor do the content justice right now. Somewhere on the web should be good enough, Google should be able to find it then :-) Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070109/86df4bb8/attachment.bin From daniellord at mac.com Tue Jan 9 13:12:09 2007 From: daniellord at mac.com (Daniel Lord) Date: Tue, 9 Jan 2007 04:12:09 -0800 Subject: [Pythonmac-SIG] gmpy universal build (static)? In-Reply-To: References: <17815.20896.33046.900341@montanaro.dyndns.org> <459D9646.8040600@noaa.gov> <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> <02275A1D-1099-4FAE-AD8D-B1CC5CEBD5D4@mac.com> Message-ID: > IMHO this is the more important one for software that doesn't build > out of the box, binary packages are nice to have but it should be > possible to rebuild those without reinventing the wheel every time. > > What I'd like to see is a collection of binary packages that are > created from a set of recipies (somewhat like what DarwinPorts > does, but without sucking in a second installation of unix). That > way it should be possible to (mostly) automaticly rebuild the > binary packages when new versions of software are released, and > when a new version of Python is released. > > In an ideal world we'd have the same set of software available for > python 2.4, python 2.5 and Apple's python installation. The only > way to get there is by using a toolset that does most of the work, > manually building software and checking that everything still works > is too much work. I use shell scripts to do such things even though there are far better tools. I like it because the shell is: ubiquitous, doesn't require special tools or configs, is easy to comprehend, and is easy to modify when things (as they always do) break as versions change. It would be nice to have a set of tools like Fink does, only made for building software in place. > Somewhere on the web should be good enough, Google should be able > to find it then :-) I have a .Mac home page I _never_ really use. Sound like a project to go into the queue. That reminds me, I need to do this for my universal PIL build for 2.4 as well lest the formula become lost in antiquity ;-) On Jan 9, 2007, at 3:32, Ronald Oussoren wrote: > > On 9 Jan, 2007, at 12:04, Daniel Lord wrote: > >> Ronald, >> Yes I will. You raise a very good point about reproducibility. >> I'll build a binary distro for those who want to keep it simple. >> But I will also include an archive containing instruction, shell >> scripts, env vars, and steps required to 'curl' the source and >> build it from scratch. > > IMHO this is the more important one for software that doesn't build > out of the box, binary packages are nice to have but it should be > possible to rebuild those without reinventing the wheel every time. > > What I'd like to see is a collection of binary packages that are > created from a set of recipies (somewhat like what DarwinPorts > does, but without sucking in a second installation of unix). That > way it should be possible to (mostly) automaticly rebuild the > binary packages when new versions of software are released, and > when a new version of Python is released. > > In an ideal world we'd have the same set of software available for > python 2.4, python 2.5 and Apple's python installation. The only > way to get there is by using a toolset that does most of the work, > manually building software and checking that everything still works > is too much work. > >> It requires just a bit of tweaking the CFLAGS and LDFLAGS ( for >> gmp) and a one-line patch for the gmpy distro in cvs (1.02) >> >> That would be an ideal things to also put in the Wiki were it not >> in such sorry state. >> I'd like to help with the Wiki, but I don't have the requisite >> time to learn is admin nor do the content justice right now. > > Somewhere on the web should be good enough, Google should be able > to find it then :-) > > Ronald From rowen at cesmail.net Wed Jan 10 19:16:37 2007 From: rowen at cesmail.net (Russell E Owen) Date: Wed, 10 Jan 2007 10:16:37 -0800 Subject: [Pythonmac-SIG] gmpy universal build (static)? References: <17815.20896.33046.900341@montanaro.dyndns.org> <459D9646.8040600@noaa.gov> <6a36e7290701041721p7a694aa4nac91f3331db8441a@mail.gmail.com> <02275A1D-1099-4FAE-AD8D-B1CC5CEBD5D4@mac.com> Message-ID: In article , Ronald Oussoren wrote: > What I'd like to see is a collection of binary packages that are > created from a set of recipies (somewhat like what DarwinPorts does, > but without sucking in a second installation of unix). That way it > should be possible to (mostly) automaticly rebuild the binary > packages when new versions of software are released, and when a new > version of Python is released. I agree. I'd be nice to have a recipe for any packages on pythonmac.org that aren't trivial to build. (Ditto for eggs, I suppose; I've not yet tried to learn how to make eggs -- binary or otherwise. Any good basic tutorials around?) > In an ideal world we'd have the same set of software available for > python 2.4, python 2.5 and Apple's python installation. The only way > to get there is by using a toolset that does most of the work, > manually building software and checking that everything still works > is too much work. That sounds wonderful -- publish a script instead of a description of what to do. But even a recipe is much better than nothing. And to that effect...I am willing to serve recipes for building Mac versions of python-related software (I already serve a few). But we're talking basic here, no wiki, no database, each recipe is a page, with one table of contents page, you send me an update when you want to fix or improve something. -- Russell From kranki at mac.com Wed Jan 10 19:56:27 2007 From: kranki at mac.com (bob) Date: Wed, 10 Jan 2007 13:56:27 -0500 Subject: [Pythonmac-SIG] gmpy universal build (static)? Message-ID: I like most do not like all that DarwinPorts and Fink bring in when you install them. So, I have been developing my own scripts as well. Currently, I use a model for the script based on the actions that DarwinPorts does when it installs packages, but using bash scripts rather than tcl which I never really liked. You may view some of them at http://idisk.mac.com/kranki-Public if you are interested. mkLibexpat.sh is my primary script where I develop new features and then push them back into the other scripts. I have not tried to make any of them universal installations nor have I added binary installs, currently just source installs. I own 7 macs of varying types and running these scripts has really not been much of a burden. Besides, I just didn't feel that I wanted them taking up twice as much harddrive space, but I am not opposed to adding that ability to them if needed. They were written by me and have not had any sort of review by others which I would like. So, even if you do not want to use them, but review them, I would appreciate the feedback. I am going to use them whether anyone else does or not until I find something better. Anyway, they are not copyrighted because they are not that important. However, I do believe that it is important to provide the build scripts being used to create the binaries that are being distributed and to distribute them with the binaries. They provide an educational benefit as well as a potential source of improvements if made available. I would be willing to provide some time to help in creating and maintaining them in collaboration with others. Just let me know. From david.warde.farley at utoronto.ca Thu Jan 11 17:32:59 2007 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Thu, 11 Jan 2007 11:32:59 -0500 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? Message-ID: When I compile Numpy & Scipy from source (on a G5 running 10.4.8) I run into these sorts of snags: >>> from scipy import sparse Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/scipy/sparse/__init__.py", line 5, in ? from sparse import * File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/scipy/sparse/sparse.py", line 12, in ? import sparsetools ImportError: Failure linking new module: /Library/Frameworks/ Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/ sparse/sparsetools.so: Symbol not found: _fprintf$LDBLStub Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages/scipy/sparse/sparsetools.so Expected in: dynamic lookup Originally there were problems with libg2c.a and such, solved by putting symlinks in /usr/local/lib to those libraries as offered by the HPC g77 distribution. I can't seem to figure out how to get around this, nor can I find a binary distribution of scipy. Any help? Dave From david.warde.farley at utoronto.ca Thu Jan 11 17:48:14 2007 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Thu, 11 Jan 2007 11:48:14 -0500 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: References: Message-ID: I should point out that I just installed the distributed fat binaries after installing the absolute latest Universal Python, and I still get this error. dwf at morrislab:/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages$ python Python 2.4.4 (#1, Oct 18 2006, 10:34:39) [GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> from scipy import sparse Traceback (most recent call last): File "", line 1, in ? File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/scipy/sparse/__init__.py", line 5, in ? from sparse import * File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/site-packages/scipy/sparse/sparse.py", line 12, in ? import sparsetools ImportError: Failure linking new module: scipy/sparse/sparsetools.so: Symbol not found: _fprintf$LDBLStub Referenced from: scipy/sparse/sparsetools.so Expected in: dynamic lookup On 11-Jan-07, at 11:32 AM, David Warde-Farley wrote: > When I compile Numpy & Scipy from source (on a G5 running 10.4.8) I > run into these sorts of snags: > > >>> from scipy import sparse > Traceback (most recent call last): > File "", line 1, in ? > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/scipy/sparse/__init__.py", line 5, in ? > from sparse import * > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/scipy/sparse/sparse.py", line 12, in ? > import sparsetools > ImportError: Failure linking new module: /Library/Frameworks/ > Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/ > sparse/sparsetools.so: Symbol not found: _fprintf$LDBLStub > Referenced from: /Library/Frameworks/Python.framework/Versions/ > 2.4/lib/python2.4/site-packages/scipy/sparse/sparsetools.so > Expected in: dynamic lookup > > Originally there were problems with libg2c.a and such, solved by > putting symlinks in /usr/local/lib to those libraries as offered by > the HPC g77 distribution. I can't seem to figure out how to get > around this, nor can I find a binary distribution of scipy. Any help? > > Dave From robert.kern at gmail.com Thu Jan 11 18:13:24 2007 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 11 Jan 2007 11:13:24 -0600 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: References: Message-ID: David Warde-Farley wrote: > When I compile Numpy & Scipy from source (on a G5 running 10.4.8) I > run into these sorts of snags: > > >>> from scipy import sparse > Traceback (most recent call last): > File "", line 1, in ? > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/scipy/sparse/__init__.py", line 5, in ? > from sparse import * > File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ > python2.4/site-packages/scipy/sparse/sparse.py", line 12, in ? > import sparsetools > ImportError: Failure linking new module: /Library/Frameworks/ > Python.framework/Versions/2.4/lib/python2.4/site-packages/scipy/ > sparse/sparsetools.so: Symbol not found: _fprintf$LDBLStub > Referenced from: /Library/Frameworks/Python.framework/Versions/2.4/ > lib/python2.4/site-packages/scipy/sparse/sparsetools.so > Expected in: dynamic lookup > > Originally there were problems with libg2c.a and such, solved by > putting symlinks in /usr/local/lib to those libraries as offered by > the HPC g77 distribution. I can't seem to figure out how to get > around this, nor can I find a binary distribution of scipy. Any help? With Universal Python 2.4, you need to be using gcc 4 and gfortran. Please see the instructions that I wrote here: http://projects.scipy.org/pipermail/numpy-discussion/2007-January/025368.html If that doesn't solve the problem, try adding -lSystemStubs to the build_ext command: $ python setup.py build_src build_clib --fcompiler=gnu95 build_ext -lSystemStubs --fcompiler=gnu95 build -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From david.warde.farley at utoronto.ca Thu Jan 11 18:38:08 2007 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Thu, 11 Jan 2007 12:38:08 -0500 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: References: Message-ID: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> On 11-Jan-07, at 12:13 PM, Robert Kern wrote: > With Universal Python 2.4, you need to be using gcc 4 and gfortran. > Please see > the instructions that I wrote here: > > http://projects.scipy.org/pipermail/numpy-discussion/2007-January/ > 025368.html > > If that doesn't solve the problem, try adding -lSystemStubs to the > build_ext > command: > > $ python setup.py build_src build_clib --fcompiler=gnu95 build_ext > -lSystemStubs --fcompiler=gnu95 build Hot dog! Yeah, I actually figured that out just after I sent the last e-mail. I think that it wasn't working because the HPC g77 build is 3.x series gcc and the scipy binaries up on pythonmac are built against a 4.x series gcc. The gfortran binaries available from http://gcc.gnu.org/wiki/GFortranBinariesMacOS did the trick (gcc_select'ed to 4.0). Now the only problem is that 3 of the Scipy tests fail, but they all seem to involve complex numbers, which I don't really need. I think this means that the Universal scipy binaries offered on pythonmac.org are quite broken. Thanks for the quick response Robert. Dave From Chris.Barker at noaa.gov Thu Jan 11 23:21:19 2007 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 11 Jan 2007 14:21:19 -0800 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> Message-ID: <45A6B85F.2020505@noaa.gov> David Warde-Farley wrote: > I think this means that the Universal scipy binaries offered on > pythonmac.org are quite broken. Yes, they are -- or at least very limited. Is it that hard to make a binary to put up (OK, two - one for PPC, one for Intel), once you've gotten it all built? At least a few people have gotten it going recently. Could someone please make them available? I understand one of the issue is that you need gfortran libs in /usr/local/... and perhaps some other stuff scattered about. Ideally, we'd figure out a way to move all these under the Python tree, but in the meantime, if you can't take all that and put in in one .mpkg, maybe a tarball would do -- something that people could just unpack and get a working system. By the way, my idea of a working system is: python 2.5 (I'm still on 2.4, but if someone is putting effort in, they might as well do the latest) latest numpy latest matplotlib latest wxPython All working together! This really makes OS-X look bad a platform. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bthom at cs.hmc.edu Fri Jan 12 02:12:37 2007 From: bthom at cs.hmc.edu (belinda thom) Date: Thu, 11 Jan 2007 17:12:37 -0800 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: <45A6B85F.2020505@noaa.gov> References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> Message-ID: On Jan 11, 2007, at 2:21 PM, Christopher Barker wrote: > > By the way, my idea of a working system is: > > python 2.5 (I'm still on 2.4, but if someone is putting effort in, > they > might as well do the latest) > > latest numpy > latest matplotlib > latest wxPython > > All working together! A dream come true! :-) > > This really makes OS-X look bad a platform. > > -Chris From njriley at uiuc.edu Fri Jan 12 02:21:27 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 11 Jan 2007 19:21:27 -0600 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: <45A6B85F.2020505@noaa.gov> References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> Message-ID: <20070112012127.GA95465@uiuc.edu> On Thu, Jan 11, 2007 at 02:21:19PM -0800, Christopher Barker wrote: > Is it that hard to make a binary to put up (OK, two - one for PPC, one > for Intel), once you've gotten it all built? At least a few people have > gotten it going recently. Could someone please make them available? How about posting them on your own Web site then? If you don't have one, the price of commodity Web hosting is virtually zero, and there are plenty of free open source project hosting services around, some of them even good. It's been repeatedly stated on this mailing list that the currently pythonmac.org maintainer doesn't have time, and would be happy to relinquish control to someone who did. But nobody's volunteered. It is really rather tiresome to read about people asking for "someone" to do something when everyone's doing this work for free. -- Nicholas Riley | From bob at redivi.com Fri Jan 12 02:29:39 2007 From: bob at redivi.com (Bob Ippolito) Date: Thu, 11 Jan 2007 17:29:39 -0800 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: <20070112012127.GA95465@uiuc.edu> References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> Message-ID: <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> On 1/11/07, Nicholas Riley wrote: > On Thu, Jan 11, 2007 at 02:21:19PM -0800, Christopher Barker wrote: > > Is it that hard to make a binary to put up (OK, two - one for PPC, one > > for Intel), once you've gotten it all built? At least a few people have > > gotten it going recently. Could someone please make them available? > > How about posting them on your own Web site then? If you don't have > one, the price of commodity Web hosting is virtually zero, and there > are plenty of free open source project hosting services around, some > of them even good. > > It's been repeatedly stated on this mailing list that the currently > pythonmac.org maintainer doesn't have time, and would be happy to > relinquish control to someone who did. But nobody's volunteered. > > It is really rather tiresome to read about people asking for "someone" > to do something when everyone's doing this work for free. > Well I'm back in the country now and I just got my mbp back from applecare today... so if "someone" sends me updated binaries I'll gladly sync them to pythonmac.org. -bob From njriley at uiuc.edu Fri Jan 12 02:33:57 2007 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 11 Jan 2007 19:33:57 -0600 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: <20070112012127.GA95465@uiuc.edu> References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> Message-ID: <20070112013357.GB95465@uiuc.edu> On Thu, Jan 11, 2007 at 07:21:27PM -0600, Nicholas Riley wrote: > It is really rather tiresome to read about people asking for "someone" > to do something when everyone's doing this work for free. I apologize for this message - I misread and overreacted. There's a dictum about counting to 3 before you send an angry email, and I don't think I made it to 1. :-/ -- Nicholas Riley | From david.warde.farley at utoronto.ca Fri Jan 12 02:38:43 2007 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Thu, 11 Jan 2007 20:38:43 -0500 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> Message-ID: On 11-Jan-07, at 8:29 PM, Bob Ippolito wrote: > Well I'm back in the country now and I just got my mbp back from > applecare today... so if "someone" sends me updated binaries I'll > gladly sync them to pythonmac.org. I would do it but again, I'm not sure my binaries are "good" i.e. completely universal, I get a number of "can't figure out architecture" warnings for stuff when I build numpy, nor am I really sure how to do all of that .mpkg packaging stuff (much less in a way that alerts users of the gfortran dependency of SciPy). That and I'm still not sure my NumPy/SciPy are linking properly against Apple's veclib for fast linear algebra goodness. scipy.test() tells me that the module cblas is empty, and that it's using fblas. Dave From robert.kern at gmail.com Fri Jan 12 05:18:30 2007 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 11 Jan 2007 22:18:30 -0600 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> Message-ID: David Warde-Farley wrote: > On 11-Jan-07, at 8:29 PM, Bob Ippolito wrote: > >> Well I'm back in the country now and I just got my mbp back from >> applecare today... so if "someone" sends me updated binaries I'll >> gladly sync them to pythonmac.org. > > I would do it but again, I'm not sure my binaries are "good" i.e. > completely universal, I get a number of "can't figure out > architecture" warnings for stuff when I build numpy, nor am I really > sure how to do all of that .mpkg packaging stuff (much less in a way > that alerts users of the gfortran dependency of SciPy). Yes, this is a problem. The builds of numpy and scipy are not Universal. I don't see a reason why numpy *shouldn't* be, but distutils thinks it isn't, so it isn't. scipy *can't* be Universal until gfortran grows that capability. > That and I'm still not sure my NumPy/SciPy are linking properly > against Apple's veclib for fast linear algebra goodness. scipy.test() > tells me that the module cblas is empty, and that it's using fblas. Well, it's linking just fine, but vecLib removed the ATLAS version information that the scipy build system uses to determine whether or not to build the wrappers for the C versions of the BLAS subroutines that ATLAS and vecLib provide. And the C versions of LAPACK subroutines are simply missing. Neither are necessary, though, just nice to have. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From david.warde.farley at utoronto.ca Fri Jan 12 05:30:29 2007 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Thu, 11 Jan 2007 23:30:29 -0500 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> Message-ID: <42271D15-A951-49A3-809D-44D854BFC438@utoronto.ca> On 11-Jan-07, at 11:18 PM, Robert Kern wrote: > Well, it's linking just fine, but vecLib removed the ATLAS version > information > that the scipy build system uses to determine whether or not to > build the > wrappers for the C versions of the BLAS subroutines that ATLAS and > vecLib > provide. And the C versions of LAPACK subroutines are simply missing. > > Neither are necessary, though, just nice to have. Eh, am I missing something or aren't the C versions of the BLAS subroutines a good bit faster? Can/does gfortran take advance of AltiVec/vecLib? I'm working with software that needs to be as fast as possible (since the output is being served over the web) and I'm hoping to squeeze the best numerical performance out that I can. Dave From robert.kern at gmail.com Fri Jan 12 05:39:40 2007 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 11 Jan 2007 22:39:40 -0600 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: <42271D15-A951-49A3-809D-44D854BFC438@utoronto.ca> References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> <42271D15-A951-49A3-809D-44D854BFC438@utoronto.ca> Message-ID: David Warde-Farley wrote: > On 11-Jan-07, at 11:18 PM, Robert Kern wrote: > >> Well, it's linking just fine, but vecLib removed the ATLAS version >> information >> that the scipy build system uses to determine whether or not to >> build the >> wrappers for the C versions of the BLAS subroutines that ATLAS and >> vecLib >> provide. And the C versions of LAPACK subroutines are simply missing. >> >> Neither are necessary, though, just nice to have. > > Eh, am I missing something or aren't the C versions of the BLAS > subroutines a good bit faster? Okay, let me clarify. ATLAS is implemented entirely in C. vecLib is a slightly modified version of ATLAS. ATLAS provides both the standard BLAS interface which uses the FORTRAN calling conventions in terms of the names of symbols and column-major arrays. It also provides versions which uses C calling conventions and row-major arrays. The latter is what I am referring to when I say "C versions of the BLAS subroutines." If you only have "the FORTRAN versions of the subroutines," then you will incur the cost of copying the numpy arrays (row major) to the column major format. While that may not be negligible, it's not huge, either. > Can/does gfortran take advance of > AltiVec/vecLib? Yup. -framework Accelerate -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From Teemu.Rinne at helsinki.fi Fri Jan 12 10:00:22 2007 From: Teemu.Rinne at helsinki.fi (Teemu Rinne) Date: Fri, 12 Jan 2007 11:00:22 +0200 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> Message-ID: Hi, >From my perspective (very limited skills&resources for understanding python details, backends, compiling sources and such scary things), I would like to add to the archives my success story using pythonmac.org/packages. Context: Mac Pro (intel) and several G5s (will try my G4 powerbook soon) python 2.4, numpy, matplotlib (basic plotting with TkAgg), scipy (filtering)[, rpy (interface to R)] Installing python2.4, numpy, and matplotlib from pythonmac packages was a pleasure. Thank you! I found that the current scipy package is outdated (error message something like:?RuntimeError: module compiled against ?version XXXXXX of C-API but this version of numpy is YYYYYY )?but, fortunately, it was quite easy? to compile scipy from sources after I had installed the other binary packages. I started the process from scratch on clean systems (reinstalled tiger on old systems).? This is what I did: -installed the latest XCode tools+SDK -installed pythonmac.org/packages (not scipy) -installed fortran? from?http://www.macresearch.org/files/gfortran/gfortranCompleteInstaller.mpkg.zip?(I added a link to /usr/bin/gfortran pointing?to /usr/local/bin/gfortran ) -added ~/.pydistutils.cfg (as explained in?pythonmac.org/wiki/FAQ)? -downloaded scipy sources (www.scipy.org, 0.5.2) and compiled&installed scipy using sudo?/usr/local/bin/python setup.py install (i.e., using python 2.4 installed from pythonmac packages) This works ok for the things I want to do. Scipy.test(10) (Ran 1610 tests in 40.736s) complains about several things (e.g., importing umfpack, clapack, cblas, complex numbers) but this does not seem to matter. I don't know about wxPython. I would be more than happy to contribute to pythonmac packages. But I would have to solve these issues: (1) Is my scipy build (Intel, G5) ok for general distribution? I have no idea. (2) How to make pythonmac packages. This seems like a faq but seems that finding relevant information requires some time&effort as there seems to be several different packaging approaches etc. It would be great to have step-by-step instructions to get started. Cheers, Teemu Rinne Dept Psychology Univ Helsinki, Finland From Chris.Barker at noaa.gov Fri Jan 12 18:12:36 2007 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 12 Jan 2007 09:12:36 -0800 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> <42271D15-A951-49A3-809D-44D854BFC438@utoronto.ca> Message-ID: <45A7C184.5020402@noaa.gov> Robert Kern wrote: > Yup. -framework Accelerate Robert, just so we're clear here. If one does a straight "setup.py build" with numpy 1.0.1, do you get a version that uses Veclib? I do understand that that is the Fortran-compatible version, and thus may result in some extra copying to shift between row and column major ordering. By the way, if one were to take care to use Fortran ordered numpy arrays, would you avoid that copying? On a few other topics in this thread: Nicholas Riley wrote: > How about posting them on your own Web site then? If you don't have > one, the price of commodity Web hosting is virtually zero, Cost is not the issue -- I think the community is far better served if there are a small ( ideally one ) number of places to go for Python modules on OS-X. Ideally, it's possible to keep stuff in sync there too. > It's been repeatedly stated on this mailing list that the currently > pythonmac.org maintainer doesn't have time, and would be happy to > relinquish control to someone who did. But nobody's volunteered. Not quite true. Bob has been out of town recently, and, indeed I have volunteered to put stuff up there, but we've haven't coordinated that yet. Bob -- can you give me permissions to put stuff up myself, or will you be around enough for a while to keep doing it yourself? He has been looking for someone to maintain the Wiki, but I don't think I can do that. > It is really rather tiresome to read about people asking for "someone" > to do something when everyone's doing this work for free. I, for one, have spent quite a bit of time helping people out on this mailing list and others, and have built packages and contributed them to pythonmac as well. As it happens, I haven't needed SciPy recently, so I haven't built it, so I can't contribute it -- I hope to do so soon. However, I'm not sure it's so unreasonable to ask someone that has gotten a great deal of help on lists like this to then take the extra effort to put what they've done up for others. I know I've tried to do that. David Warde-Farley wrote: > I would do it but again, I'm not sure my binaries are "good" OK, this is a key problem. The truth is that we all have different needs, and someone that has gotten numpy/MPL/SciPy all working for them may not have a version that will work for everyone (Universal support, working with TK and Wx, etc.) So there does need to be a bit of testing and coordinating. I hereby volunteer to do that. If someone things they have it all ready to go, let me know, and I'll try to test and make sure that everything fits together. From Robert's messages, I think I have a pretty good idea what's possible. Again, this is what I think we should put up on pythonmac: python 2.5 (I'm still on 2.4, but if someone is putting effort in, they might as well do the latest) latest numpy latest matplotlib latest wxPython All Universal and working together! latest SciPy, built for the numpy above, linked to veclib. One each for PPC and Intel. Are there any other commonly used packages that need to be version compatible with these? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From robert.kern at gmail.com Fri Jan 12 20:49:03 2007 From: robert.kern at gmail.com (Robert Kern) Date: Fri, 12 Jan 2007 13:49:03 -0600 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: <45A7C184.5020402@noaa.gov> References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> <42271D15-A951-49A3-809D-44D854BFC438@utoronto.ca> <45A7C184.5020402@noaa.gov> Message-ID: Christopher Barker wrote: > Robert Kern wrote: >> Yup. -framework Accelerate > > Robert, just so we're clear here. If one does a straight "setup.py > build" with numpy 1.0.1, do you get a version that uses Veclib? I do > understand that that is the Fortran-compatible version, and thus may > result in some extra copying to shift between row and column major > ordering. By the way, if one were to take care to use Fortran ordered > numpy arrays, would you avoid that copying? Yes. Both with numpy and scipy. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco From rowen at cesmail.net Fri Jan 12 21:21:57 2007 From: rowen at cesmail.net (Russell E Owen) Date: Fri, 12 Jan 2007 12:21:57 -0800 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> Message-ID: In article <45A6B85F.2020505 at noaa.gov>, Christopher Barker wrote: >.... > By the way, my idea of a working system is: > > python 2.5 (I'm still on 2.4, but if someone is putting effort in, they > might as well do the latest) > > latest numpy > latest matplotlib > latest wxPython FYI: I plan to build and contribute a new matplotlib using wxPython 2.8 once wxPython 2.8 is available on pythonmac.org. I've been waiting because I felt it would be confusing if for the pythonmac matplotlib to require a wxPython newer than could be found there. Meanwhile I have packages for numpy 1.0.1 (standard build, nothing fancy done to bring in faster libraries) and somewhat updated packages of matplotlib that should be available on pythonmac soon, and until then you can get them here: Regards, -- Russell From kw at codebykevin.com Fri Jan 12 22:00:55 2007 From: kw at codebykevin.com (Kevin Walzer) Date: Fri, 12 Jan 2007 16:00:55 -0500 Subject: [Pythonmac-SIG] PyObjc learning curve from Tkinter background? Message-ID: <45A7F707.3030008@codebykevin.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've released a Tkinter application, tweaked a lot to fit in better with the Aqua HIG, and I'm reasonably pleased with the results. Looking my next project, though, I'm concerned about Tk's limitations (lack of native drag-and-drop support on OS X, inability to read Mac icons, etc.), and I'm not sure I want to spend months learning C to extend Tk at that level. So I'm thinking about PyObjC, mainly because it seems to offer better Mac-native hooks. I'm wondering, though, about the learning curve. Does anyone have experience coming to PyOjbC from a Tkinter background, and if so, can you comment on the experience of learning PyObjC? I'm not a complete newbie to Cocoa development--I've done some work with Cocoa via AppleScript Studio--and I'm now reasonably comfortable with object-oriented programming, after finding that Tkinter applications work much better with classes than with pure procedural programming (the standard for Tcl, the language in which I have the most experience). But the hurdles still look pretty high right now, in terms of the frameworks and grokking ObjC syntax, even without worrying about memory management. Any advice is appreciated. - -- Kevin Walzer Code by Kevin http://www.codebykevin.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFp/cGEsLm8HXyq4sRAgzDAJ9lIIKjexlLkIeUmEIVfwRj3Ltf0wCfaAFv GttmNn8Ipo3Qu/0ELlWFRBQ= =nU3E -----END PGP SIGNATURE----- From delza at livingcode.org Fri Jan 12 22:15:18 2007 From: delza at livingcode.org (Dethe Elza) Date: Fri, 12 Jan 2007 13:15:18 -0800 Subject: [Pythonmac-SIG] PyObjc learning curve from Tkinter background? In-Reply-To: <45A7F707.3030008@codebykevin.com> References: <45A7F707.3030008@codebykevin.com> Message-ID: Hi Kevin, PyObjC has its share of hurdles, but there are some good resources to get you started. First, there are example programs in the PyObjC distro which can make good starting points. Second, the mapping from Objective-C to Python is very straightforward (see the PyObjC tutorial), which makes it easy to use existing Cocoa documentation. Third, there is a very good reference for Cocoa: AppKiDo (http:// homepage.mac.com/aglee/downloads/). My sporadic blog may also be helpful, with several examples of PyObjC projects. Finally, when I've gotten stuck in some aspect of PyObjC, the developer's list has been very helpful (https://lists.sourceforge.net/ lists/listinfo/pyobjc-dev). HTH --Dethe What dark passions and ancient evils have been held in check by the grim totalitarianism of the profit motive? --Bruce Sterling From cookedm at physics.mcmaster.ca Sat Jan 13 23:39:25 2007 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Sat, 13 Jan 2007 14:39:25 -0800 Subject: [Pythonmac-SIG] Compiling Scipy/available binaries for Universal Python 2.4? In-Reply-To: References: <5E930FB0-DBD4-4683-A94C-E226A6F379DE@utoronto.ca> <45A6B85F.2020505@noaa.gov> <20070112012127.GA95465@uiuc.edu> <6a36e7290701111729i687bd322g9d3cc80ed5f9933a@mail.gmail.com> <42271D15-A951-49A3-809D-44D854BFC438@utoronto.ca> <45A7C184.5020402@noaa.gov> Message-ID: <7ECD2041-CFD3-48C2-812E-2E6B097A61AE@physics.mcmaster.ca> On Jan 12, 2007, at 11:49 , Robert Kern wrote: > Christopher Barker wrote: >> Robert Kern wrote: >>> Yup. -framework Accelerate >> >> Robert, just so we're clear here. If one does a straight "setup.py >> build" with numpy 1.0.1, do you get a version that uses Veclib? I do >> understand that that is the Fortran-compatible version, and thus may >> result in some extra copying to shift between row and column major >> ordering. By the way, if one were to take care to use Fortran ordered >> numpy arrays, would you avoid that copying? > > Yes. Both with numpy and scipy. As long as your arrays are contiguous, it won't matter whether they are C-ordered or Fortran-ordered. Pretty much every BLAS routine takes an argument that says whether to use the array as-is, or the transpose (or the Hermitian conjugate in the case of complex arrays). That's how the C wrappers of Fortran BLAS routines work. The tranpose of a Fortran-ordered array is the original array as C-ordered. For instance, in Fortran to calculate AB=C, you'd do something like DGEMM('N','N',A,B), and to caculate A^T B, something like DGEMM ('T','N',A,B). In C, if A and B are C-ordered, for AB you'd call the Fortran routine like so: DGEMM('T','T', B, A), which does B^T A^T = C^T, and C will be the C-ordered result of AB. The underlying implementations of the BLAS routines are pretty much always the same for the C interface and the Fortran interface. -- |>|\/|< /------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From ngcc_hk at yahoo.com Sun Jan 14 06:12:27 2007 From: ngcc_hk at yahoo.com (Dennis Ng) Date: Sun, 14 Jan 2007 13:12:27 +0800 Subject: [Pythonmac-SIG] XCode fails to see py2app Message-ID: <4574192B-14C0-4B1C-88F3-131B1B82055A@yahoo.com> Dear all, Following the examples http://developer.apple.com/cocoa/pyobjc.html as well as using PyObjC 1.4 installer for (Universal) Python 2.4 on Mac OS X 10.4 I have got an error message that Xcode cannot find py2app. There is a thread on this topic but there is no answer on how to deal with it. So I raised it again. It seems that it is a common problem to newbie and for newly installed environment. It is noted if one run the source manually i.e. follow the instruction using Xcode, interface builder, drop to terminal and do the python setup.py py2app The program will works but if you compile it under Xcode, it cannot: The details is as below and you may note that somehow Xcode can only points to the Java and nothing Python in the compile environment: Building target ?Development? of project ?PyAverager? with configuration ?Development? ? (1 error) cd / setenv ACTION setenv APPLE_INTERNAL_DEVELOPER_DIR /AppleInternal/Developer setenv APPLE_INTERNAL_DIR /AppleInternal setenv APPLE_INTERNAL_DOCUMENTATION_DIR /AppleInternal/ Documentation setenv APPLE_INTERNAL_LIBRARY_DIR /AppleInternal/Library setenv APPLE_INTERNAL_TOOLS /AppleInternal/Developer/Tools setenv BUILD_COMPONENTS "headers build" setenv BUILD_DIR "/Users/testuser/Desktop/pyObjC - averager/build" setenv BUILD_ROOT "/Users/testuser/Desktop/pyObjC - averager/build" setenv BUILD_STYLE Development setenv BUILD_VARIANTS normal setenv BUILT_PRODUCTS_DIR "/Users/testuser/Desktop/pyObjC - averager/build/Development" setenv CC /usr/bin/cc setenv CLASS_FILE_DIR "/Users/testuser/Desktop/pyObjC - averager/ build/PyAverager.build/Development/Development.build/JavaClasses" setenv CLONE_HEADERS NO setenv CONFIGURATION Development setenv CONFIGURATION_BUILD_DIR "/Users/testuser/Desktop/pyObjC - averager/build/Development" setenv CONFIGURATION_TEMP_DIR "/Users/testuser/Desktop/pyObjC - averager/build/PyAverager.build/Development" setenv COPY_PHASE_STRIP NO setenv DEBUGGING_SYMBOLS YES setenv DERIVED_FILES_DIR setenv DERIVED_FILE_DIR "/Users/testuser/Desktop/pyObjC - averager/build/PyAverager.build/Development/Development.build/ DerivedSources" setenv DERIVED_SOURCES_DIR "/Users/testuser/Desktop/pyObjC - averager/build/PyAverager.build/Development/Development.build/ DerivedSources" setenv DEVELOPMENT_LANGUAGE English setenv DO_HEADER_SCANNING_IN_JAM NO setenv DSTROOT /tmp/PyAverager.dst setenv ENABLE_HEADER_DEPENDENCIES YES setenv FILE_LIST "/Users/testuser/Desktop/pyObjC - averager/ build/PyAverager.build/Development/Development.build/Objects/ LinkFileList" setenv FRAMEWORK_VERSION A setenv GCC3_VERSION 3.3 setenv GROUP testuser setenv HEADERMAP_INCLUDES_FLAT_ENTRIES_FOR_TARGET_BEING_BUILT YES setenv HEADERMAP_INCLUDES_FRAMEWORK_ENTRIES_FOR_ALL_PRODUCT_TYPES YES setenv HEADERMAP_INCLUDES_NONPUBLIC_NONPRIVATE_HEADERS YES setenv HEADERMAP_INCLUDES_PROJECT_HEADERS YES setenv INSTALL_DIR "/tmp/PyAverager.dst/(INSTALL_PATH)" setenv INSTALL_GROUP testuser setenv INSTALL_MODE_FLAG a-w,a+rX setenv INSTALL_OWNER testuser setenv INSTALL_ROOT /tmp/PyAverager.dst setenv JAVA_APP_STUB /System/Library/Frameworks/JavaVM.framework/ Resources/MacOS/JavaApplicationStub setenv JAVA_ARCHIVE_CLASSES YES setenv JAVA_ARCHIVE_TYPE JAR setenv JAVA_COMPILER /usr/bin/javac setenv JAVA_FRAMEWORK_RESOURCES_DIRS Resources setenv JAVA_JAR_FLAGS cv setenv JAVA_SOURCE_SUBDIR . setenv JAVA_USE_DEPENDENCIES YES setenv JAVA_ZIP_FLAGS -urg setenv LOCAL_ADMIN_APPS_DIR /Applications/Utilities setenv LOCAL_APPS_DIR /Applications setenv LOCAL_DEVELOPER_DIR /Library/Developer setenv LOCAL_LIBRARY_DIR /Library setenv NATIVE_ARCH i386 setenv OBJECT_FILE_DIR "/Users/testuser/Desktop/pyObjC - averager/build/PyAverager.build/Development/Development.build/Objects" setenv OBJROOT "/Users/testuser/Desktop/pyObjC - averager/build" setenv OPTIMIZATION_LEVEL 0 setenv OS MACOS setenv PATH_PREFIXES_EXCLUDED_FROM_HEADER_DEPENDENCIES "/usr/ include /usr/local/include /System/Library/Frameworks /System/Library/ PrivateFrameworks /Developer/Headers" setenv PRODUCT_NAME setenv PROFILING_CODE NO setenv PROJECT PyAverager setenv PROJECT_DERIVED_FILE_DIR "/Users/testuser/Desktop/pyObjC - averager/build/PyAverager.build/DerivedSources" setenv PROJECT_DIR "/Users/testuser/Desktop/pyObjC - averager" setenv PROJECT_FILE_PATH "/Users/testuser/Desktop/pyObjC - averager/PyAverager.xcodeproj" setenv PROJECT_NAME PyAverager setenv PROJECT_TEMP_DIR "/Users/testuser/Desktop/pyObjC - averager/build/PyAverager.build" setenv REMOVE_CVS_FROM_RESOURCES YES setenv REMOVE_SVN_FROM_RESOURCES YES setenv SDKROOT setenv SHARED_DERIVED_FILE_DIR "/Users/testuser/Desktop/pyObjC - averager/build/Development/DerivedSources" setenv SOURCE_ROOT "/Users/testuser/Desktop/pyObjC - averager" setenv SRCROOT "/Users/testuser/Desktop/pyObjC - averager" setenv STRIP_INSTALLED_PRODUCT YES setenv SYMROOT "/Users/testuser/Desktop/pyObjC - averager/build" setenv SYSTEM_ADMIN_APPS_DIR /Applications/Utilities setenv SYSTEM_APPS_DIR /Applications setenv SYSTEM_CORE_SERVICES_DIR /System/Library/CoreServices setenv SYSTEM_DEMOS_DIR /Applications/Extras setenv SYSTEM_DEVELOPER_APPS_DIR /Developer/Applications setenv SYSTEM_DEVELOPER_DEMOS_DIR "/Developer/Applications/ Utilities/Built Examples" setenv SYSTEM_DEVELOPER_DIR /Developer setenv SYSTEM_DEVELOPER_DOC_DIR "/Developer/ADC Reference Library" setenv SYSTEM_DEVELOPER_GRAPHICS_TOOLS_DIR "/Developer/ Applications/Graphics Tools" setenv SYSTEM_DEVELOPER_JAVA_TOOLS_DIR "/Developer/Applications/ Java Tools" setenv SYSTEM_DEVELOPER_PERFORMANCE_TOOLS_DIR "/Developer/ Applications/Performance Tools" setenv SYSTEM_DEVELOPER_RELEASENOTES_DIR "/Developer/ADC Reference Library/releasenotes" setenv SYSTEM_DEVELOPER_TOOLS /Developer/Tools setenv SYSTEM_DEVELOPER_TOOLS_DOC_DIR "/Developer/ADC Reference Library/documentation/DeveloperTools" setenv SYSTEM_DEVELOPER_TOOLS_RELEASENOTES_DIR "/Developer/ADC Reference Library/releasenotes/DeveloperTools" setenv SYSTEM_DEVELOPER_UTILITIES_DIR /Developer/Applications/ Utilities setenv SYSTEM_DOCUMENTATION_DIR /Library/Documentation setenv SYSTEM_LIBRARY_DIR /System/Library setenv TARGETNAME Development setenv TARGET_BUILD_DIR "/Users/testuser/Desktop/pyObjC - averager/build/Development" setenv TARGET_NAME Development setenv TARGET_TEMP_DIR "/Users/testuser/Desktop/pyObjC - averager/build/PyAverager.build/Development/Development.build" setenv TEMP_DIR "/Users/testuser/Desktop/pyObjC - averager/build/ PyAverager.build/Development/Development.build" setenv TEMP_FILES_DIR setenv TEMP_FILE_DIR "/Users/testuser/Desktop/pyObjC - averager/ build/PyAverager.build/Development/Development.build" setenv TEMP_ROOT "/Users/testuser/Desktop/pyObjC - averager/build" setenv USER testuser setenv USER_APPS_DIR /Users/testuser/Applications setenv USER_LIBRARY_DIR /Users/testuser/Library setenv XCODE_APP_SUPPORT_DIR "/Library/Application Support/Apple/ Developer Tools" /usr/bin/env /Users/testuser/Desktop/pyObjC\ -\ averager/ setup.py py2app --alias Traceback (most recent call last): File "/Users/testuser/Desktop/pyObjC - averager/setup.py", line 38, in ? import py2app ImportError: No module named py2app ImportError: No module named py2app ImportError: No module named py2app ImportError: No module named py2app ImportError: No module named py2app ImportError: No module named py2app Build failed (1 error) Somehow the py2app cannot be found. My environment is quite common for macbook (Intel) i.e. it has the current version Python in /Library/Frameworks/Python.framework/Versions/2.4/ as well as an older library in /Library/Python/2.3/ but calling python would use the newer library The newly installed PyObjC has this: /Developer/Python/py2app/ /Developer/Python/PyObjC/ The py2app example like TinyTinyEdit run ok under terminal compile method. Somehow the setup script cannot find the two libraries pyobjC installed and seems to use Java environment. Any hint? Best regards. Dennis -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070114/958da091/attachment.html From rowen at cesmail.net Tue Jan 16 22:20:58 2007 From: rowen at cesmail.net (Russell E Owen) Date: Tue, 16 Jan 2007 13:20:58 -0800 Subject: [Pythonmac-SIG] py2app warning: may need to include email.Util Message-ID: My py2app-bundled Mac application recently started failing with "no module named email.Util" when trying to display images. It turns out pyfits uses urllib which uses email.Util, which apparently has been renamed email.util with some kind of clever lazy import code so one can still use email.Util. Apparently the cleverness is too much for py2app's module finder. Anyway, the easy workaround is to specify email.Util as a necessary module to import. But I'll report a python bug or submit a urllib patch. -- Russell From ronaldoussoren at mac.com Tue Jan 16 22:35:08 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 16 Jan 2007 22:35:08 +0100 Subject: [Pythonmac-SIG] py2app warning: may need to include email.Util In-Reply-To: References: Message-ID: <3B940336-83E0-4150-9C0B-544B6BD3F12A@mac.com> On 16 Jan, 2007, at 22:20, Russell E Owen wrote: > My py2app-bundled Mac application recently started failing with "no > module named email.Util" when trying to display images. It turns out > pyfits uses urllib which uses email.Util, which apparently has been > renamed email.util with some kind of clever lazy import code so one > can > still use email.Util. Apparently the cleverness is too much for > py2app's > module finder. The cleverness doesn't use the import statement, which is why py2app doesn't understand this. Py2exe will suffer from the same problem as it uses a simular algorithm. > > Anyway, the easy workaround is to specify email.Util as a necessary > module to import. But I'll report a python bug or submit a urllib > patch. It's unlikely that this will be fixed in Python itself, we'll have to add a recipe to py2app that works around this problem. I don't have time to look at this right now, patches are obviously welcome :-) Ronald P.S. This is an issue with Python >= 2.5 only. > > -- Russell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070116/becbb5fd/attachment.bin From rowen at cesmail.net Wed Jan 17 00:01:38 2007 From: rowen at cesmail.net (Russell E Owen) Date: Tue, 16 Jan 2007 15:01:38 -0800 Subject: [Pythonmac-SIG] py2app warning: may need to include email.Util In-Reply-To: <3B940336-83E0-4150-9C0B-544B6BD3F12A@mac.com> References: <3B940336-83E0-4150-9C0B-544B6BD3F12A@mac.com> Message-ID: At 10:35 PM +0100 1/16/07, Ronald Oussoren wrote: >On 16 Jan, 2007, at 22:20, Russell E Owen wrote: > >>My py2app-bundled Mac application recently started failing with "no >>module named email.Util" when trying to display images. It turns out >>pyfits uses urllib which uses email.Util, which apparently has been >>renamed email.util with some kind of clever lazy import code so one can >>still use email.Util. Apparently the cleverness is too much for py2app's >>module finder. > >The cleverness doesn't use the import statement, which is why py2app >doesn't understand this. Py2exe will suffer from the same problem as >it uses a simular algorithm. > >>Anyway, the easy workaround is to specify email.Util as a necessary >>module to import. But I'll report a python bug or submit a urllib patch. > >It's unlikely that this will be fixed in Python itself, we'll have >to add a recipe to py2app that works around this problem. I don't >have time to look at this right now, patches are obviously welcome >:-) I submitted a patch for python (changing email.Utils->email.utils in urllib, with similar patches for urllib2 and smtplib). But I agree that a recipe for py2app would be very good, since some people will run py2app against 2.5. The following recipe seems to work, but I don't know if it's really the right way to go. It is based on extrapolating from the current recipes. None of them seem to do the same job and I've not found any docs on writing recipes: def check(cmd, mf): m = mf.findNode('email') if m is None or m.filename is None: return None oldNames = [ 'base64MIME', 'Charset', 'Encoders', 'Errors', 'Generator', 'Header', 'Iterators', 'Message', 'MIMEAudio', 'MIMEBase', 'MIMEImage', 'MIMEMessage', 'MIMEMultipart', 'MIMENonMultipart', 'MIMEText', 'Parser', 'quopriMIME', 'Utils', 'message_from_string', 'message_from_file', ] oldModules = ["email." + name for name in oldNames] return dict( modules = oldModules, ) Regards, -- Russell From rowen at u.washington.edu Wed Jan 17 00:21:48 2007 From: rowen at u.washington.edu (Russell E Owen) Date: Tue, 16 Jan 2007 15:21:48 -0800 Subject: [Pythonmac-SIG] py2app warning: may need to include email.Util In-Reply-To: References: <3B940336-83E0-4150-9C0B-544B6BD3F12A@mac.com> Message-ID: At 3:01 PM -0800 1/16/07, Russell E Owen wrote: >The following recipe seems to work, but I don't know if it's really >the right way to go. It is based on extrapolating from the current >recipes. None of them seem to do the same job and I've not found any >docs on writing recipes: > >def check(cmd, mf): > m = mf.findNode('email') > if m is None or m.filename is None: > return None > oldNames = [ > 'base64MIME', > 'Charset', > 'Encoders', > 'Errors', > 'Generator', > 'Header', > 'Iterators', > 'Message', > 'MIMEAudio', > 'MIMEBase', > 'MIMEImage', > 'MIMEMessage', > 'MIMEMultipart', > 'MIMENonMultipart', > 'MIMEText', > 'Parser', > 'quopriMIME', > 'Utils', > 'message_from_string', > 'message_from_file', > ] > oldModules = ["email." + name for name in oldNames] > > return dict( > modules = oldModules, > ) I spoke too soon. I had my patched urllib in place, masking the effect of the recipe. This simple recipe does work and does emulate other recipes: def check(cmd, mf): m = mf.findNode('email') if m is None or m.filename is None: return None return dict( packages = ['email'], ) -- Russell From ronaldoussoren at mac.com Wed Jan 17 21:15:56 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 17 Jan 2007 21:15:56 +0100 Subject: [Pythonmac-SIG] py2app warning: may need to include email.Util In-Reply-To: References: <3B940336-83E0-4150-9C0B-544B6BD3F12A@mac.com> Message-ID: <193FF1E3-014A-4E17-A05F-3E57A42DEDD3@mac.com> On 17 Jan, 2007, at 0:21, Russell E Owen wrote: > At 3:01 PM -0800 1/16/07, Russell E Owen wrote: >> The following recipe seems to work, but I don't know if it's >> really the right way to go. It is based on extrapolating from the >> current recipes. None of them seem to do the same job and I've not >> found any docs on writing recipes: >> >> def check(cmd, mf): >> m = mf.findNode('email') >> if m is None or m.filename is None: >> return None >> oldNames = [ >> 'base64MIME', >> 'Charset', >> 'Encoders', >> 'Errors', >> 'Generator', >> 'Header', >> 'Iterators', >> 'Message', >> 'MIMEAudio', >> 'MIMEBase', >> 'MIMEImage', >> 'MIMEMessage', >> 'MIMEMultipart', >> 'MIMENonMultipart', >> 'MIMEText', >> 'Parser', >> 'quopriMIME', >> 'Utils', >> 'message_from_string', >> 'message_from_file', >> ] >> oldModules = ["email." + name for name in oldNames] >> >> return dict( >> modules = oldModules, >> ) > > I spoke too soon. I had my patched urllib in place, masking the > effect of the recipe. This simple recipe does work and does emulate > other recipes: > > def check(cmd, mf): > m = mf.findNode('email') > if m is None or m.filename is None: > return None > return dict( > packages = ['email'], > ) I've added a recipe that's close to this one. The only difference is that I've added an if statement that makes sure the recipe isn't used for version of python before 2.5. I haven't tested the recipe yet, I didn't have setuptools installed in my 2.5 tree and the cheeseshop seems to be down at the moment. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070117/5f9a10da/attachment.bin From daryl.spitzer at gmail.com Thu Jan 18 22:38:36 2007 From: daryl.spitzer at gmail.com (Daryl Spitzer) Date: Thu, 18 Jan 2007 13:38:36 -0800 Subject: [Pythonmac-SIG] pyperl? Message-ID: Has anyone any experience with pyperl (http://wiki.python.org/moin/PyPerl)? I installed pyperl-1.0.1 without error, but `python test.py` fails: pdb tells me that "import perl" results in "ImportError: perl2.so not found". So I guess it didn't install properly. -- Daryl Spitzer From vip at avatar.com.au Fri Jan 19 07:11:57 2007 From: vip at avatar.com.au (David Worrall) Date: Fri, 19 Jan 2007 17:11:57 +1100 Subject: [Pythonmac-SIG] importing namespaces/modules Message-ID: <025ED0A8-5E99-46FE-8F76-2EB18054C420@avatar.com.au> Hello all, I've got a query which is probably obvious for people more experienced than I but I can't find any exact reference to it elsewhere. It's not mac specific, but hey, I already belong to too many dev groups... :-) The discussion at http://docs.python.org/tut/node11.html is OK but it doesn't really answer my query. I note that increasingly programmers are deprecating >>> from module import * in favour of >>> import module which is fair enough, as explicit attributes make code more readable. Are the functions/classes/whatevers that are imported into the namespace with >>> import module but not otherwise referenced, explicitly loaded into the python "workspace" (excuse me, I'm an unrepentant APL programmer) including the __doc__ strings etc etc or not? And if so, do they remain in the .pyc image? And after py2app? In the case where module is quite large (think wx or twisted for eg) I'm wondering what are the relative advantages/disadvantages of, for example >>> import twisted >>> class MessageHandler(twisted.internet.protocol.DatagramProtocol): compared with >>> from twisted.internet.protocol import DatagramProtocol Class MessageHandler(DatagramProtocol): other than the obvious easy of reading "twisted.internet.protocol.DatagramProtocol" in a large environment with many imported modules, which is my situation. Any advise gratedfully acknowledged, David _________________________________________________ experimental polymedia: www.avatar.com.au Sonic Communications Research Group, University of Canberra. www.canberra.edu.au/vc-forum/scrg vip=Verbal Interactivity Project From piet at cs.uu.nl Fri Jan 19 10:37:00 2007 From: piet at cs.uu.nl (Piet van Oostrum) Date: Fri, 19 Jan 2007 10:37:00 +0100 Subject: [Pythonmac-SIG] importing namespaces/modules In-Reply-To: <025ED0A8-5E99-46FE-8F76-2EB18054C420@avatar.com.au> (David Worrall's message of "Fri\, 19 Jan 2007 17\:11\:57 +1100") References: <025ED0A8-5E99-46FE-8F76-2EB18054C420@avatar.com.au> Message-ID: I should add another difference in the behaviour of variables import in one or the other way. This can lead to subtle differences. If you use 'from module import x, y' (or 'from module import *') Python makes new `bindings' of the names `x' and `y' in the importing module with the values these names had in the imported module. However they are independent of the original ones. So if you execute an assignment to x in the original module, e.g. in a function that was defined there and that you also imported, the change in x is not reflected in the imported x, and vice versa. This can lead to unexpected behaviour. If, however, you say 'import module' and then use module.x, then it is the same variable, and changes in the imported module's x will be visible in the importing module's module.x and vice versa. -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: piet at vanoostrum.org From piet at cs.uu.nl Fri Jan 19 10:27:39 2007 From: piet at cs.uu.nl (Piet van Oostrum) Date: Fri, 19 Jan 2007 10:27:39 +0100 Subject: [Pythonmac-SIG] importing namespaces/modules In-Reply-To: <025ED0A8-5E99-46FE-8F76-2EB18054C420@avatar.com.au> References: <025ED0A8-5E99-46FE-8F76-2EB18054C420@avatar.com.au> Message-ID: >>>>> David Worrall (DW) wrote: >DW> Hello all, >DW> I've got a query which is probably obvious for people more >DW> experienced than I >DW> but I can't find any exact reference to it elsewhere. >DW> It's not mac specific, but hey, I already belong to too many dev >DW> groups... :-) >DW> The discussion at http://docs.python.org/tut/node11.html is OK but it >DW> doesn't really answer my query. >DW> I note that increasingly programmers are deprecating >>>>> from module import * >DW> in favour of >>>>> import module >DW> which is fair enough, as explicit attributes make code more readable. >DW> Are the functions/classes/whatevers that are imported into the >DW> namespace with >>> import module >DW> but not otherwise referenced, explicitly loaded into the python >DW> "workspace" (excuse me, I'm an unrepentant APL programmer) >DW> including the __doc__ strings etc etc or not? The whole module is always loaded into memory, no matter what format of the import statement you use. >DW> And if so, do they remain in the .pyc image? Every module has its own .pyc file. The .pyc file of the importing module only contains the bytecode for the import statement, not the bytecode of the imported module, because that is in thye .pyc file of the imported module. >DW> And after py2app? I am not very familiar with py2app, but I think it packs up the necessary .pyc modules into the executable. But I am quite sure it will always pack the whole .pyc file. It would be unfeasible to extract only a part of a .pyc file as there will be all kinds of internal references in the module. Some of the dependencies might be so dynamic that a static analyses would be unable to detect them. >DW> In the case where module is quite large (think wx or twisted for eg) >DW> I'm wondering what are the relative advantages/disadvantages of, for >DW> example >>>>> import twisted >>>>> class MessageHandler(twisted.internet.protocol.DatagramProtocol): >DW> compared with >>>>> from twisted.internet.protocol import DatagramProtocol >DW> Class MessageHandler(DatagramProtocol): >DW> other than the obvious easy of reading >DW> "twisted.internet.protocol.DatagramProtocol" in a large environment >DW> with many imported modules, which is my situation. The advantages have nothing to do with size. In the above example it is mainly readability, and maybe name clashes with a DatagramProtocol from another module. The main reason for deprecating from module import * is the pollution of your namespace. E.g. ERRORCODE = -1 SUCCESSCODE = 1 from module import * Now suppose this code has been running correctly for a while. Then a revision is made in module which adds the variable ERRORCODE to module.py with a different value. Now suddenly the value of ERRORCODE is different in your program which may lead to subtle bugs. You may think this can be avoided by putting all import statements first in your program before defining any variables (or classes, functions, etc). But then you can have the same interaction between the different modules. from graphics import * from statistics import * Now statistics can `shadow' a variable from graphics, for example if the both have a function 'draw'. Of course the same could happen if you write: from graphics import paint, draw from statistics import draw, average but at least then it is visible in your code. And the most secure would be to use import graphics, and then use graphics.draw etc. -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: piet at vanoostrum.org From ronaldoussoren at mac.com Fri Jan 19 14:08:36 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 19 Jan 2007 05:08:36 -0800 Subject: [Pythonmac-SIG] importing namespaces/modules In-Reply-To: References: <025ED0A8-5E99-46FE-8F76-2EB18054C420@avatar.com.au> Message-ID: On Friday, January 19, 2007, at 01:45PM, "Piet van Oostrum" wrote: > >>DW> And after py2app? > >I am not very familiar with py2app, but I think it packs up the necessary >.pyc modules into the executable. But I am quite sure it will always pack >the whole .pyc file. It would be unfeasible to extract only a part of a >.pyc file as there will be all kinds of internal references in the module. >Some of the dependencies might be so dynamic that a static analyses would >be unable to detect them. py2app always includes entire pyc files and looks at import statements to detect dependencies. Ronald From daryl.spitzer at gmail.com Fri Jan 19 16:56:54 2007 From: daryl.spitzer at gmail.com (Daryl Spitzer) Date: Fri, 19 Jan 2007 07:56:54 -0800 Subject: [Pythonmac-SIG] pyperl? In-Reply-To: References: Message-ID: Felix Schwarz on zope-perl at zope.org pointed out that I should be using 1.0.1c. It works! -- Daryl On 1/18/07, Daryl Spitzer wrote: > Has anyone any experience with pyperl (http://wiki.python.org/moin/PyPerl)? > > I installed pyperl-1.0.1 without error, but `python test.py` fails: > pdb tells me that "import perl" results in "ImportError: perl2.so not > found". So I guess it didn't install properly. > > -- > Daryl Spitzer > From hengist.podd at virgin.net Fri Jan 19 19:28:31 2007 From: hengist.podd at virgin.net (has) Date: Fri, 19 Jan 2007 18:28:31 +0000 Subject: [Pythonmac-SIG] [ann] Appscript Installer 1.5 Message-ID: <7C379CEB-0645-4AD9-B0E7-21209CF52CFF@virgin.net> Hi all, Announcing the release of Appscript Installer 1.5, containing all the latest appscript-related modules, documentation and tools: http://appscript.sourceforge.net/download.html This release contains several significant API changes, along with various bugfixes and other internal improvements, and is recommended for all users. In addition, the bundled osadict command line tool has been overhauled to create a powerful interactive dictionary browser and HTML exporter with support for py-appscript, rb-appscript and AppleScript formatting styles. (Existing appscript users: please read the 'API CHANGES' file included with the appscript package before upgrading from older versions.) Enjoy, has -- http://freespace.virgin.net/hamish.sanderson/ http://appscript.sourceforge.net http://rb-appscript.rubyforge.org From vip at avatar.com.au Sat Jan 20 08:00:53 2007 From: vip at avatar.com.au (David Worrall) Date: Sat, 20 Jan 2007 18:00:53 +1100 Subject: [Pythonmac-SIG] importing namespaces/modules In-Reply-To: References: <025ED0A8-5E99-46FE-8F76-2EB18054C420@avatar.com.au> Message-ID: <6EF24AB1-1747-4F2D-A668-0D15921BFD7D@avatar.com.au> Piet, Ronald, You have been most kind in taking the time to answer these queries. Thank you. David On 20/01/2007, at 12:08 AM, Ronald Oussoren wrote: > > On Friday, January 19, 2007, at 01:45PM, "Piet van Oostrum" > wrote: >> >>> DW> And after py2app? >> >> I am not very familiar with py2app, but I think it packs up the >> necessary >> .pyc modules into the executable. But I am quite sure it will >> always pack >> the whole .pyc file. It would be unfeasible to extract only a part >> of a >> .pyc file as there will be all kinds of internal references in the >> module. >> Some of the dependencies might be so dynamic that a static >> analyses would >> be unable to detect them. > > py2app always includes entire pyc files and looks at import > statements to detect dependencies. > > Ronald > _________________________________________________ experimental polymedia: www.avatar.com.au Sonic Communications Research Group, University of Canberra: www.canberra.edu.au/vc-forum/scrg vip=Verbal Interactivity Project From nirs at freeshell.org Sat Jan 20 15:33:55 2007 From: nirs at freeshell.org (Nir Soffer) Date: Sat, 20 Jan 2007 16:33:55 +0200 Subject: [Pythonmac-SIG] tarfile fails silently on 10.4? Message-ID: <14C95E45-5ED9-44BA-BC37-ECFC29F8EF6B@freeshell.org> I used to use tarfile on 10.3 to extract a bz2 compressed tarball. I tried the code today on 10.4, and untaring fail silently after about 5% of tarball content, without any error. This is the failing code: tar = tarfile.open(os.path.join(SHARE, 'underlay.tar.bz2'), mode='r:bz2') for member in tar: tar.extract(member, WIKI) tar.close() The tarball contains 794 pages, but this code will extract only 47 pages. Again, this used to work correctly about 1 year ago with 10.3.7. The tarball is ok, I can extract the content using tar xjf tarball, and I even recreated the tarball again with same results. Same behavior with builtin Python 2.3.5, and Python 2.4.3 from MacPorts. We used this code instead of using tar command line tool, becaue it has to run on multiple platforms. After wasting too much time on stupid differences between bsd tar and gnu tar, we simply moved to python only solution, which worked great. Best Regards, Nir Soffer From ronaldoussoren at mac.com Sat Jan 20 17:48:02 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 20 Jan 2007 17:48:02 +0100 Subject: [Pythonmac-SIG] tarfile fails silently on 10.4? In-Reply-To: <14C95E45-5ED9-44BA-BC37-ECFC29F8EF6B@freeshell.org> References: <14C95E45-5ED9-44BA-BC37-ECFC29F8EF6B@freeshell.org> Message-ID: <8187B6E7-AA84-44EE-BDC0-27D72547878D@mac.com> On 20 Jan, 2007, at 15:33, Nir Soffer wrote: > I used to use tarfile on 10.3 to extract a bz2 compressed tarball. I > tried the code today on 10.4, and untaring fail silently after about > 5% of tarball content, without any error. > > This is the failing code: > > tar = tarfile.open(os.path.join(SHARE, 'underlay.tar.bz2'), > mode='r:bz2') > for member in tar: > tar.extract(member, WIKI) > tar.close() > > The tarball contains 794 pages, but this code will extract only 47 > pages. Again, this used to work correctly about 1 year ago with > 10.3.7. The script looks fine. How did you create the archive? Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070120/7a435a7a/attachment.bin From nirs at freeshell.org Sun Jan 21 23:19:48 2007 From: nirs at freeshell.org (Nir Soffer) Date: Mon, 22 Jan 2007 00:19:48 +0200 Subject: [Pythonmac-SIG] tarfile fails silently on 10.4? In-Reply-To: <8187B6E7-AA84-44EE-BDC0-27D72547878D@mac.com> References: <14C95E45-5ED9-44BA-BC37-ECFC29F8EF6B@freeshell.org> <8187B6E7-AA84-44EE-BDC0-27D72547878D@mac.com> Message-ID: On Jan 20, 2007, at 18:48, Ronald Oussoren wrote: >> I used to use tarfile on 10.3 to extract a bz2 compressed tarball. I >> tried the code today on 10.4, and untaring fail silently after about >> 5% of tarball content, without any error. >> >> This is the failing code: >> >> tar = tarfile.open(os.path.join(SHARE, 'underlay.tar.bz2'), >> mode='r:bz2') >> for member in tar: >> tar.extract(member, WIKI) >> tar.close() >> >> The tarball contains 794 pages, but this code will extract only 47 >> pages. Again, this used to work correctly about 1 year ago with >> 10.3.7. > > The script looks fine. How did you create the archive? The original tar was created on Linux around a year ago, I don't know how it was created. Trying to extract the original file fail after 42 members. I extracted the tarball and created it again with /usr/bin/tar (GNU tar) 1.14. This version seems to be the same version installed by default on 10.4.8. Trying to extract the new tarball fail after 47 members. Best Regards, Nir Soffer -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070122/6d1f98c0/attachment.htm From dwoods at wcer.wisc.edu Wed Jan 24 16:14:09 2007 From: dwoods at wcer.wisc.edu (David Woods) Date: Wed, 24 Jan 2007 09:14:09 -0600 Subject: [Pythonmac-SIG] Opening an app from another app under different OS X versions Message-ID: <003801c73fca$4bec0090$db296880@ad.education.wisc.edu> My wxPython application has a context sensitive help system, using wx.html.HtmlHelpController(), which also contains a Tutorial for the program. Users like to leave the Help window open while they are simultaneously working in the application. To allow this, I set the Help application up as a free-standing application that I can call from my regular application when it is needed. (This is necessary because of issues with menu construction.) My applications are built using py2app, so the call I've been using looks like this: os.system('open -a TransanaHelp.app') This works on OS X 10.3, and it works when I'm running under Python on OS X 10.4, but I have not been able to get anything along these lines to work under OS X 10.4 once my app has been bundled up with py2app. It's like the Help app tries to launch, but then it immediately, and silently, shuts down. (i.e. the Console doesn't report anything.) os.spawnv() and os.popen2() don't work either. Does anybody have any ideas for how I can launch a bundled wxPython app from within another bundled wxPython app on OS X 10.4? Thanks for your help, David K. Woods, Ph.D. Transana Lead Developer Wisconsin Center for Education Research University of Wisconsin, Madison http://www.transana.org From kw at codebykevin.com Wed Jan 24 17:23:43 2007 From: kw at codebykevin.com (Kevin Walzer) Date: Wed, 24 Jan 2007 11:23:43 -0500 Subject: [Pythonmac-SIG] Opening an app from another app under different OS X versions In-Reply-To: <003801c73fca$4bec0090$db296880@ad.education.wisc.edu> References: <003801c73fca$4bec0090$db296880@ad.education.wisc.edu> Message-ID: <45B7880F.7000901@codebykevin.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Woods wrote: > My wxPython application has a context sensitive help system, using > wx.html.HtmlHelpController(), which also contains a Tutorial for the > program. Users like to leave the Help window open while they are > simultaneously working in the application. To allow this, I set the Help > application up as a free-standing application that I can call from my > regular application when it is needed. (This is necessary because of issues > with menu construction.) My applications are built using py2app, so the > call I've been using looks like this: > > os.system('open -a TransanaHelp.app') > > This works on OS X 10.3, and it works when I'm running under Python on OS X > 10.4, but I have not been able to get anything along these lines to work > under OS X 10.4 once my app has been bundled up with py2app. It's like the > Help app tries to launch, but then it immediately, and silently, shuts down. > (i.e. the Console doesn't report anything.) os.spawnv() and > os.popen2() don't work either. Does anybody have any ideas for how I can > launch a bundled wxPython app from within another bundled wxPython app on OS > X 10.4? > > Thanks for your help, > > David K. Woods, Ph.D. > Transana Lead Developer > Wisconsin Center for Education Research > University of Wisconsin, Madison > http://www.transana.org > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > Where is the help application bundled? Alongside the main app in the same directory, or inside the main app's application bundle itself? Perhaps it's a path issue, i.e. 'open' can't find the app to open. If so, you may need to do some work to get a full path to the help app, then launch it (i.e., os.system('open -a /path/to/myapp.app') ). - -- Kevin Walzer Code by Kevin http://www.codebykevin.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFt4gOEsLm8HXyq4sRAur4AJ9u3vKlXLEldALsil/IdcuUE2/8UwCeKFxo UwGgrIA4fvwU+FA2OjtrPg0= =dyGm -----END PGP SIGNATURE----- From delza at livingcode.org Wed Jan 24 18:44:15 2007 From: delza at livingcode.org (Dethe Elza) Date: Wed, 24 Jan 2007 09:44:15 -0800 Subject: [Pythonmac-SIG] Opening an app from another app under different OS X versions In-Reply-To: <45B7880F.7000901@codebykevin.com> References: <003801c73fca$4bec0090$db296880@ad.education.wisc.edu> <45B7880F.7000901@codebykevin.com> Message-ID: As Kevin said, you may only need the full path to your app. It's remotely possible you would need the full path to open as well (/usr/ bin/open). Full paths are finicky though, and you will need to know where your application is installed, if the help application is in the app bundle, for instance. Also, paths are different on internationalized versions of OS X. The right way is probably to use PyObjC and the NSWorkspace object: from AppKit import NSWorkspace NSWorkspace.sharedWorkspace.launchApplication_('MyApp') For more on Workspace services, there is this article: file:/// Developer/ADC%20Reference%20Library/documentation/Cocoa/Conceptual/ Workspace/index.html Also, when you're launching an app with open, you don't need the -a flag, but without it you do need the path to the application. --Dethe You need to lay out the user interface components visually, by hand, with total control over where they go. Automated LayoutManagers don?t cut it. A corollary of this is that you can?t move a UI layout from one platform to another and have the computer make everything fit. Computers don?t lay out interfaces by themselves any better than they can translate French to English by themselves. -- Jens Alfke From dwoods at wcer.wisc.edu Wed Jan 24 19:13:29 2007 From: dwoods at wcer.wisc.edu (David Woods) Date: Wed, 24 Jan 2007 12:13:29 -0600 Subject: [Pythonmac-SIG] Opening an app from another app under different OSX versions In-Reply-To: <45B7880F.7000901@codebykevin.com> Message-ID: <007101c73fe3$598e90f0$db296880@ad.education.wisc.edu> > David Woods wrote: > > My wxPython application has a context sensitive help system, using > > wx.html.HtmlHelpController(), which also contains a Tutorial for the > > program. Users like to leave the Help window open while they are > > simultaneously working in the application. To allow this, I set the > > Help application up as a free-standing application that I can call > > from my regular application when it is needed. (This is necessary > > because of issues with menu construction.) My applications are built > > using py2app, so the call I've been using looks like this: > > > > os.system('open -a TransanaHelp.app') > > > > This works on OS X 10.3, and it works when I'm running under Python > > on > > OS X 10.4, but I have not been able to get anything along these lines > > to work under OS X 10.4 once my app has been bundled up with py2app. > > It's like the Help app tries to launch, but then it immediately, and > > silently, shuts down. (i.e. the Console doesn't report anything.) > > os.spawnv() and os.popen2() don't work either. Does anybody have any > > ideas for how I can launch a bundled wxPython app from within another > > bundled wxPython app on OS X 10.4? > > > > Thanks for your help, > > > > David K. Woods, Ph.D. > > Transana Lead Developer > > Wisconsin Center for Education Research > > University of Wisconsin, Madison > > http://www.transana.org > > > > > Where is the help application bundled? Alongside the main app > in the same directory, or inside the main app's application > bundle itself? Perhaps it's a path issue, i.e. 'open' can't > find the app to open. If so, you may need to do some work to > get a full path to the help app, then launch it (i.e., > os.system('open -a /path/to/myapp.app') ). > > - -- > Kevin Walzer > Code by Kevin > http://www.codebykevin.com Adding the path didn't help. Calling "open -a TransanaHelp.app" from the command line finds the app, and adding the full path makes is start a bit faster. But when the same call is made from within my bundled Python program (regardless of whether the path is included), I see the following in the console: 'import site' failed; use -v for traceback Traceback (most recent call last): File "/Applications/Transana_2/TransanaHelp.app/Contents/MacOS/TransanaHelp", line 3, in ? import sys, os ImportError: No module named os So it seems, if I'm interpreting this right, like Python's not able to find its own modules under this particular scenario. Line 3 of TransanaHelp.py, by the way, is not the import statement shown here. That line 3 is of some internal Python routine that's not part of my code. Any other ideas? Thanks, David From delza at livingcode.org Wed Jan 24 20:07:05 2007 From: delza at livingcode.org (Dethe Elza) Date: Wed, 24 Jan 2007 11:07:05 -0800 Subject: [Pythonmac-SIG] Opening an app from another app under different OSX versions In-Reply-To: <007101c73fe3$598e90f0$db296880@ad.education.wisc.edu> References: <007101c73fe3$598e90f0$db296880@ad.education.wisc.edu> Message-ID: <27FC22FE-5A7C-4108-92C0-ABE5894711ED@livingcode.org> On 24-Jan-07, at 10:13 AM, David Woods wrote: > Adding the path didn't help. Calling "open -a TransanaHelp.app" > from the > command line finds the app, and adding the full path makes is start > a bit > faster. But when the same call is made from within my bundled Python > program (regardless of whether the path is included), I see the > following in > the console: > > 'import site' failed; use -v for traceback > Traceback (most recent call last): > File > "/Applications/Transana_2/TransanaHelp.app/Contents/MacOS/ > TransanaHelp", > line 3, in ? > import sys, os > ImportError: No module named os > > So it seems, if I'm interpreting this right, like Python's not able > to find > its own modules under this particular scenario. Line 3 of > TransanaHelp.py, > by the way, is not the import statement shown here. That line 3 is > of some > internal Python routine that's not part of my code. I had a problem like this when first moving from distutils-based setup files to setuptools-based setup files. Getting the latest version of py2app may help. --Dethe Copyrights may have been an efficient mechanism to support creative and artistic work in the middle ages, but they don?t work very well in the Internet Age. --Dean Baker From dwoods at wcer.wisc.edu Wed Jan 24 20:38:20 2007 From: dwoods at wcer.wisc.edu (David Woods) Date: Wed, 24 Jan 2007 13:38:20 -0600 Subject: [Pythonmac-SIG] Opening an app from another app under different OSX versions In-Reply-To: <27FC22FE-5A7C-4108-92C0-ABE5894711ED@livingcode.org> Message-ID: <007a01c73fef$33ef4180$db296880@ad.education.wisc.edu> > > Adding the path didn't help. Calling "open -a TransanaHelp.app" > > from the > > command line finds the app, and adding the full path makes > is start > > a bit > > faster. But when the same call is made from within my > bundled Python > > program (regardless of whether the path is included), I see the > > following in > > the console: > > > > 'import site' failed; use -v for traceback > > Traceback (most recent call last): > > File "/Applications/Transana_2/TransanaHelp.app/Contents/MacOS/ > > TransanaHelp", > > line 3, in ? > > import sys, os > > ImportError: No module named os > > > > So it seems, if I'm interpreting this right, like Python's not able > > to find > > its own modules under this particular scenario. Line 3 of > > TransanaHelp.py, > > by the way, is not the import statement shown here. That > line 3 is > > of some > > internal Python routine that's not part of my code. > > I had a problem like this when first moving from distutils-based > setup files to setuptools-based setup files. Getting the latest > version of py2app may help. > > --Dethe Upgrading to py2app 0.3.5 had absolutely no effect. David From daniellord at mac.com Wed Jan 24 23:11:45 2007 From: daniellord at mac.com (Daniel Lord) Date: Wed, 24 Jan 2007 14:11:45 -0800 Subject: [Pythonmac-SIG] Question about "setup.py build" Message-ID: <9B412EF1-B20F-442A-9419-0C16DAA5424D@mac.com> I admit to being a novice at this yet, but I couldn't find anything relevant to this issue on-line: I am trying to build a version of pysqlite that works with sqllite3 : 1. Apple's installed version doesn't work with the latest so I reinstalled 2. sqllite3 won't build shared libs for universal binaries (typical of a lot of linux/UNIX build since the developers never have that problem except on OS X) 3. so I built Intel-only but.... 4. pysqlite keeps trying to build a universal build (CFLAGS="-O -g - isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"; etc. etc.) with "python setup.py build" 5. But nowhere in the setup.py or setup.cfg is that set. I explicitly unset CFLAGS and LDFLAGS to ensure it wasn't coming from there. So where is it being set? By the Python build? Where? I jsut need a little pointer or two and I'll do the rest. Thanks. Daniel From bob at redivi.com Wed Jan 24 23:26:36 2007 From: bob at redivi.com (Bob Ippolito) Date: Wed, 24 Jan 2007 14:26:36 -0800 Subject: [Pythonmac-SIG] Question about "setup.py build" In-Reply-To: <9B412EF1-B20F-442A-9419-0C16DAA5424D@mac.com> References: <9B412EF1-B20F-442A-9419-0C16DAA5424D@mac.com> Message-ID: <6a36e7290701241426s7f372577w1c67e1842f2656c0@mail.gmail.com> On 1/24/07, Daniel Lord wrote: > I admit to being a novice at this yet, but I couldn't find anything > relevant to this issue on-line: > > I am trying to build a version of pysqlite that works with sqllite3 : > 1. Apple's installed version doesn't work with the latest so I > reinstalled > 2. sqllite3 won't build shared libs for universal binaries (typical > of a lot of linux/UNIX build since the developers never have that > problem except on OS X) Why would you want shared libs anyway? I'm pretty sure the Mac build script that comes with Python 2.5 (Mac/BuildScript/build-installer.py) will automatically download SQLite and compile it universally as a static lib. Take a look in there. > 3. so I built Intel-only but.... > 4. pysqlite keeps trying to build a universal build (CFLAGS="-O -g - > isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"; etc. > etc.) with "python setup.py build" > 5. But nowhere in the setup.py or setup.cfg is that set. I > explicitly unset CFLAGS and LDFLAGS to ensure it wasn't coming from > there. > > So where is it being set? By the Python build? Where? I jsut need a > little pointer or two and I'll do the rest. Thanks. The same place that everything else that distutils knows about is coming from, the Makefile in your Python library that was created when Python was built: lib/python2.4/config/Makefile -bob From bob at redivi.com Wed Jan 24 23:29:31 2007 From: bob at redivi.com (Bob Ippolito) Date: Wed, 24 Jan 2007 14:29:31 -0800 Subject: [Pythonmac-SIG] Opening an app from another app under different OSX versions In-Reply-To: <007a01c73fef$33ef4180$db296880@ad.education.wisc.edu> References: <27FC22FE-5A7C-4108-92C0-ABE5894711ED@livingcode.org> <007a01c73fef$33ef4180$db296880@ad.education.wisc.edu> Message-ID: <6a36e7290701241429n1044ca8eh450a68df83fcb9a2@mail.gmail.com> On 1/24/07, David Woods wrote: > > > Adding the path didn't help. Calling "open -a TransanaHelp.app" > > > from the > > > command line finds the app, and adding the full path makes > > is start > > > a bit > > > faster. But when the same call is made from within my > > bundled Python > > > program (regardless of whether the path is included), I see the > > > following in > > > the console: > > > > > > 'import site' failed; use -v for traceback > > > Traceback (most recent call last): > > > File "/Applications/Transana_2/TransanaHelp.app/Contents/MacOS/ > > > TransanaHelp", > > > line 3, in ? > > > import sys, os > > > ImportError: No module named os > > > > > > So it seems, if I'm interpreting this right, like Python's not able > > > to find > > > its own modules under this particular scenario. Line 3 of > > > TransanaHelp.py, > > > by the way, is not the import statement shown here. That > > line 3 is > > > of some > > > internal Python routine that's not part of my code. > > > > I had a problem like this when first moving from distutils-based > > setup files to setuptools-based setup files. Getting the latest > > version of py2app may help. > > > > --Dethe > > Upgrading to py2app 0.3.5 had absolutely no effect. > It's *probably* because py2app sets a lot of environment variables that can effect child Python interpreters... Try clearing out any PY* environment variables sometime early in your script. -bob From daniellord at mac.com Wed Jan 24 23:59:50 2007 From: daniellord at mac.com (Daniel Lord) Date: Wed, 24 Jan 2007 14:59:50 -0800 Subject: [Pythonmac-SIG] Question about "setup.py build" In-Reply-To: <6a36e7290701241426s7f372577w1c67e1842f2656c0@mail.gmail.com> References: <9B412EF1-B20F-442A-9419-0C16DAA5424D@mac.com> <6a36e7290701241426s7f372577w1c67e1842f2656c0@mail.gmail.com> Message-ID: <2F3127B1-0720-4FC7-8AE5-1241EBDC7E80@mac.com> Thanks Bob, coming through as always. Daniel On Jan 24, 2007, at 14:26, Bob Ippolito wrote: > On 1/24/07, Daniel Lord wrote: >> I admit to being a novice at this yet, but I couldn't find anything >> relevant to this issue on-line: >> >> I am trying to build a version of pysqlite that works with sqllite3 : >> 1. Apple's installed version doesn't work with the latest so I >> reinstalled >> 2. sqllite3 won't build shared libs for universal binaries (typical >> of a lot of linux/UNIX build since the developers never have that >> problem except on OS X) > > Why would you want shared libs anyway? I'm pretty sure the Mac build > script that comes with Python 2.5 (Mac/BuildScript/build-installer.py) > will automatically download SQLite and compile it universally as a > static lib. Take a look in there. > >> 3. so I built Intel-only but.... >> 4. pysqlite keeps trying to build a universal build (CFLAGS="-O -g - >> isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"; etc. >> etc.) with "python setup.py build" >> 5. But nowhere in the setup.py or setup.cfg is that set. I >> explicitly unset CFLAGS and LDFLAGS to ensure it wasn't coming from >> there. >> >> So where is it being set? By the Python build? Where? I jsut need a >> little pointer or two and I'll do the rest. Thanks. > > The same place that everything else that distutils knows about is > coming from, the Makefile in your Python library that was created when > Python was built: lib/python2.4/config/Makefile > > -bob From daniellord at mac.com Thu Jan 25 02:39:40 2007 From: daniellord at mac.com (Daniel Lord) Date: Wed, 24 Jan 2007 17:39:40 -0800 Subject: [Pythonmac-SIG] Question about "setup.py build" In-Reply-To: References: <9B412EF1-B20F-442A-9419-0C16DAA5424D@mac.com> <6a36e7290701241426s7f372577w1c67e1842f2656c0@mail.gmail.com> Message-ID: I realized I only copied Bob on this and to send it out to everyone might help someone else the build for PySQLite is poorly designed and ignores the state of '-- enable-shared' and looks for the dylib anyway so fails on static-only builds. I will have to hack it to get it to work. Shame, shame. On Jan 24, 2007, at 15:08, Daniel Lord wrote: > Bob, > Just so you know though, I was building the dynamic libs because > the installer looks for them even if you disable shared libs. > Bad design. So I'll have to 'hack' it to make it work. Not that > that isn't business as usual with OS X ;-) > > [daniello at mercury.local]$ sudo make install > Password: > tclsh ./tclinstaller.tcl 3.3 > couldn't open ".libs/libtclsqlite3.dylib": no such file or directory > while executing > "open $LIBFILE" > invoked from within > "set in [open $LIBFILE]" > (file "./tclinstaller.tcl" line 23) > make: *** [tcl_install] Error 1 > [ > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20070124/10034b8a/attachment.htm From ronaldoussoren at mac.com Thu Jan 25 09:08:21 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 25 Jan 2007 09:08:21 +0100 Subject: [Pythonmac-SIG] Opening an app from another app under different OS X versions In-Reply-To: References: <003801c73fca$4bec0090$db296880@ad.education.wisc.edu> <45B7880F.7000901@codebykevin.com> Message-ID: <08C2B577-D78B-4515-9009-63E495A0E5A8@mac.com> On 24 Jan, 2007, at 18:44, Dethe Elza wrote: > Also, paths are different on > internationalized versions of OS X. The aren't AFAIK. The finder is localized and shows different folder names if you run in another language (that's why there are ".localized" turds in several directories). Windows is the OS where directory names actually do change depending on the language you install it in. The OSX implementation actually makes it possible to have several accounts with different languages and have them all see their localized version of folder names. > > --Dethe > > > You need to lay out the user interface components visually, by hand, > with total control over where they go. Automated LayoutManagers don?t > cut it. A corollary of this is that you can?t move a UI layout from > one platform to another and have the computer make everything fit. > Computers don?t lay out interfaces by themselves any better than they > can translate French to English by themselves. -- Jens Alfke +1 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070125/c36b3ec3/attachment.bin From ronaldoussoren at mac.com Thu Jan 25 09:19:01 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 25 Jan 2007 09:19:01 +0100 Subject: [Pythonmac-SIG] Question about "setup.py build" In-Reply-To: <6a36e7290701241426s7f372577w1c67e1842f2656c0@mail.gmail.com> References: <9B412EF1-B20F-442A-9419-0C16DAA5424D@mac.com> <6a36e7290701241426s7f372577w1c67e1842f2656c0@mail.gmail.com> Message-ID: <9687D695-4667-4894-A2A5-D3E12C3A4FAF@mac.com> On 24 Jan, 2007, at 23:26, Bob Ippolito wrote: > On 1/24/07, Daniel Lord wrote: >> I admit to being a novice at this yet, but I couldn't find anything >> relevant to this issue on-line: >> >> I am trying to build a version of pysqlite that works with sqllite3 : >> 1. Apple's installed version doesn't work with the latest so I >> reinstalled >> 2. sqllite3 won't build shared libs for universal binaries (typical >> of a lot of linux/UNIX build since the developers never have that >> problem except on OS X) > > Why would you want shared libs anyway? I'm pretty sure the Mac build > script that comes with Python 2.5 (Mac/BuildScript/build-installer.py) > will automatically download SQLite and compile it universally as a > static lib. Take a look in there. It does, the sqlite module in the binary distribution for python 2.5 links with our own copy of sqlite because the distribution also works on 10.3 and Apple didn't ship sqlite with that release. I'm also pretty sure that I didn't anything that would make it impossible to build a univeral dynamic library, I use a static lib because that's more convenient. The only reason to use a dylib when building extensions is when you have multiple extensions that link to the same library and share access (that's why the bundles ncurses in py2.5 is a shared library). > >> 3. so I built Intel-only but.... >> 4. pysqlite keeps trying to build a universal build (CFLAGS="-O -g - >> isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc"; etc. >> etc.) with "python setup.py build" >> 5. But nowhere in the setup.py or setup.cfg is that set. I >> explicitly unset CFLAGS and LDFLAGS to ensure it wasn't coming from >> there. >> >> So where is it being set? By the Python build? Where? I jsut need a >> little pointer or two and I'll do the rest. Thanks. > > The same place that everything else that distutils knows about is > coming from, the Makefile in your Python library that was created when > Python was built: lib/python2.4/config/Makefile Barring bug adding '-arch', 'i386' to the compile and link flags for an extension should do the right thing (that is, distutils will recoginze these flags and remove the default -arch flags when the user specified a specific architecture). Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070125/2750d0ea/attachment-0001.bin From ronaldoussoren at mac.com Thu Jan 25 09:24:42 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 25 Jan 2007 09:24:42 +0100 Subject: [Pythonmac-SIG] Opening an app from another app under different OSX versions In-Reply-To: <6a36e7290701241429n1044ca8eh450a68df83fcb9a2@mail.gmail.com> References: <27FC22FE-5A7C-4108-92C0-ABE5894711ED@livingcode.org> <007a01c73fef$33ef4180$db296880@ad.education.wisc.edu> <6a36e7290701241429n1044ca8eh450a68df83fcb9a2@mail.gmail.com> Message-ID: <8CBD0EA4-B84E-4D2C-AA78-70E9AF08285E@mac.com> On 24 Jan, 2007, at 23:29, Bob Ippolito wrote: > On 1/24/07, David Woods wrote: >>>> Adding the path didn't help. Calling "open -a TransanaHelp.app" >>>> from the >>>> command line finds the app, and adding the full path makes >>> is start >>>> a bit >>>> faster. But when the same call is made from within my >>> bundled Python >>>> program (regardless of whether the path is included), I see the >>>> following in >>>> the console: >>>> >>>> 'import site' failed; use -v for traceback >>>> Traceback (most recent call last): >>>> File "/Applications/Transana_2/TransanaHelp.app/Contents/MacOS/ >>>> TransanaHelp", >>>> line 3, in ? >>>> import sys, os >>>> ImportError: No module named os >>>> >>>> So it seems, if I'm interpreting this right, like Python's not able >>>> to find >>>> its own modules under this particular scenario. Line 3 of >>>> TransanaHelp.py, >>>> by the way, is not the import statement shown here. That >>> line 3 is >>>> of some >>>> internal Python routine that's not part of my code. >>> >>> I had a problem like this when first moving from distutils-based >>> setup files to setuptools-based setup files. Getting the latest >>> version of py2app may help. >>> >>> --Dethe >> >> Upgrading to py2app 0.3.5 had absolutely no effect. >> > > It's *probably* because py2app sets a lot of environment variables > that can effect child Python interpreters... Try clearing out any PY* > environment variables sometime early in your script. And please try to build a small application that reproduces the problem when this doesn't work out. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3562 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20070125/fb586ff2/attachment.bin From delza at livingcode.org Thu Jan 25 18:35:05 2007 From: delza at livingcode.org (Dethe Elza) Date: Thu, 25 Jan 2007 09:35:05 -0800 Subject: [Pythonmac-SIG] Opening an app from another app under different OS X versions In-Reply-To: <08C2B577-D78B-4515-9009-63E495A0E5A8@mac.com> References: <003801c73fca$4bec0090$db296880@ad.education.wisc.edu> <45B7880F.7000901@codebykevin.com> <08C2B577-D78B-4515-9009-63E495A0E5A8@mac.com> Message-ID: On 25-Jan-07, at 12:08 AM, Ronald Oussoren wrote: > On 24 Jan, 2007, at 18:44, Dethe Elza wrote: > >> Also, paths are different on >> internationalized versions of OS X. > > The aren't AFAIK. The finder is localized and shows different > folder names if you run in another language (that's why there are > ".localized" turds in several directories). Windows is the OS where > directory names actually do change depending on the language you > install it in. > > The OSX implementation actually makes it possible to have several > accounts with different languages and have them all see their > localized version of folder names. Cool, I didn't know that. I'm pretty sure older versions of Mac OS (pre-OS X) *did* work that way--you had to use symbolic constants to refer to known folders and not count on the exact file paths. That said, using fully-qualified paths can still be fragile, since users may move things around when you least expect it. --Dethe "There's a little bit of God in every truck driver and a little bit of truck driver in every God." -- Blayne Horner From dwoods at wcer.wisc.edu Thu Jan 25 19:41:29 2007 From: dwoods at wcer.wisc.edu (David Woods) Date: Thu, 25 Jan 2007 12:41:29 -0600 Subject: [Pythonmac-SIG] Opening an app from another app under different OSX versions -- SOLVED In-Reply-To: <6a36e7290701241429n1044ca8eh450a68df83fcb9a2@mail.gmail.com> Message-ID: <00a601c740b0$6d2288b0$db296880@ad.education.wisc.edu> > On 1/24/07, David Woods wrote: > > > > Adding the path didn't help. Calling "open -a > TransanaHelp.app" > > > > from the command line finds the app, and adding the full path > > > > makes > > > is start > > > > a bit > > > > faster. But when the same call is made from within my > > > bundled Python > > > > program (regardless of whether the path is included), I see the > > > > following in the console: > > > > > > > > 'import site' failed; use -v for traceback > > > > Traceback (most recent call last): > > > > File > "/Applications/Transana_2/TransanaHelp.app/Contents/MacOS/ > > > > TransanaHelp", > > > > line 3, in ? > > > > import sys, os > > > > ImportError: No module named os > > > > > > > > So it seems, if I'm interpreting this right, like Python's not > > > > able to find its own modules under this particular > scenario. Line > > > > 3 of TransanaHelp.py, > > > > by the way, is not the import statement shown here. That > > > line 3 is > > > > of some > > > > internal Python routine that's not part of my code. > > > > > > I had a problem like this when first moving from distutils-based > > > setup files to setuptools-based setup files. Getting the latest > > > version of py2app may help. > > > > > > --Dethe > > > > Upgrading to py2app 0.3.5 had absolutely no effect. > > > > It's *probably* because py2app sets a lot of environment > variables that can effect child Python interpreters... Try > clearing out any PY* environment variables sometime early in > your script. > > -bob Bob, That was indeed the source of the problem. I now delete the PYTHONHOME, PYTHONPATH, and PYTHONEXECUTABLE environment variables before the os.system() call and the Help application shows up as it should. Am I likely to see side-effects from deleting these environment variables? Should I restore them to their original values after the Help call has been made? Thanks a ton for your help. I *NEVER* would've figure this one out. David From bob at redivi.com Thu Jan 25 20:12:21 2007 From: bob at redivi.com (Bob Ippolito) Date: Thu, 25 Jan 2007 11:12:21 -0800 Subject: [Pythonmac-SIG] Opening an app from another app under different OSX versions -- SOLVED In-Reply-To: <00a601c740b0$6d2288b0$db296880@ad.education.wisc.edu> References: <6a36e7290701241429n1044ca8eh450a68df83fcb9a2@mail.gmail.com> <00a601c740b0$6d2288b0$db296880@ad.education.wisc.edu> Message-ID: <6a36e7290701251112g5eb1c4dfo1395a8ca3315b650@mail.gmail.com> On 1/25/07, David Woods wrote: > > On 1/24/07, David Woods wrote: > > > > > Adding the path didn't help. Calling "open -a > > TransanaHelp.app" > > > > > from the command line finds the app, and adding the full path > > > > > makes > > > > is start > > > > > a bit > > > > > faster. But when the same call is made from within my > > > > bundled Python > > > > > program (regardless of whether the path is included), I see the > > > > > following in the console: > > > > > > > > > > 'import site' failed; use -v for traceback > > > > > Traceback (most recent call last): > > > > > File > > "/Applications/Transana_2/TransanaHelp.app/Contents/MacOS/ > > > > > TransanaHelp", > > > > > line 3, in ? > > > > > import sys, os > > > > > ImportError: No module named os > > > > > > > > > > So it seems, if I'm interpreting this right, like Python's not > > > > > able to find its own modules under this particular > > scenario. Line > > > > > 3 of TransanaHelp.py, > > > > > by the way, is not the import statement shown here. That > > > > line 3 is > > > > > of some > > > > > internal Python routine that's not part of my code. > > > > > > > > I had a problem like this when first moving from distutils-based > > > > setup files to setuptools-based setup files. Getting the latest > > > > version of py2app may help. > > > > > > > > --Dethe > > > > > > Upgrading to py2app 0.3.5 had absolutely no effect. > > > > > > > It's *probably* because py2app sets a lot of environment > > variables that can effect child Python interpreters... Try > > clearing out any PY* environment variables sometime early in > > your script. > > > > -bob > > > Bob, > > That was indeed the source of the problem. I now delete the PYTHONHOME, > PYTHONPATH, and PYTHONEXECUTABLE environment variables before the > os.system() call and the Help application shows up as it should. > > Am I likely to see side-effects from deleting these environment variables? > Should I restore them to their original values after the Help call has been > made? No, there will not be side-effects. Those variables are used by py2app's bootstrap executable to communicate with the Python interpreter on startup and that's it. > Thanks a ton for your help. I *NEVER* would've figure this one out. It's certainly not obvious. I only knew what it was because I wrote py2app ;) -bob From mithro at mithis.com Sun Jan 28 07:07:30 2007 From: mithro at mithis.com (Tim Ansell) Date: Sun, 28 Jan 2007 16:37:30 +1030 Subject: [Pythonmac-SIG] Threaded GUI application.... Message-ID: <1169964450.27591.160.camel@localhost> Hello, I currently have a threaded GUI application. I have a "GUI" thread (which is always the main thread), a "Media Download" thread, and a few other misc threads. Everything worked fine on Mac OS X until I added the "Media Download" thread. I was very careful to make sure GUI calls only occured in the GUI thread (because otherwise you get "Bus Error" segfaults). However, after I added the "Media Download" thread, I started getting "Bus Error". I couldn't figure out why for a long time, the "Media Download" thread definitely makes no GUI calls in any of my code. I trace the error to urlib.py in the standard library. The culprit is the following lines, ---- if sys.platform == 'darwin': def getproxies_internetconfig(): """Return a dictionary of scheme -> proxy server URL mappings. By convention the mac uses Internet Config to store proxies. An HTTP proxy, for instance, is stored under the HttpProxy key. """ try: import ic except ImportError: return {} ------- It dies on the "import ic" line with a "Bus Error". I'm assuming this is because the IC module interacts with the GUI, and as it isn't the main thread causes this problem. So, my question is, how do I get around/fix this? Is there a way to "catch" the Bus Error and just throw an exception? Can I override the getproxies_internetconfig function? Are there any other standard library functions I should avoid calling in a non-main thread under Mac? Thanks for your help. Tim Ansell From chris.van.bael at gmail.com Sun Jan 28 16:32:31 2007 From: chris.van.bael at gmail.com (Chris Van Bael) Date: Sun, 28 Jan 2007 07:32:31 -0800 Subject: [Pythonmac-SIG] Stripping for i386 on G4, bad install of py2app Message-ID: <5465ee790701280732k36455512t3d56753b4748fbe7@mail.gmail.com> Hi all, I want to ask you for some help, for a problem that's coming back to bite me again. See: http://mail.python.org/pipermail/pythonmac-sig/2006-November/018421.html Problem is that striping for i386 doesn't succeed on a G4. Did the uninstall according to the py2app webpage, but still fails. I had this problem on my G4 Mini and I could only resolve it by reinstalling OS X completely. Now I have an iBook G4 with the same problem. Reinstalled OSX completely, but still no success. If first installed setuptools and py2app with the bootstrap method, when a build with that failed, I uninstalled it and re-installed it according to this guide: http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html#installation I know of some other people that where also not succesfull in installing py2app/setuptools. Is there maybe some problem with the installer? I do it every time according to the guide and yet most of the time it fails... Greets, Chris From kim.branson at gmail.com Tue Jan 30 08:00:00 2007 From: kim.branson at gmail.com (Kim Branson) Date: Mon, 29 Jan 2007 23:00:00 -0800 Subject: [Pythonmac-SIG] numarray 1.5.2 compilation 10.4 ppc Message-ID: <638A823D-6B61-4A6C-B9F5-F495860F3A22@gmail.com> Hi, i'm trying to build numarray 1.5.2 for 10.4 on a ppc machine, using gcc 4.0. i get the following errors: this machine does not have the MacOSX10.4u sdk. it has xcode 2.1 installed. there are a few versions of limits in /usr/include/i386/limits.h /usr/include/i386/_limits.h /usr/include/limits.h /usr/include/machine/limits.h /usr/include/machine/_limits.h /usr/include/ppc/limits.h /usr/include/ppc/_limits.h /usr/include/sys/syslimits.h /usr/lib/gcc/i686-apple-darwin8/4.0.0/include/limits.h should i try to get setup.py to use these? cheers Kim >python setup.py build Using EXTRA_COMPILE_ARGS = ['-Ddarwin'] Using external BLAS and LAPACK running config Wrote config.h running build running build_py copying Lib/numinclude.py -> build/lib.macosx-10.3-fat-2.4/numarray running build_ext building 'numarray._conv' extension gcc -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk - fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd - fno-common -dynamic -DNDEBUG -g -O3 -IInclude/numarray -I/Library/ Frameworks/Python.framework/Versions/2.4/include/python2.4 -c Src/ _convmodule.c -o build/temp.macosx-10.3-fat-2.4/Src/_convmodule.o - Ddarwin In file included from Src/_convmodule.c:13: /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:18:20: error: limits.h: No such file or directory /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:21:2: error: #error "Something's broken. UCHAR_MAX should be defined in limits.h." /Library/Frameworks/Python.framework/Versions/2.4/include/python2.4/ Python.h:25:2: error: #error "Python's source code assumes C's unsigned char is an 8-bit type." ..etc.. From lists at mostrom.pp.se Tue Jan 30 10:49:21 2007 From: lists at mostrom.pp.se (=?UTF-8?Q?Jan_Erik_Mostr=C3=B6?= =?UTF-8?Q?m?=) Date: Tue, 30 Jan 2007 10:49:21 +0100 Subject: [Pythonmac-SIG] Growl for python 2.5 Message-ID: How can I change the growl binding so they work for 2.5? I tried finding some place where I configure this but being a newbie with this I failed. jem From pythonmac-sig at mcclimans.net Tue Jan 30 16:42:40 2007 From: pythonmac-sig at mcclimans.net (Chris McClimans) Date: Tue, 30 Jan 2007 09:42:40 -0600 Subject: [Pythonmac-SIG] /Library/Graphics/Patch .plugin for Quartz Composer In-Reply-To: <6FB7E647-7452-44C7-8EDD-B06E006C7EAE@mac.com> References: <93B1D612-A8F4-483E-92AF-8EEBCBDA651C@mcclimans.net> <6FB7E647-7452-44C7-8EDD-B06E006C7EAE@mac.com> Message-ID: I was poking around the working Quartz Composer Patch Plugin build I made and found the exact version I used to create it in Contents/ Info.plist: py2app template bundle version 0.2.5 So I downloaded http://svn.red-bean.com/bob/py2app/releases/ py2app-0.2.5/ and it still didn't work. So I started looking at the imports. The culprit is an upgrade from the included macholib-0.8 from py2app-0.2.5 to macholib-1.0 or higher. If you install a macholib version beyond what is included with py2app-0.2.5, the build process works differently. For me it results in two binaries. (sample setup.py and PyQcPatchLoader.py below) Results after 'python setup.py py2app' with py2app-0.2.5 and the included macholib-0.8: $ls dist/PyQcPatchLoader.plugin/Contents/MacOS/ PyQcPatchLoader Results after 'python setup.py py2app' with py2app-0.3.1 and macholib-1.0 or higher: $ls dist/PyQcPatchLoader.plugin/Contents/MacOS/ PyQcPatchLoader python I suspect a diff of: http://svn.red-bean.com/bob/py2app/releases/py2app-0.2.5/src/ macholib/ #aka macholib-0.8 and http://svn.red-bean.com/bob/macholib/tags/macholib-1.0/macholib/ has the culprit embedded in there somewhere. Any thoughts or suggestions would be greatly appreciated. -chris ps. I'm moving this thread to pythonmac-sig as it's not really pyobjc- dev related and that list seems to get more volume. On Jan 30, 2007, at 1:38 AM, Ronald Oussoren wrote: > > >> For those that are not interested in QuartzComposer plugins, here is >> my real issue. >> The setup.py below should result in only one file in dist/ >> PyQcPatchLoader.plugin/Contents/MacOS/ and it should be >> PyQcPatchLoader when run through py2app. However it contains both >> python and the CFBundleExecutable and they are not linked correctly >> for loading as a plugin. >> >> I was able to get it to work correctly yesterday, but now I've >> upgraded everything to current versions, and I think I have broken >> something. Or I may have a blaring mistake staring at me. ;) > > The setup.py file looks fine to me. It seems that you have stumbled > acros a bug in py2app. I'll see if I can find and fix this. > > Ronald > > On 29 Jan, 2007, at 19:55, Chris McClimans wrote: ===setup.py=== """ Script for building the a GraphFoundation plugin... aka a QuartComposer Framework patch. Usage: python setup.py py2app To use this copy dist/PyPatchLoader.plugin to Library/Graphics/Patches: ~/Library/Graphics/Patches /Library/Graphics/Patches /System/Library/Graphics/Patches """ from distutils.core import setup import py2app infoPlist = setup( name='PyQcPatchLoader', plugin=['PyQcPatchLoader.py'], options=dict( py2app=dict( extension=".plugin", plist=dict( CFBundleDevelopmentRegion='English', CFBundleExecutable='PyQcPatchLoader', CFBundleName='PyQcPatchLoader', NSPrincipalClass='PyQcPatchLoader', CFBundleIdentifier='net.mcclimans.pypatchloader', CFBundleGetInfoString='Simple Python Plugin Loader for Quartz Composer', CFBundlePackageType='BNDL', GFPlugIn=True, CFBundleSignature='????', CFBundleVersion='1.0', CFBundleShortVersionString = '0.1', ) ), ), ) ===PyQcPatchLoader.py== import Quartz import objc from Foundation import NSLog objc.loadBundle('QuartComposer',globals(), objc.pathForFramework( u'/System/Library/Frameworks/Quartz.framework/Frameworks/ QuartzComposer.framework')) QCPatch=objc.lookUpClass('QCPatch') class PyQcPatch(QCPatch): pass # The NSPrincipalClass of a QCPatch BNDL must conform to GFPluginRegistration GFPlugInRegistration = objc.protocolNamed('GFPlugInRegistration') class PyQcPatchLoader(NSObject, GFPlugInRegistration): @objc.signature('v12 at 0:4 at 8') def registerNodesWithManager_(self, nodemanager): """ nodemanager is a GFNodeManager instance that is passed to us when this module is loaded by the QuartzComposer Framework """ NSLog('We Excuted! Yea!') nodemanager.registerNodeWithClass_(PyQcPatch) #we'll deal with what really needs to happen later #nodemanager.registerNodeWithClass_(PyPatch) registerNodesWithManager_=classmethod(registerNodesWithManager_) From Chris.Barker at noaa.gov Tue Jan 30 23:13:53 2007 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 30 Jan 2007 14:13:53 -0800 Subject: [Pythonmac-SIG] Regarding universal python framework.... Message-ID: <45BFC321.70103@noaa.gov> Hi all, I had a question/comment from a numpy/Scipy developer that I was asked to forward on: > > To get the "definition" of "universal" I went to > > http://en.wikipedia.org/wiki/Universal_Binaries > > > > the last paragraph says: > > Apple's Xcode 2.4 takes the concept of universal binaries even > > further, by allowing four-architecture binaries to be created (32 and > > 64 bit for both Intel and PowerPC), therefore allowing a single > > executable to take full advantage of the CPU capabilities of any Mac > > OS X machine What are folk's thoughts on building "quad binary" universal builds in the future? Is there much point? Are there any 64bit Intel Macs? What difference might a 64bit build make on a G5? For the app in mind, this is the issue: I am interested in 64-bit because it is supposed to be able to open >4GB data files in memmap mode (that is, you could treat any large data set like a normal numpy array and *instantaneously* access sub-data without ever loading the entire file. Note that this works even with small amounts of physical memory, only the (theoretical) memory address space has to be 64bit.) thoughts? -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Tue Jan 30 23:21:30 2007 From: bob at redivi.com (Bob Ippolito) Date: Tue, 30 Jan 2007 14:21:30 -0800 Subject: [Pythonmac-SIG] Regarding universal python framework.... In-Reply-To: <45BFC321.70103@noaa.gov> References: <45BFC321.70103@noaa.gov> Message-ID: <6a36e7290701301421q7457c05dq134bb0320d8ad265@mail.gmail.com> On 1/30/07, Christopher Barker wrote: > Hi all, > > I had a question/comment from a numpy/Scipy developer that I was asked > to forward on: > > > > To get the "definition" of "universal" I went to > > > http://en.wikipedia.org/wiki/Universal_Binaries > > > > > > the last paragraph says: > > > Apple's Xcode 2.4 takes the concept of universal binaries even > > > further, by allowing four-architecture binaries to be created (32 and > > > 64 bit for both Intel and PowerPC), therefore allowing a single > > > executable to take full advantage of the CPU capabilities of any Mac > > > OS X machine > > What are folk's thoughts on building "quad binary" universal builds in > the future? Is there much point? Are there any 64bit Intel Macs? What > difference might a 64bit build make on a G5? A 64-bit build would use more RAM, and it would let you address more RAM. That's pretty much it. It would also be only usable on leopard. I tried to build ppc64 on my G5 with tiger and it just crashed (and I didn't have enough reason to figure out exactly why). For intel it's probably a bit different because there's more registers and whatnot in 64-bit mode... so it may actually be an overall performance win for machines that can do it. I think all Core 2 Duo machines are x86-64 capable. > For the app in mind, this is the issue: > > I am interested in 64-bit because it is supposed to be able to > open >4GB data files in memmap mode (that is, you could treat any > large data set like a normal numpy array and *instantaneously* access > sub-data without ever loading the entire file. Note that this works > even with small amounts of physical memory, only the (theoretical) > memory address space has to be 64bit.) That is a good use case for having a 64-bit address space. The problem with a quad binary build is that there's a lot more difference between 32-bit and 64-bit than there is from PPC and Intel. It would be a lot of work to make that happen. It would also end up in pain because I believe that a 64-bit machine would default to using the 64-bit version of the executable which wouldn't be compatible with any existing extensions. It would make a lot of sense to have a 64-bit python distribution that was built for x86-64 and ppc64... but I don't think it would be a good idea to try and make python build quad. -bob From Chris.Barker at noaa.gov Wed Jan 31 00:31:27 2007 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 30 Jan 2007 15:31:27 -0800 Subject: [Pythonmac-SIG] Regarding universal python framework.... In-Reply-To: <6a36e7290701301421q7457c05dq134bb0320d8ad265@mail.gmail.com> References: <45BFC321.70103@noaa.gov> <6a36e7290701301421q7457c05dq134bb0320d8ad265@mail.gmail.com> Message-ID: <45BFD54F.1020108@noaa.gov> Thanks Bob, We can always count on you for having useful ideas about all sorts of stuff. It does sound like a quad binary wouldn't be a good idea. > For intel it's probably a bit different because there's more registers > and whatnot in 64-bit mode... so it may actually be an overall > performance win for machines that can do it. > > I think all Core 2 Duo machines are x86-64 capable. Isn't that all Intel Macs? > The problem with a quad binary build is that there's a lot more > difference between 32-bit and 64-bit than there is from PPC and Intel. Wow! that's a surprise to me. I suppose there are a LOT of 32 bit assumptions built into a lot of code. > It would be a lot of work to make that happen. It would also end up in > pain because I believe that a 64-bit machine would default to using > the 64-bit version of the executable which wouldn't be compatible with > any existing extensions. Would setup.py build Universal extensions right (if the extension was written to support 64 bit)? > It would make a lot of sense to have a 64-bit python distribution that > was built for x86-64 and ppc64... Hmm. I like that idea. Now we just need a bunch of people to find the time..... -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Wed Jan 31 00:36:32 2007 From: bob at redivi.com (Bob Ippolito) Date: Tue, 30 Jan 2007 15:36:32 -0800 Subject: [Pythonmac-SIG] Regarding universal python framework.... In-Reply-To: <45BFD54F.1020108@noaa.gov> References: <45BFC321.70103@noaa.gov> <6a36e7290701301421q7457c05dq134bb0320d8ad265@mail.gmail.com> <45BFD54F.1020108@noaa.gov> Message-ID: <6a36e7290701301536w21283868hc7873a3fd881eb0b@mail.gmail.com> On 1/30/07, Christopher Barker wrote: > > Thanks Bob, > > We can always count on you for having useful ideas about all sorts of stuff. > > It does sound like a quad binary wouldn't be a good idea. > > > For intel it's probably a bit different because there's more registers > > and whatnot in 64-bit mode... so it may actually be an overall > > performance win for machines that can do it. > > > > I think all Core 2 Duo machines are x86-64 capable. > > Isn't that all Intel Macs? No. The first few revisions were Core Duo, not Core 2 Duo. The MacBook Pro I have definitely isn't 64-bit or 802.11n... > > The problem with a quad binary build is that there's a lot more > > difference between 32-bit and 64-bit than there is from PPC and Intel. > > Wow! that's a surprise to me. I suppose there are a LOT of 32 bit > assumptions built into a lot of code. It's not so much that there are 32-bit assumptions but that there are checks that do different things between 32-bit and 64-bit code, and if that check is done during configure or setup.py then it's not compatible with the way that universal binaries are typically built. > > It would be a lot of work to make that happen. It would also end up in > > pain because I believe that a 64-bit machine would default to using > > the 64-bit version of the executable which wouldn't be compatible with > > any existing extensions. > > Would setup.py build Universal extensions right (if the extension was > written to support 64 bit)? Sure. Distutils builds things the same way that Python was built unless you tell it otherwise. > > It would make a lot of sense to have a 64-bit python distribution that > > was built for x86-64 and ppc64... > > Hmm. I like that idea. Now we just need a bunch of people to find the > time..... Good luck :) Personally I have neither the time, need, or the (intel) hardware. -bob From ronaldoussoren at mac.com Wed Jan 31 09:14:12 2007 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 31 Jan 2007 09:14:12 +0100 Subject: [Pythonmac-SIG] Regarding universal python framework.... In-Reply-To: <45BFC321.70103@noaa.gov> References: <45BFC321.70103@noaa.gov> Message-ID: <721C870C-E482-405E-A716-26DD0AFBCB56@mac.com> On 30 Jan, 2007, at 23:13, Christopher Barker wrote: > Hi all, > > I had a question/comment from a numpy/Scipy developer that I was asked > to forward on: > >>> To get the "definition" of "universal" I went to >>> http://en.wikipedia.org/wiki/Universal_Binaries >>> >>> the last paragraph says: >>> Apple's Xcode 2.4 takes the concept of universal binaries even >>> further, by allowing four-architecture binaries to be created (32 >>> and >>> 64 bit for both Intel and PowerPC), therefore allowing a single >>> executable to take full advantage of the CPU capabilities of any Mac >>> OS X machine > > What are folk's thoughts on building "quad binary" universal builds in > the future? Is there much point? Are there any 64bit Intel Macs? What > difference might a 64bit build make on a G5? I'd love to see a 4-way universal build of python, but mostly just because of the coolness factor not that I really need it. As Bob noted this isn't as simple as turning on extra CFLAGS and I don't have time to work on this for the forseeable future. With a 4-way universal build I'd make the framework itself 4-way universal and have two sets of python interpreters: "python/ python2.5" and "python-64/python2.5-64". That way users can explicitly choose if they want to use a 64-bit build. This is a hard requirement for Tiger because of the severe limitations on the API's you can use there in 64-bit mode, but even on Leopard 64-bit is not always the right choice. Ronald