From delza at livingcode.org Tue Jan 3 06:17:11 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 2 Jan 2006 21:17:11 -0800 Subject: [Pythonmac-SIG] PyMedia for Mac? Message-ID: Does anyone know of a working port of PyMedia for OS X? I've seen, via Google, that several people have attempted the job, but no sign of anyone who has completed it. --Dethe Young children play in a way that is strikingly similar to the way scientists work --Busytown News From mark.asbach at post.rwth-aachen.de Tue Jan 3 22:27:33 2006 From: mark.asbach at post.rwth-aachen.de (Mark Asbach) Date: Tue, 03 Jan 2006 22:27:33 +0100 Subject: [Pythonmac-SIG] Newbie troubles with MacPython 2.4.1 / Tiger 10.4.3 Message-ID: <3484DADB-7B11-4699-B0BB-F755DA5CA536@post.rwth-aachen.de> Hi everybody, I know this should / could be a FAQ, but unfortunately I didn't find anything appropriate on the MacPython pages or the Python Wiki. Here's my problem: I started with a iMac G5 with all Apple updates installed. Then I installed MacPython-OSX-2.4.1-1, directly after that I installed the TigerPython24Fix-r2. Then I started up the PackageManager and tried to get those modules that I need. I successfully installed PIL-1.1.5- binary, but when I tried to install numarray-1.2.3-binary, the install failed. Now there's an incomplete numarray on my disk that fails to import into python2.4 with the error "no module named numarrayall". When I enable "Show Hidden" in PackageManager, the pseudo packages "WriteableBin-hidden" and "WriteableInclude-hidden" appear not to be installed. It's also interesting, that when I disable "For Current User Only", I get a warning that says "Install directory '/Library/ Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages' is not writeable or not readable". That's correct: iMac:~ asbach$ ll /Library/Frameworks/Python.framework/Versions/2.4/ lib/python2.4/site-packages total 8 -rw-r--r-- 1 root admin 119 Mar 31 2005 README Hm. Did I overlook something? What should I do to get numarray installed? chown the installed version of Python 2.4 so that I own them (instead of root), chmod g+w all modules, or do something more advanced? Thanks in advance, Mark From bob at redivi.com Wed Jan 4 00:01:41 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 3 Jan 2006 15:01:41 -0800 Subject: [Pythonmac-SIG] Newbie troubles with MacPython 2.4.1 / Tiger 10.4.3 In-Reply-To: <3484DADB-7B11-4699-B0BB-F755DA5CA536@post.rwth-aachen.de> References: <3484DADB-7B11-4699-B0BB-F755DA5CA536@post.rwth-aachen.de> Message-ID: On Jan 3, 2006, at 1:27 PM, Mark Asbach wrote: > I started with a iMac G5 with all Apple updates installed. Then I > installed MacPython-OSX-2.4.1-1, directly after that I installed the > TigerPython24Fix-r2. Then I started up the PackageManager and tried > to get those modules that I need. I successfully installed PIL-1.1.5- > binary, but when I tried to install numarray-1.2.3-binary, the > install failed. Now there's an incomplete numarray on my disk that > fails to import into python2.4 with the error "no module named > numarrayall". PackageManager is no longer supported, don't use it. There's some precompiled packages at http://pythonmac.org/packages/ -bob From tcj25 at cam.ac.uk Wed Jan 4 00:08:13 2006 From: tcj25 at cam.ac.uk (Terry Jones) Date: Tue, 3 Jan 2006 23:08:13 +0000 Subject: [Pythonmac-SIG] Adding Qt designer image files to py2app Message-ID: <17339.989.494980.93992@terry.jones.tc> Apologies for a Qt question - but it is python, mac, py2app related: I have just started using Qt Designer (still under Qt 3.3.4). I've made a simple form, converted it to python via pyuic, and I can subclass it and run it. But when I do, none of the images (visible in Qt Designer) appear. I get messages: QPixmap::fromMimeSource: Cannot find pixmap "filenew" in the mime source factory QPixmap::fromMimeSource: Cannot find pixmap "fileopen" in the mime source factory QPixmap::fromMimeSource: Cannot find pixmap "filesave" in the mime source factory QPixmap::fromMimeSource: Cannot find pixmap "print" in the mime source factory I tried adding the image files (which are present in the directory where I'm saving the designer forms) to my setup.py: data_files = [ ('images', ['images/filenew', 'images/fileopen', 'images/filesave', 'images/print']) ], When I use py2app to build this, the image files are placed into dist/mainform.app/Contents/Resources/images, but when I open the app, Qt is still not finding them. Can anyone tell me what I should be doing here? Also, is the solution different for Mac apps? I.e., should my setup.py place the images elsewhere for linux, windows, etc? Thanks for any help, Terry From Chris.Barker at noaa.gov Wed Jan 4 01:37:53 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 03 Jan 2006 16:37:53 -0800 Subject: [Pythonmac-SIG] Newbie troubles with MacPython 2.4.1 / Tiger 10.4.3 In-Reply-To: <3484DADB-7B11-4699-B0BB-F755DA5CA536@post.rwth-aachen.de> References: <3484DADB-7B11-4699-B0BB-F755DA5CA536@post.rwth-aachen.de> Message-ID: <43BB18E1.20508@noaa.gov> Mark Asbach wrote: > Then I started up the PackageManager and tried > to get those modules that I need. PackageManager is no longer being maintained. You can find a lot of packages (including numarray) at: http://www.pythonmac.org/packages/ Make sure you get ones that match your OS-X/Python versions. You can use packages for OS-X 10.3 on Tiger. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From mark.asbach at post.rwth-aachen.de Wed Jan 4 11:37:12 2006 From: mark.asbach at post.rwth-aachen.de (Mark Asbach) Date: Wed, 04 Jan 2006 11:37:12 +0100 Subject: [Pythonmac-SIG] Newbie troubles with MacPython 2.4.1 / Tiger 10.4.3 In-Reply-To: <43BB18E1.20508@noaa.gov> References: <3484DADB-7B11-4699-B0BB-F755DA5CA536@post.rwth-aachen.de> <43BB18E1.20508@noaa.gov> Message-ID: Hi Christopher, hi Bob, >> Then I started up the PackageManager and tried to get those >> modules that I need. > > PackageManager is no longer being maintained. You can find a lot of > packages (including numarray) at: > > http://www.pythonmac.org/packages/ thanks a lot for the quick answers! Maybe it would be helpful to not distribute PackageManager with the MacPython installer package any longer or at least provide information on this topic in a prominent location. I've edited the MacPython wiki page at http://wiki.python.org/moin/MacPython to reflect the current status of PackageManager. Jack: as your MacPython page was the first page that I found googling for python on Mac topics, it would be nice if you found the time to update the "News" section on http://homepages.cwi.nl/~jack/macpython/ and the OS X page http://homepages.cwi.nl/~jack/macpython/macpython- osx.html to at least give some hints on where to find the current releases and modules. It's quite confusing to have mac / python documentation split over so many places on the web and it's even more confusing to find contradictory information on them. There's also a Wiki on pythonmac.org that I edited to reflect those changes. Unfortunately it contains a lot of information that is outdated / useless with the 'official unofficial' builds from http:// undefined.org/python/. I'll post a second message on MacPython documentation status. Thanks for your efforts, Mark From mark.asbach at post.rwth-aachen.de Wed Jan 4 12:08:44 2006 From: mark.asbach at post.rwth-aachen.de (Mark Asbach) Date: Wed, 04 Jan 2006 12:08:44 +0100 Subject: [Pythonmac-SIG] MacPython documentation and webpages Message-ID: Hi MacPython community, I've been a python user for two years now and a Macintosh user for even more years. However, I did'n use python on the Mac extensively as I have cross-platform projects that bring their own (unix-flavour) python install. This week I tried to get up and running with a current (2.4) installation as a framework build. Probably, this is the way to go on OS X for the common user. However, I found that information on MacPython is split over a couple of web locations, most of which feature incomplete, outdated or at least contradictory information on where to get which version of MacPython. On my quest I struggled over these places: http://www.python.org/2.4.2 -- no info on Mac, not even a link to the other resources on python.org (see below) http://www.python.org/download/download_mac.html -- most accurate place but well hidden http://www.python.org/doc/2.4.2/mac -- linking to http://www.cwi.nl/ ~jack/macpython http://www.python.org/doc/faq -- no information on python / mac but on python / windows http://wiki.python.org -- more or less current information http://www.pythonmac.org -- unstructured list but contains most of the links to current information http://pythonmac.org/wiki/FAQ -- more or less outdated information on Jack's MacPython 2.3 framework build http://undefined.org/python -- current MacPython 2.4.1 framework build and link to http://pythonmac.org/packages http://homepages.cwi.nl/~jack/macpython -- formerly the place to look but now outdated and containing no links to newer information From my point of view, it would be very helpful to concentrate MacPython knowledge and information in a central place like www.python.org / http://wiki.python.org and replace all outdated information on the other web pages by a link to that central place. Please don't take this for criticism on the original authors of the pages referenced. I do honour all the work that has gone into documenting the different stages of MacPython development. But it's a good time to overhaul and restructure the info now, since Apple ships a nearly unmodified (but partly broken) MacPython 2.3 framework build with 10.3 and 10.4. I would invest some time and effort in revising documentation, but since I'm dependent or your knowledge and experience, this is a call for discussion / participation. What is your opinion? Thanks in advance, Mark From Chris.Barker at noaa.gov Wed Jan 4 18:04:54 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 04 Jan 2006 09:04:54 -0800 Subject: [Pythonmac-SIG] MacPython documentation and webpages In-Reply-To: References: <3484DADB-7B11-4699-B0BB-F755DA5CA536@post.rwth-aachen.de> <43BB18E1.20508@noaa.gov> Message-ID: <43BC0036.70501@noaa.gov> Mark, Thank you so much for taking a lead on this: it is sorely needed. Mark Asbach wrote: > Maybe it would be helpful to not distribute PackageManager with the > MacPython installer package any longer I'm not sure the MacPython installer has anything in it that's truly useful anymore. I know I don't use anything in it. If there is useful stuff in there, maybe it could be separated out and put in the collection at pythonmac.org/packages > on this topic in a prominent location. I've edited the MacPython wiki > page at http://wiki.python.org/moin/MacPython to reflect the current > status of PackageManager. Thank you for doing that. That kind of initiative is what makes Wiki's work! > Jack: as your MacPython page was the first page that I found googling > for python on Mac topics, it would be nice if you found the time to > update the "News" section Yes Jack, please do that! I know you haven't had much time for macpython lately, but for historical reasons, your page is quite prominent. > I found that information on > MacPython is split over a couple of web locations, most of which > feature incomplete, outdated or at least contradictory information on > where to get which version of MacPython. This is so true. We really need a well laid out, definitive main page for Python on OS-X. Perhaps it can be hosted on python.org. Otherwise, pythonmac.org is a good option also, but its main page needs to be updated. Once we've got that, we can try to get as many of the other pages to point to it as possible: maybe this would be a good use for a "google bomb". I am neither the web master of any of those sites, nor a guru of MacPython, but I'll help where I can. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From lists at mostrom.pp.se Wed Jan 4 18:29:13 2006 From: lists at mostrom.pp.se (=?UTF-8?Q?Jan_Erik_Mostr=C3=B6?= =?UTF-8?Q?m?=) Date: Wed, 4 Jan 2006 18:29:13 +0100 Subject: [Pythonmac-SIG] MacPython documentation and webpages In-Reply-To: Message-ID: Mark Asbach 2006-01-04 12:08: > I would invest some time and effort in revising documentation, but > since I'm dependent or your knowledge and experience, this is a call > for discussion / participation. What is your opinion? I'm in a similar situation, I would like to spend more time working with Python but time constraints mostly forces me to do other things. Anyway, one of the problem I have when I do get the time is finding Mac specific info ... so I'm all for working for this and I'll help with what I can. Perhaps one way would be to use a CMS system like Drupal (or perhaps something that uses Python ;-) to let people work on this? jem -- Jan Erik Mostr?m, www.mostrom.pp.se From bob at redivi.com Wed Jan 4 21:51:23 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 Jan 2006 12:51:23 -0800 Subject: [Pythonmac-SIG] MacPython documentation and webpages In-Reply-To: References: Message-ID: <68D8EE46-69BA-48A3-8512-6566FD728A9C@redivi.com> On Jan 4, 2006, at 9:29 AM, Jan Erik Mostr?m wrote: > Mark Asbach 2006-01-04 12:08: > >> I would invest some time and effort in revising documentation, but >> since I'm dependent or your knowledge and experience, this is a call >> for discussion / participation. What is your opinion? > > I'm in a similar situation, I would like to spend more time working > with > Python but time constraints mostly forces me to do other things. > Anyway, one > of the problem I have when I do get the time is finding Mac > specific info ... > so I'm all for working for this and I'll help with what I can. > > Perhaps one way would be to use a CMS system like Drupal (or perhaps > something that uses Python ;-) to let people work on this? There's already two relevant wikis (python.org, pythonmac.org), what would a CMS do differently? -bob From lists at mostrom.pp.se Wed Jan 4 23:14:38 2006 From: lists at mostrom.pp.se (=?UTF-8?Q?Jan_Erik_Mostr=C3=B6?= =?UTF-8?Q?m?=) Date: Wed, 4 Jan 2006 23:14:38 +0100 Subject: [Pythonmac-SIG] MacPython documentation and webpages In-Reply-To: <68D8EE46-69BA-48A3-8512-6566FD728A9C@redivi.com> Message-ID: Bob Ippolito 2006-01-04 21:51: > There's already two relevant wikis (python.org, pythonmac.org), what > would a CMS do differently? Nothing ... I just need to read the pages and realize that there already is a wiki there ;-) jem -- Jan Erik Mostr?m, www.mostrom.pp.se From Chris.Barker at noaa.gov Thu Jan 5 00:02:50 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 04 Jan 2006 15:02:50 -0800 Subject: [Pythonmac-SIG] MacPython documentation and webpages In-Reply-To: <68D8EE46-69BA-48A3-8512-6566FD728A9C@redivi.com> References: <68D8EE46-69BA-48A3-8512-6566FD728A9C@redivi.com> Message-ID: <43BC541A.8080007@noaa.gov> Bob Ippolito wrote: > There's already two relevant wikis (python.org, pythonmac.org), what > would a CMS do differently? What it might to differently is make it easier to maintain the main front-page web site, but I don't think we need it. Bob, Are you the webmaster of pythonmac.org? If so, how is that page produced? is it static html? If so, are you open to replacing it with a page that is better suited as the primary Front-End to the Python-on-OS-X world? I think that's the best place for it. python.org only has a very simple page for each platform, it's fine as it is, if pythonmac.org had a better page If you'd like to see it improved, there seems to be some interest in this group in doing the work. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Thu Jan 5 02:12:03 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 Jan 2006 17:12:03 -0800 Subject: [Pythonmac-SIG] MacPython documentation and webpages In-Reply-To: <43BC541A.8080007@noaa.gov> References: <68D8EE46-69BA-48A3-8512-6566FD728A9C@redivi.com> <43BC541A.8080007@noaa.gov> Message-ID: On Jan 4, 2006, at 3:02 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> There's already two relevant wikis (python.org, pythonmac.org), what >> would a CMS do differently? > > What it might to differently is make it easier to maintain the main > front-page web site, but I don't think we need it. > > Bob, > > Are you the webmaster of pythonmac.org? If so, how is that page > produced? is it static html? Yes and yes. > If so, are you open to replacing it with a page that is better > suited as > the primary Front-End to the Python-on-OS-X world? I think that's the > best place for it. python.org only has a very simple page for each > platform, it's fine as it is, if pythonmac.org had a better page > > If you'd like to see it improved, there seems to be some interest in > this group in doing the work. Patches accepted ;) If anyone wants to deal with it, I'm definitely willing to dish out accounts. -bob From david.warde.farley at utoronto.ca Thu Jan 5 04:45:00 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Wed, 4 Jan 2006 22:45:00 -0500 Subject: [Pythonmac-SIG] Cleanest way to access IOKit from Python? Message-ID: <4AF6669B-6EDB-4470-AA8F-D05B2F200C6B@utoronto.ca> I've been grokking the mailing list archives and I can't seem to find anything but vague references to IOKit. Basically, I want to mess with a USB Input device (it acts kind of like a keyboard wedge) directly. It seems like the best way to do this would be through IOKit. The question is, can I do it from Python? Is my best option writing a Python module in C and then calling that from my application? Thanks, - Dave From bob at redivi.com Thu Jan 5 05:10:38 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 4 Jan 2006 20:10:38 -0800 Subject: [Pythonmac-SIG] Cleanest way to access IOKit from Python? In-Reply-To: <4AF6669B-6EDB-4470-AA8F-D05B2F200C6B@utoronto.ca> References: <4AF6669B-6EDB-4470-AA8F-D05B2F200C6B@utoronto.ca> Message-ID: On Jan 4, 2006, at 7:45 PM, David Warde-Farley wrote: > I've been grokking the mailing list archives and I can't seem to find > anything but vague references to IOKit. > > Basically, I want to mess with a USB Input device (it acts kind of > like a keyboard wedge) directly. It seems like the best way to do > this would be through IOKit. The question is, can I do it from Python? > > Is my best option writing a Python module in C and then calling that > from my application? As far as I know, that's the only thing you can do... unless there's some Objective-C framework somewhere that does what you need to do, in which case you could just use that from PyObjC without writing an extension. -bob From bray at printable.com Wed Jan 4 22:06:59 2006 From: bray at printable.com (Brian Ray) Date: Wed, 4 Jan 2006 15:06:59 -0600 Subject: [Pythonmac-SIG] MacPython documentation and webpages Message-ID: <33F54006-B0DC-485E-98CC-BD8A1D345B81@printable.com> On Jan 4, 2006, at 2:51 PM, Bob Ippolito wrote: > There's already two relevant wikis (python.org, pythonmac.org), what > would a CMS do differently? I agree these work well. I keep reminding myself to start adding stuff :) BTW, what happened to the ReStructuredText as a formatting option on pythonmac.org wiki? I tried to add some Carbon documentation a while back in ReST, but it gave me an error. Docutils? See the problem is I already have some of it in ReStructedText. Regards, Brian Ray http://brianray.chipy.org aim:brianray34 From bray at printable.com Wed Jan 4 22:06:59 2006 From: bray at printable.com (Brian Ray) Date: Wed, 4 Jan 2006 15:06:59 -0600 Subject: [Pythonmac-SIG] MacPython documentation and webpages In-Reply-To: <68D8EE46-69BA-48A3-8512-6566FD728A9C@redivi.com> References: <68D8EE46-69BA-48A3-8512-6566FD728A9C@redivi.com> Message-ID: <09BCC4B6-E2E1-4F6C-92EB-E622DE88887D@printable.com> On Jan 4, 2006, at 2:51 PM, Bob Ippolito wrote: > There's already two relevant wikis (python.org, pythonmac.org), what > would a CMS do differently? I agree these work well. I keep reminding myself to start adding stuff :) BTW, what happened to the ReStructuredText as a formatting option on pythonmac.org wiki? I tried to add some Carbon documentation a while back in ReST, but it gave me an error. Docutils? See the problem is I already have some of it in ReStructedText. Regards, Brian Ray http://brianray.chipy.org aim:brianray34 From Benjamin.Schollnick at xerox.com Thu Jan 5 15:01:39 2006 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Thu, 5 Jan 2006 09:01:39 -0500 Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) Message-ID: <266589E1B9392B4C9195CC25A07C73B90183D202@usa0300ms04.na.xerox.net> Folks, I am under the impression that PIL was bundled automatically with MacPython? Am I wrong? - Benjamin From bray at sent.com Thu Jan 5 15:59:18 2006 From: bray at sent.com (Brian Ray) Date: Thu, 5 Jan 2006 08:59:18 -0600 Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) Message-ID: <80B5E467-B5B4-421D-B190-43A7DE86298D@sent.com> On Jan 5, 2006, at 8:01 AM, Schollnick, Benjamin wrote: > > I am under the impression that PIL was bundled automatically with > MacPython? > Am I wrong? I think MacPython came with Package Manager. From Package Manager you obtain PIL. At least, that is what I read from the MacPython homepage. I never used PIL on the Mac. There are plenty of native Python binding to other (better?) imaging libraries. --Brian From bray at sent.com Thu Jan 5 16:33:25 2006 From: bray at sent.com (Brian Ray) Date: Thu, 5 Jan 2006 09:33:25 -0600 Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) In-Reply-To: <266589E1B9392B4C9195CC25A07C73B90183D202@usa0300ms04.na.xerox.net> References: <266589E1B9392B4C9195CC25A07C73B90183D202@usa0300ms04.na.xerox.net> Message-ID: <9E7C21DE-19DA-487D-B142-3050675DA144@sent.com> On Jan 5, 2006, at 8:01 AM, Schollnick, Benjamin wrote: > > I am under the impression that PIL was bundled automatically with > MacPython? > Am I wrong? > I think MacPython came with Package Manager. From Package Manager you obtain PIL. At least, that is what I read from the MacPython homepage. I never used PIL on the Mac. There are plenty of native Python binding to other (better?) imaging libraries. --Brian PS Sorry if you get multiple emails, Benjamin, I meant to reply to the list From mark.asbach at post.rwth-aachen.de Thu Jan 5 17:20:35 2006 From: mark.asbach at post.rwth-aachen.de (Mark Asbach) Date: Thu, 05 Jan 2006 17:20:35 +0100 Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) In-Reply-To: <80B5E467-B5B4-421D-B190-43A7DE86298D@sent.com> References: <80B5E467-B5B4-421D-B190-43A7DE86298D@sent.com> Message-ID: <8F53ADCD-1699-4262-8522-8281443EF6DE@post.rwth-aachen.de> Hi Benjamin, hi Brian, >> I am under the impression that PIL was bundled automatically with >> MacPython? Am I wrong? you are ;-) > I think MacPython came with Package Manager. From Package Manager you > obtain PIL. At least, that is what I read from the MacPython > homepage. I never used PIL on the Mac. There are plenty of native > Python binding to other (better?) imaging libraries. Don't do that. Instead: - install Python 2.4.1 from http://undefined.org/python - install PIL from http://www.pythonmac.org/packages Yours, Mark From Benjamin.Schollnick at xerox.com Thu Jan 5 17:29:03 2006 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Thu, 5 Jan 2006 11:29:03 -0500 Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) Message-ID: <266589E1B9392B4C9195CC25A07C73B90183D204@usa0300ms04.na.xerox.net> > Don't do that. Instead: > > - install Python 2.4.1 from http://undefined.org/python > - install PIL from http://www.pythonmac.org/packages I did that.... But it still didn't seem to work.... Then I remembered that 2.41 is /usr/local/bin/python2.4 ... The default is v2.3... So it was mostly user error.... But I don't think that PIL will help at this point... I'm attempting to add a splashscreen to an cross-platform (Windows / Mac) application... PIL appears to use Tkinter? Or at least the code that I found as a starting point is using Tkinter / PIL.... Since my application is using PythonCard / wxPython, I don't think that it would be a great idea to use anything that involves Tkinter..... Just as a lark... Here's the code that I was thinking of modeling from... """SplashScreen A splash screen that displays an image for a predefined number of milliseconds. usage tk = Tk() s = SplashScreen(tk, timeout=2000, image="python.jpg") mainloop() The main window will be shown after the timeout. requires: PIL imaging library """ from Tkinter import * try: from PIL import Image, ImageTk except ImportError: import Image, ImageTk class SplashScreen(Toplevel): def __init__(self, master, image=None, timeout=1000): """(master, image, timeout=1000) -> create a splash screen from specified image file. Keep splashscreen up for timeout milliseconds""" Toplevel.__init__(self, master, relief=RAISED, borderwidth=5) self.main = master if self.main.master != None: # Why ? self.main.master.withdraw() self.main.withdraw() self.overrideredirect(1) im = Image.open(image) self.image = ImageTk.PhotoImage(im) self.after_idle(self.centerOnScreen) self.update() self.after(timeout, self.destroy) def centerOnScreen(self): self.update_idletasks() width, height = self.width, self.height = self.image.width(), self.image.height() xmax = self.winfo_screenwidth() ymax = self.winfo_screenheight() x0 = self.x0 = (xmax - self.winfo_reqwidth()) / 2 - width/2 y0 = self.y0 = (ymax - self.winfo_reqheight()) / 2 - height/2 self.geometry("+%d+%d" % (x0, y0)) self.createWidgets() def createWidgets(self): # Need to fill in here self.canvas = Canvas(self, height=self.width, width=self.height) self.canvas.create_image(0,0, anchor=NW, image=self.image) self.canvas.pack() def destroy(self): self.main.update() self.main.deiconify() self.withdraw() if __name__ == "__main__": import os tk = Tk() l = Label(tk, text="main window") l.pack() #assert os.path.exists("python.jpg") s = SplashScreen(tk, timeout=20000, image="python.jpg") mainloop() -- Benjamin From hraban at fiee.net Thu Jan 5 18:25:22 2006 From: hraban at fiee.net (Henning Hraban Ramm) Date: Thu, 5 Jan 2006 18:25:22 +0100 Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) In-Reply-To: <266589E1B9392B4C9195CC25A07C73B90183D204@usa0300ms04.na.xerox.net> References: <266589E1B9392B4C9195CC25A07C73B90183D204@usa0300ms04.na.xerox.net> Message-ID: <41BEFA35-7B3D-4DF9-A010-BBF4012DC394@fiee.net> Am 2006-01-05 um 17:29 schrieb Schollnick, Benjamin: > But I don't think that PIL will help at this point... I'm > attempting to > add a splashscreen to an cross-platform (Windows / Mac) application... > PIL appears to use Tkinter? > Since my application is using PythonCard / wxPython, I don't think > that > it would be a great idea to use anything that involves Tkinter..... Perhaps you should have asked about SplashScreen on the wxPython users list instead about PIL on the Mac Python list. And perhaps you should've looked at som wxPython docs, e.g. the API or this: http://wiki.wxpython.org/index.cgi/SplashScreen Greetlings, Hraban From Benjamin.Schollnick at xerox.com Thu Jan 5 18:32:42 2006 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Thu, 5 Jan 2006 12:32:42 -0500 Subject: [Pythonmac-SIG] Cleanest way to access IOKit from Python? Message-ID: <266589E1B9392B4C9195CC25A07C73B90183D205@usa0300ms04.na.xerox.net> > > Basically, I want to mess with a USB Input device (it acts kind of > > like a keyboard wedge) directly. It seems like the best way > to do this > > would be through IOKit. The question is, can I do it from Python? Could you clarify what you mean by a "Keyboard wedge"? Do you mean that it shows up on the USB bus as a keyboard? If so, you may not need to do anything.... I'll double check tonight... I have a USB barcode scanner that the MOSX detects as a keyboard.... I believe that MacPython / Python can read if from a simple readline.... - Benjamin From Benjamin.Schollnick at xerox.com Thu Jan 5 18:42:49 2006 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Thu, 5 Jan 2006 12:42:49 -0500 Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) Message-ID: <266589E1B9392B4C9195CC25A07C73B90183D206@usa0300ms04.na.xerox.net> > Perhaps you should have asked about SplashScreen on the wxPython > users list > instead about PIL on the Mac Python list. > And perhaps you should've looked at som wxPython docs, e.g. the API > or this: Possibly... But.... I am not seriously researching it, and did not ask about it here... I am playing with some code... As to wxPython's Splashscreen... I was attempting to eliminate the need for wxPython during the "boot up" phase. So wxPython is not necessarily a perfect fit for the splashscreen... The application takes a few moments to start, and I want to get the splash screen as close to beginning as possible. That means not loading a lot of imported modules.. WxPython seems to be just *slightly* bulky... in that regard... If it had been possible, PIL just displaying a JPG would have been nice.. Since I don't use PIL, it was suprising to me that it required Tkinter to display an image... But in hindsight, it makes perfect since. We are not always perfect... - Benjamin From bray at sent.com Thu Jan 5 18:48:31 2006 From: bray at sent.com (Brian Ray) Date: Thu, 5 Jan 2006 11:48:31 -0600 Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) In-Reply-To: References: Message-ID: <553C6755-395A-4C0E-9E44-1992BDD21925@sent.com> On Jan 5, 2006, at 11:01 AM, Joancarles Casasin wrote: > > Could you point to some of these imaging libraries alternative to PIL? Well this is kind of a broad topic. And it depends on what your trying to do. But a short list: -- a Python Binding for Quartz . -- anti-grain has Tk, Wx, and PIL backends, as well. -- Python GD . -- Python OpenGL . I am sure I left many out. From takeme2your at rocketmail.com Thu Jan 5 18:18:12 2006 From: takeme2your at rocketmail.com (U n d e r a c h i e v e r) Date: Thu, 05 Jan 2006 17:18:12 +0000 Subject: [Pythonmac-SIG] Newbie troubles with MacPython 2.4.1 / Tiger 10.4.3 References: <3484DADB-7B11-4699-B0BB-F755DA5CA536@post.rwth-aachen.de> Message-ID: On 3/1/06 23:01, in article A34546EF-9909-4BB7-867F-313F5834B14E at redivi.com, "Bob Ippolito" wrote: > > On Jan 3, 2006, at 1:27 PM, Mark Asbach wrote: > >> I started with a iMac G5 with all Apple updates installed. Then I >> installed MacPython-OSX-2.4.1-1, directly after that I installed the >> TigerPython24Fix-r2. Then I started up the PackageManager and tried >> to get those modules that I need. I successfully installed PIL-1.1.5- >> binary, but when I tried to install numarray-1.2.3-binary, the >> install failed. Now there's an incomplete numarray on my disk that >> fails to import into python2.4 with the error "no module named >> numarrayall". > > PackageManager is no longer supported, don't use it. There's some > precompiled packages at http://pythonmac.org/packages/ I've found using darwinports, rather than Apple's bundled, python gives me access to the darwinports packages for python. Very handy. But lacking a few 'maccy' things like the objectiveC module. To install, use the downloads/instructions here: http://darwinports.org A handy list of python modules is here: http://python.darwinports.com/ I like it, YMMV. -- takeme2your at rocketmail.com U n d e r a c h i e v e r From Chris.Barker at noaa.gov Thu Jan 5 20:22:20 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 05 Jan 2006 11:22:20 -0800 Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) In-Reply-To: <553C6755-395A-4C0E-9E44-1992BDD21925@sent.com> References: <553C6755-395A-4C0E-9E44-1992BDD21925@sent.com> Message-ID: <43BD71EC.3070602@noaa.gov> Brian Ray wrote: > -- a Python Binding for Quartz . Now that may work for the OP's original goal: getting up a splash screen before initializing wx. I'd be interested to hear it it does. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Benjamin.Schollnick at xerox.com Thu Jan 5 20:32:52 2006 From: Benjamin.Schollnick at xerox.com (Schollnick, Benjamin) Date: Thu, 5 Jan 2006 14:32:52 -0500 Subject: [Pythonmac-SIG] SplashScreens... Message-ID: <266589E1B9392B4C9195CC25A07C73B90183D207@usa0300ms04.na.xerox.net> > > -- a Python Binding for Quartz . > > Now that may work for the OP's original goal: getting up a > splash screen before initializing wx. > > I'd be interested to hear it it does. I'll take a look and let you know. The only issue that might prevent me from exploring it is that this is a Cross-platform Windows/Macintosh application.... And since Quartz does not exist on the Windows side, I would have to explore a different solution there... - Benjamin From bob at redivi.com Thu Jan 5 21:45:43 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 5 Jan 2006 12:45:43 -0800 Subject: [Pythonmac-SIG] SplashScreens... In-Reply-To: <266589E1B9392B4C9195CC25A07C73B90183D207@usa0300ms04.na.xerox.net> References: <266589E1B9392B4C9195CC25A07C73B90183D207@usa0300ms04.na.xerox.net> Message-ID: <3CCA1727-042B-4EC5-B25B-3CEB35F55632@redivi.com> On Jan 5, 2006, at 11:32 AM, Schollnick, Benjamin wrote: >>> -- a Python Binding for Quartz . >> >> Now that may work for the OP's original goal: getting up a >> splash screen before initializing wx. >> >> I'd be interested to hear it it does. > > I'll take a look and let you know. > > The only issue that might prevent me from > exploring it is that this is a Cross-platform Windows/Macintosh > application.... > > And since Quartz does not exist on the Windows side, I would have > to explore a different solution there... It won't work anyway. 1. It can't display anything, it's for developing image pipelines 2. That Quartz binding only exists for Python 2.3.x and is closed source -bob From janssen at parc.com Thu Jan 5 22:58:09 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 5 Jan 2006 13:58:09 PST Subject: [Pythonmac-SIG] PIL for Python 2.4x? (Mac OS 2.4.x) In-Reply-To: Your message of "Thu, 05 Jan 2006 11:22:20 PST." <43BD71EC.3070602@noaa.gov> Message-ID: <06Jan5.135810pst."58633"@synergy1.parc.xerox.com> Cairo seems to have Quartz bindings, as well. And there's pycairo [http://cairographics.org/pycairo]. Bill From fairwinds at eastlink.ca Sun Jan 8 01:13:04 2006 From: fairwinds at eastlink.ca (David Pratt) Date: Sat, 07 Jan 2006 20:13:04 -0400 Subject: [Pythonmac-SIG] MacPython 2.4.1 over Mac's 10.3.9's persistent Python 2.3 Message-ID: <43C05910.1080007@eastlink.ca> Hi there. I recently upgraded my machine's OS from 10.2.8 (jaguar) to 10.3.9 (panther). I removed my previous 2.3.5 python mac install by removing Python.framework and MacPython-2.3 from Applications. I also removed python pythonw python2.3 and pythonw2.3 from /usr/local/bin. I installed PantherPythonFix.dmg and then installed MacPython-OSX-2.4.1-1.dmg. Install went fine - no errors. However, when I open a terminal I and type python or pythonw at the prompt I still get the Apple build of python after restarting and opening terminal. Can someone point out what the problem could be. This is quite frustrating since I remember the Jaguar install being very smooth and effortless. Regards, David From bob at redivi.com Sun Jan 8 01:21:29 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 7 Jan 2006 16:21:29 -0800 Subject: [Pythonmac-SIG] MacPython 2.4.1 over Mac's 10.3.9's persistent Python 2.3 In-Reply-To: <43C05910.1080007@eastlink.ca> References: <43C05910.1080007@eastlink.ca> Message-ID: <1165F3DB-7F33-47D7-88E7-CE3A8656E325@redivi.com> On Jan 7, 2006, at 4:13 PM, David Pratt wrote: > Hi there. I recently upgraded my machine's OS from 10.2.8 (jaguar) to > 10.3.9 (panther). I removed my previous 2.3.5 python mac install by > removing Python.framework and MacPython-2.3 from Applications. I also > removed python pythonw python2.3 and pythonw2.3 from /usr/local/bin. I > installed PantherPythonFix.dmg and then installed > MacPython-OSX-2.4.1-1.dmg. Install went fine - no errors. > > However, when I open a terminal I and type python or pythonw at the > prompt I still get the Apple build of python after restarting and > opening terminal. Can someone point out what the problem could be. > This > is quite frustrating since I remember the Jaguar install being very > smooth and effortless. Add /usr/local/bin to your PATH environment variable. Installation for Jaguar was the same. http://tinyurl.com/cwjc8 -bob From fairwinds at eastlink.ca Sun Jan 8 02:00:42 2006 From: fairwinds at eastlink.ca (David Pratt) Date: Sat, 07 Jan 2006 21:00:42 -0400 Subject: [Pythonmac-SIG] MacPython 2.4.1 over Mac's 10.3.9's persistent Python 2.3 In-Reply-To: <1165F3DB-7F33-47D7-88E7-CE3A8656E325@redivi.com> References: <43C05910.1080007@eastlink.ca> <1165F3DB-7F33-47D7-88E7-CE3A8656E325@redivi.com> Message-ID: <43C0643A.40302@eastlink.ca> Hi Bob. I have this path is in my .cshrc where I am setting paths for my home. This seemed to work fine for Jaguar but I guess not for Panther. [dp_mac450:~] davidpra% python2.4 Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> [dp_mac450:~] davidpra% python Python 2.3 (#1, Sep 13 2003, 00:49:11) [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> So getting python2.4, just not the right version from python or pythonw at command line as with macpython 2.3. I'll try setting path using the other method from the link you provided using the ~/.MacOSX/environment.plist method. Hopefully this will do the trick. Many thanks. Regards, David Bob Ippolito wrote: > > On Jan 7, 2006, at 4:13 PM, David Pratt wrote: > >> Hi there. I recently upgraded my machine's OS from 10.2.8 (jaguar) to >> 10.3.9 (panther). I removed my previous 2.3.5 python mac install by >> removing Python.framework and MacPython-2.3 from Applications. I also >> removed python pythonw python2.3 and pythonw2.3 from /usr/local/bin. I >> installed PantherPythonFix.dmg and then installed >> MacPython-OSX-2.4.1-1.dmg. Install went fine - no errors. >> >> However, when I open a terminal I and type python or pythonw at the >> prompt I still get the Apple build of python after restarting and >> opening terminal. Can someone point out what the problem could be. This >> is quite frustrating since I remember the Jaguar install being very >> smooth and effortless. > > > Add /usr/local/bin to your PATH environment variable. Installation for > Jaguar was the same. > > http://tinyurl.com/cwjc8 > > -bob > From bob at redivi.com Sun Jan 8 02:21:51 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 7 Jan 2006 17:21:51 -0800 Subject: [Pythonmac-SIG] MacPython 2.4.1 over Mac's 10.3.9's persistent Python 2.3 In-Reply-To: <43C0643A.40302@eastlink.ca> References: <43C05910.1080007@eastlink.ca> <1165F3DB-7F33-47D7-88E7-CE3A8656E325@redivi.com> <43C0643A.40302@eastlink.ca> Message-ID: Given that, you must be placing /usr/local/bin after /usr/bin in your PATH. That is not the correct thing to do for the behavior you want. e.g. you currently have this: export PATH=$PATH:/usr/local/bin but you want this instead: export PATH=/usr/local/bin:$PATH -bob On Jan 7, 2006, at 5:00 PM, David Pratt wrote: > Hi Bob. I have this path is in my .cshrc where I am setting paths > for my > home. This seemed to work fine for Jaguar but I guess not for Panther. > > [dp_mac450:~] davidpra% python2.4 > Python 2.4.1 (#2, Mar 31 2005, 00:05:10) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> > [dp_mac450:~] davidpra% python > Python 2.3 (#1, Sep 13 2003, 00:49:11) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin > Type "help", "copyright", "credits" or "license" for more information. >>>> > > So getting python2.4, just not the right version from python or > pythonw > at command line as with macpython 2.3. I'll try setting path using the > other method from the link you provided using the > ~/.MacOSX/environment.plist method. Hopefully this will do the trick. > > Many thanks. > > Regards, > David > > Bob Ippolito wrote: >> >> On Jan 7, 2006, at 4:13 PM, David Pratt wrote: >> >>> Hi there. I recently upgraded my machine's OS from 10.2.8 >>> (jaguar) to >>> 10.3.9 (panther). I removed my previous 2.3.5 python mac install by >>> removing Python.framework and MacPython-2.3 from Applications. I >>> also >>> removed python pythonw python2.3 and pythonw2.3 from /usr/local/ >>> bin. I >>> installed PantherPythonFix.dmg and then installed >>> MacPython-OSX-2.4.1-1.dmg. Install went fine - no errors. >>> >>> However, when I open a terminal I and type python or pythonw at the >>> prompt I still get the Apple build of python after restarting and >>> opening terminal. Can someone point out what the problem could >>> be. This >>> is quite frustrating since I remember the Jaguar install being very >>> smooth and effortless. >> >> >> Add /usr/local/bin to your PATH environment variable. >> Installation for >> Jaguar was the same. >> >> http://tinyurl.com/cwjc8 >> >> -bob >> > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From fairwinds at eastlink.ca Sun Jan 8 03:16:51 2006 From: fairwinds at eastlink.ca (David Pratt) Date: Sat, 07 Jan 2006 22:16:51 -0400 Subject: [Pythonmac-SIG] MacPython 2.4.1 over Mac's 10.3.9's persistent Python 2.3 In-Reply-To: References: <43C05910.1080007@eastlink.ca> <1165F3DB-7F33-47D7-88E7-CE3A8656E325@redivi.com> <43C0643A.40302@eastlink.ca> Message-ID: <43C07613.1030008@eastlink.ca> Right. I'm good to go! Many thanks for your help Bob :-) Regards, David Bob Ippolito wrote: > Given that, you must be placing /usr/local/bin after /usr/bin in your > PATH. That is not the correct thing to do for the behavior you want. > > e.g. you currently have this: > > export PATH=$PATH:/usr/local/bin > > but you want this instead: > > export PATH=/usr/local/bin:$PATH > > -bob > > On Jan 7, 2006, at 5:00 PM, David Pratt wrote: > >> Hi Bob. I have this path is in my .cshrc where I am setting paths for my >> home. This seemed to work fine for Jaguar but I guess not for Panther. >> >> [dp_mac450:~] davidpra% python2.4 >> Python 2.4.1 (#2, Mar 31 2005, 00:05:10) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>>>> >> [dp_mac450:~] davidpra% python >> Python 2.3 (#1, Sep 13 2003, 00:49:11) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin >> Type "help", "copyright", "credits" or "license" for more information. >> >>>>> >> >> So getting python2.4, just not the right version from python or pythonw >> at command line as with macpython 2.3. I'll try setting path using the >> other method from the link you provided using the >> ~/.MacOSX/environment.plist method. Hopefully this will do the trick. >> >> Many thanks. >> >> Regards, >> David >> >> Bob Ippolito wrote: >> >>> >>> On Jan 7, 2006, at 4:13 PM, David Pratt wrote: >>> >>>> Hi there. I recently upgraded my machine's OS from 10.2.8 (jaguar) to >>>> 10.3.9 (panther). I removed my previous 2.3.5 python mac install by >>>> removing Python.framework and MacPython-2.3 from Applications. I also >>>> removed python pythonw python2.3 and pythonw2.3 from /usr/local/ bin. I >>>> installed PantherPythonFix.dmg and then installed >>>> MacPython-OSX-2.4.1-1.dmg. Install went fine - no errors. >>>> >>>> However, when I open a terminal I and type python or pythonw at the >>>> prompt I still get the Apple build of python after restarting and >>>> opening terminal. Can someone point out what the problem could be. >>>> This >>>> is quite frustrating since I remember the Jaguar install being very >>>> smooth and effortless. >>> >>> >>> >>> Add /usr/local/bin to your PATH environment variable. Installation >>> for >>> Jaguar was the same. >>> >>> http://tinyurl.com/cwjc8 >>> >>> -bob >>> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > From smithsm at samuelsmith.org Mon Jan 9 05:32:04 2006 From: smithsm at samuelsmith.org (Samuel M. Smith) Date: Sun, 8 Jan 2006 21:32:04 -0700 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? Message-ID: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> I downloaded Python-2.4.2.tgz expanded it into the directory Python-2.4.2 I cd in python-2.4.2 and run ./configure --enable--framework make this creates a file in the python-2.4.2 directory called python.exe if I run ./python.exe I get the following prompt Python 2.4.1 (#2, Mar 31 2005, 00:05:10) [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin Type "help", "copyright", "credits" or "license" for more information. If I do sudo make install I still get python 2.4.1 prompt Is this an error? What is happening here. Why don't I get 2.4.2 ********************************************************************** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84043 801-768-2768 voice 801-768-2769 fax ********************************************************************** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ********************************************************************** From smithsm at samuelsmith.org Mon Jan 9 05:44:47 2006 From: smithsm at samuelsmith.org (Samuel M. Smith) Date: Sun, 8 Jan 2006 21:44:47 -0700 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> Message-ID: <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> On 08 Jan, 2006, at 21:32, Samuel M. Smith wrote: > I downloaded Python-2.4.2.tgz expanded it into the directory > Python-2.4.2 > I cd in python-2.4.2 and run > > ./configure --enable--framework > make excuse the typo here I actually ran ./configure --enable-framework I have os x 10.4.3 I had previously installed 2.4.1 using the package installer on undefined.org > > this creates a file in the python-2.4.2 directory called python.exe > if I run > ./python.exe > I get the following prompt > Python 2.4.1 (#2, Mar 31 2005, 00:05:10) > [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > > If I do sudo make install I still get python 2.4.1 prompt > Is this an error? > What is happening here. Why don't I get 2.4.2 > > > > ********************************************************************** > Samuel M. Smith Ph.D. > 2966 Fort Hill Road > Eagle Mountain, Utah 84043 > 801-768-2768 voice > 801-768-2769 fax > ********************************************************************** > "The greatest source of failure and unhappiness in the world is > giving up what we want most for what we want at the moment" > ********************************************************************** > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig ********************************************************************** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84043 801-768-2768 voice 801-768-2769 fax ********************************************************************** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ********************************************************************** From bob at redivi.com Mon Jan 9 06:12:22 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 8 Jan 2006 21:12:22 -0800 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> Message-ID: <1206DDBB-C9A4-4BE9-8544-C29A66DBB443@redivi.com> On Jan 8, 2006, at 8:44 PM, Samuel M. Smith wrote: > > On 08 Jan, 2006, at 21:32, Samuel M. Smith wrote: > >> I downloaded Python-2.4.2.tgz expanded it into the directory >> Python-2.4.2 >> I cd in python-2.4.2 and run >> >> ./configure --enable--framework >> make > > excuse the typo here I actually ran > ./configure --enable-framework > > I have os x 10.4.3 I had previously installed 2.4.1 using the package > installer on undefined.org > >> >> this creates a file in the python-2.4.2 directory called python.exe >> if I run >> ./python.exe >> I get the following prompt >> Python 2.4.1 (#2, Mar 31 2005, 00:05:10) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin >> Type "help", "copyright", "credits" or "license" for more >> information. >> >> If I do sudo make install I still get python 2.4.1 prompt >> Is this an error? >> What is happening here. Why don't I get 2.4.2 You did get 2.4.2, but it's dynamically linking to /Library/ Frameworks/Python.framework because that's where it's going to install to. try this: env DYLD_FRAMEWORK_PATH=. ./python.exe -bob From smithsm at samuelsmith.org Mon Jan 9 06:20:38 2006 From: smithsm at samuelsmith.org (Samuel M. Smith) Date: Sun, 8 Jan 2006 22:20:38 -0700 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> Message-ID: <4426B82A-0969-466E-BBD1-D9735672BCBA@samuelsmith.org> I next tried removing the old 2.4.1 installation by changing the name of the directory /library/frameworks/python.framework/versions/2.4 to 2.4a I then did a ./configure and make I tried to run ./python.exe and got the following error AlBook:/install/python/macpython/python2.4.2/python-2.4.2 smithsm$ ./ python.exe dyld: Library not loaded: /Library/Frameworks/Python.framework/ Versions/2.4/Python Referenced from: /Install/Python/MacPython/Python2.4.2/ Python-2.4.2/./python.exe Reason: image not found Trace/BPT trap so apparently I can't run the python.exe without the framework fully installed so I did sudo make install and got this error Framework build: use "make frameworkinstall" in stead of "make install" make: *** [altbininstall] Error 1 so I tried sudo make frameworkinstall and this worked. So the real way to build 2.4.2 is first removed any previous 2.4.x builds then run ./configure --enable-framework make sudo make frameworkinstall this is different from every instruction I have seen. Nobody has ever said use make framworkinstall. So either everyone else is wrong or I am missing something important. Also it really is a pain to remove the old installation since I then have to reinstall every singe package that I installed in the previous 2.4.x installation. I thought the whole ideas was that I could upgrade to a newer 2.4.x without removing the old one. Help would be much appreciated! Has no one else actually installed 2.4.2 on os x 10.4.3? On 08 Jan, 2006, at 21:44, Samuel M. Smith wrote: > > On 08 Jan, 2006, at 21:32, Samuel M. Smith wrote: > >> I downloaded Python-2.4.2.tgz expanded it into the directory >> Python-2.4.2 >> I cd in python-2.4.2 and run >> >> ./configure --enable--framework >> make > > excuse the typo here I actually ran > ./configure --enable-framework > > I have os x 10.4.3 I had previously installed 2.4.1 using the package > installer on undefined.org > >> >> this creates a file in the python-2.4.2 directory called python.exe >> if I run >> ./python.exe >> I get the following prompt >> Python 2.4.1 (#2, Mar 31 2005, 00:05:10) >> [GCC 3.3 20030304 (Apple Computer, Inc. build 1666)] on darwin >> Type "help", "copyright", "credits" or "license" for more >> information. >> >> If I do sudo make install I still get python 2.4.1 prompt >> Is this an error? >> What is happening here. Why don't I get 2.4.2 >> >> >> >> ********************************************************************* >> * >> Samuel M. Smith Ph.D. >> 2966 Fort Hill Road >> Eagle Mountain, Utah 84043 >> 801-768-2768 voice >> 801-768-2769 fax >> ********************************************************************* >> * >> "The greatest source of failure and unhappiness in the world is >> giving up what we want most for what we want at the moment" >> ********************************************************************* >> * >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > ********************************************************************** > Samuel M. Smith Ph.D. > 2966 Fort Hill Road > Eagle Mountain, Utah 84043 > 801-768-2768 voice > 801-768-2769 fax > ********************************************************************** > "The greatest source of failure and unhappiness in the world is > giving up what we want most for what we want at the moment" > ********************************************************************** > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig ********************************************************************** Samuel M. Smith Ph.D. 2966 Fort Hill Road Eagle Mountain, Utah 84043 801-768-2768 voice 801-768-2769 fax ********************************************************************** "The greatest source of failure and unhappiness in the world is giving up what we want most for what we want at the moment" ********************************************************************** From smithsm at samuelsmith.org Mon Jan 9 06:25:26 2006 From: smithsm at samuelsmith.org (Samuel M. Smith) Date: Sun, 8 Jan 2006 22:25:26 -0700 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <1206DDBB-C9A4-4BE9-8544-C29A66DBB443@redivi.com> References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> <1206DDBB-C9A4-4BE9-8544-C29A66DBB443@redivi.com> Message-ID: > > You did get 2.4.2, but it's dynamically linking to /Library/ > Frameworks/Python.framework because that's where it's going to > install to. > > try this: > > env DYLD_FRAMEWORK_PATH=. ./python.exe > but shouldn't that dynamic link have been obviated once I did a sudo make install? At that point shouldn't Python.framework now have the 2.4.2 executable? From sw at wordtech-software.com Mon Jan 9 06:29:55 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Mon, 09 Jan 2006 00:29:55 -0500 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <4426B82A-0969-466E-BBD1-D9735672BCBA@samuelsmith.org> References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> <4426B82A-0969-466E-BBD1-D9735672BCBA@samuelsmith.org> Message-ID: <43C1F4D3.5020901@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Samuel M. Smith wrote: > I next tried removing the old 2.4.1 installation by changing the name > of the directory > /library/frameworks/python.framework/versions/2.4 to 2.4a > > I then did a ./configure and make > I tried to run ./python.exe and got the following error > AlBook:/install/python/macpython/python2.4.2/python-2.4.2 smithsm$ ./ > python.exe > dyld: Library not loaded: /Library/Frameworks/Python.framework/ > Versions/2.4/Python > Referenced from: /Install/Python/MacPython/Python2.4.2/ > Python-2.4.2/./python.exe > Reason: image not found > Trace/BPT trap > > so apparently I can't run the python.exe without the framework fully > installed so I did > sudo make install > and got this error > > Framework build: use "make frameworkinstall" in stead of "make install" > make: *** [altbininstall] Error 1 > > so I tried > sudo make frameworkinstall > > and this worked. > > So the real way to build 2.4.2 is first removed any previous 2.4.x > builds then > run > ./configure --enable-framework > make > sudo make frameworkinstall > > this is different from every instruction I have seen. Nobody has ever > said use make framworkinstall. > So either everyone else is wrong or I am missing something important. > Aren't the instructions about the "makeframework install" somewhere in the Python source tree (a README or something like that)? I remember running into this issue with 2.4.2, then consulting docs somewhere in the code package I downloaded, then trying again successfully. The buildd process even rebuilt all the packages I had installed in the site-packages directory. Unexpected, but not an issue. - -- Cheers, Kevin Walzer, PhD WordTech Software - "Tame the Terminal" http://www.wordtech-software.com sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDwfTSJmdQs+6YVcoRAoXaAJ4h+nPbG1i8QhvRQYjDgD617urIawCeNfpM sVCk1rU4WU9WuhZTNEJ4g5c= =6tcw -----END PGP SIGNATURE----- From bob at redivi.com Mon Jan 9 06:54:37 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 8 Jan 2006 21:54:37 -0800 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <43C1F4D3.5020901@wordtech-software.com> References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> <4426B82A-0969-466E-BBD1-D9735672BCBA@samuelsmith.org> <43C1F4D3.5020901@wordtech-software.com> Message-ID: <9407E9A8-ABC4-4EAA-9AA6-F8AE2BC6C6B1@redivi.com> On Jan 8, 2006, at 9:29 PM, Kevin Walzer wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Samuel M. Smith wrote: >> I next tried removing the old 2.4.1 installation by changing the name >> of the directory >> /library/frameworks/python.framework/versions/2.4 to 2.4a >> >> I then did a ./configure and make >> I tried to run ./python.exe and got the following error >> AlBook:/install/python/macpython/python2.4.2/python-2.4.2 smithsm$ ./ >> python.exe >> dyld: Library not loaded: /Library/Frameworks/Python.framework/ >> Versions/2.4/Python >> Referenced from: /Install/Python/MacPython/Python2.4.2/ >> Python-2.4.2/./python.exe >> Reason: image not found >> Trace/BPT trap >> >> so apparently I can't run the python.exe without the framework fully >> installed so I did >> sudo make install >> and got this error I'll repeat myself and be more explicit about why I said what I said... You must run it with DYLD_FRAMEWORK_PATH=. if it's not installed yet. It has *absolutely nothing* to do with the fact that there is an existing framework somewhere else. In other words: it's not linked wrong, you ran it incorrectly. >> Framework build: use "make frameworkinstall" in stead of "make >> install" >> make: *** [altbininstall] Error 1 >> >> so I tried >> sudo make frameworkinstall >> >> and this worked. >> >> So the real way to build 2.4.2 is first removed any previous 2.4.x >> builds then >> run >> ./configure --enable-framework >> make >> sudo make frameworkinstall >> >> this is different from every instruction I have seen. Nobody has ever >> said use make framworkinstall. >> So either everyone else is wrong or I am missing something important. >> > Aren't the instructions about the "makeframework install" somewhere in > the Python source tree (a README or something like that)? I remember > running into this issue with 2.4.2, then consulting docs somewhere in > the code package I downloaded, then trying again successfully. The > buildd process even rebuilt all the packages I had installed in the > site-packages directory. Unexpected, but not an issue. Yes, that is documented (probably obscurely) and it's the right way to install a framework build. -bob From smithsm at samuelsmith.org Mon Jan 9 06:58:08 2006 From: smithsm at samuelsmith.org (Samuel M. Smith) Date: Sun, 8 Jan 2006 22:58:08 -0700 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <43C1F4D3.5020901@wordtech-software.com> References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> <4426B82A-0969-466E-BBD1-D9735672BCBA@samuelsmith.org> <43C1F4D3.5020901@wordtech-software.com> Message-ID: <1DA6B205-10DB-4911-A4BE-C9B147A23686@samuelsmith.org> >> > Aren't the instructions about the "makeframework install" somewhere in > the Python source tree (a README or something like that)? I remember > running into this issue with 2.4.2, then consulting docs somewhere in > the code package I downloaded, then trying again successfully. The > buildd process even rebuilt all the packages I had installed in the > site-packages directory. Unexpected, but not an issue. > Could be, but at least two posts on this and the main python board said that python builds out of the box to Quote "You'll have to build it yourself. That's not very hard, extract the tar archive and run: cd Python-2.4.2 ./configure --enable-framework make sudo make install " Anyway I restored my old 2.4.1 installation and then did a sudo makeframework install and that worked and preserved my old installed packages. Thats what I get for taking the message boards to literally. From ronaldoussoren at mac.com Mon Jan 9 09:31:47 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 09 Jan 2006 09:31:47 +0100 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <9407E9A8-ABC4-4EAA-9AA6-F8AE2BC6C6B1@redivi.com> References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> <4426B82A-0969-466E-BBD1-D9735672BCBA@samuelsmith.org> <43C1F4D3.5020901@wordtech-software.com> <9407E9A8-ABC4-4EAA-9AA6-F8AE2BC6C6B1@redivi.com> Message-ID: <5544313.1136795507686.JavaMail.ronaldoussoren@mac.com> On Monday, January 09, 2006, at 06:55AM, Bob Ippolito wrote: > >On Jan 8, 2006, at 9:29 PM, Kevin Walzer wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Samuel M. Smith wrote: >>> I next tried removing the old 2.4.1 installation by changing the name >>> of the directory >>> /library/frameworks/python.framework/versions/2.4 to 2.4a >>> >>> I then did a ./configure and make >>> I tried to run ./python.exe and got the following error >>> AlBook:/install/python/macpython/python2.4.2/python-2.4.2 smithsm$ ./ >>> python.exe >>> dyld: Library not loaded: /Library/Frameworks/Python.framework/ >>> Versions/2.4/Python >>> Referenced from: /Install/Python/MacPython/Python2.4.2/ >>> Python-2.4.2/./python.exe >>> Reason: image not found >>> Trace/BPT trap >>> >>> so apparently I can't run the python.exe without the framework fully >>> installed so I did >>> sudo make install >>> and got this error > >I'll repeat myself and be more explicit about why I said what I said... > >You must run it with DYLD_FRAMEWORK_PATH=. if it's not installed >yet. It has *absolutely nothing* to do with the fact that there is >an existing framework somewhere else. In other words: it's not >linked wrong, you ran it incorrectly. > >>> Framework build: use "make frameworkinstall" in stead of "make >>> install" >>> make: *** [altbininstall] Error 1 >>> >>> so I tried >>> sudo make frameworkinstall >>> >>> and this worked. >>> >>> So the real way to build 2.4.2 is first removed any previous 2.4.x >>> builds then >>> run >>> ./configure --enable-framework >>> make >>> sudo make frameworkinstall >>> >>> this is different from every instruction I have seen. Nobody has ever >>> said use make framworkinstall. >>> So either everyone else is wrong or I am missing something important. >>> >> Aren't the instructions about the "makeframework install" somewhere in >> the Python source tree (a README or something like that)? I remember >> running into this issue with 2.4.2, then consulting docs somewhere in >> the code package I downloaded, then trying again successfully. The >> buildd process even rebuilt all the packages I had installed in the >> site-packages directory. Unexpected, but not an issue. > >Yes, that is documented (probably obscurely) and it's the right way >to install a framework build. Its documented in Mac/OSX/README (the frameworkinstall bit, not DYLD_FRAMEWORK_PATH) Ronald > >-bob > >_______________________________________________ >Pythonmac-SIG maillist - Pythonmac-SIG at python.org >http://mail.python.org/mailman/listinfo/pythonmac-sig > > From jmillr at umich.edu Mon Jan 9 16:19:14 2006 From: jmillr at umich.edu (John Miller) Date: Mon, 9 Jan 2006 10:19:14 -0500 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: References: Message-ID: <2887B999-3310-4CDC-A8AB-9773AD4265B9@umich.edu> Okay, being dense here: these instructions: ''' cd Python-2.4.2 ./configure --enable-framework make sudo make frameworkinstall ''' make no mention of DYLD_FRAMEWORK_PATH. So my question is, where does it fit into the above directions? Thanks! John Miller From bob at redivi.com Mon Jan 9 23:33:57 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 9 Jan 2006 14:33:57 -0800 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <2887B999-3310-4CDC-A8AB-9773AD4265B9@umich.edu> References: <2887B999-3310-4CDC-A8AB-9773AD4265B9@umich.edu> Message-ID: On Jan 9, 2006, at 7:19 AM, John Miller wrote: > Okay, being dense here: these instructions: > > ''' > cd Python-2.4.2 > ./configure --enable-framework > make > sudo make frameworkinstall > ''' > > make no mention of DYLD_FRAMEWORK_PATH. So my question is, where does > it fit into the above directions? Thanks! It doesn't. However, Samuel was trying to run python in-place before installing. That's where it fits in. -bob From glassfordm at hotmail.com Tue Jan 10 23:16:51 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Tue, 10 Jan 2006 17:16:51 -0500 Subject: [Pythonmac-SIG] PyObjC: Errors initializing NSAttributedString using initWithHTML Message-ID: When trying to initialize an NSAttributedString like this: attributedString = AppKit.NSAttributedString.alloc().initWithHTML_baseURL_documentAttributes_(data, url, None) I get the error "TypeError: Need 2 arguments, got 3", although the documentation makes it pretty clear that there are in fact 3 arguments. Similarly, attributedString = AppKit.NSAttributedString.alloc().initWithHTML_documentAttributes_(data, url) gives the error "TypeError: Need 1 arguments, got 2", although the documentation makes it pretty clear that there are in fact 2 arguments. I've looked at the signatures for the function in PyObjC's _FoundationSignatures.py, but wasn't able to interpret them well enough to help me. For reference, they are: setSignatureForSelector("NSAttributedString", "initWithHTML:baseURL:documentAttributes:", "@0 at 4:8 at 12@16o^@20") setSignatureForSelector("NSAttributedString", "initWithHTML:documentAttributes:", "@@:@o^@") Can someone more familiar with what these mean help me out? Thanks, Mike From bob at redivi.com Tue Jan 10 23:29:37 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 10 Jan 2006 14:29:37 -0800 Subject: [Pythonmac-SIG] PyObjC: Errors initializing NSAttributedString using initWithHTML In-Reply-To: References: Message-ID: On Jan 10, 2006, at 2:16 PM, Michael Glassford wrote: > When trying to initialize an NSAttributedString like this: > > attributedString = > AppKit.NSAttributedString.alloc > ().initWithHTML_baseURL_documentAttributes_(data, > url, None) > > I get the error "TypeError: Need 2 arguments, got 3", although the > documentation makes it pretty clear that there are in fact 3 > arguments. > Similarly, > > attributedString = > AppKit.NSAttributedString.alloc().initWithHTML_documentAttributes_ > (data, > url) > > gives the error "TypeError: Need 1 arguments, got 2", although the > documentation makes it pretty clear that there are in fact 2 > arguments. The reason is because the last parameter is an output parameter. It's part of the result. attributedString, attributes = AppKit.NSAttributedString.alloc ().initWithHTML_baseURL_documentAttributes_(data, url) attributedString, attributes = AppKit.NSAttributedString.alloc ().initWithHTML_documentAttributes_(data) This behavior is definitely documented.. I don't remember exactly where, don't have a checkout on me. -bob From ronaldoussoren at mac.com Wed Jan 11 07:53:26 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 11 Jan 2006 07:53:26 +0100 Subject: [Pythonmac-SIG] PyObjC: Errors initializing NSAttributedString using initWithHTML In-Reply-To: References: Message-ID: <923B1893-87FB-4F54-A7D7-426DBAD39473@mac.com> On 10-jan-2006, at 23:29, Bob Ippolito wrote: > > This behavior is definitely documented.. I don't remember exactly > where, don't have a checkout on me. It's documented in this section: http://pyobjc.sourceforge.net/doc/ intro.php#messages-and-functions. Ronald > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From glassfordm at hotmail.com Wed Jan 11 15:52:58 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Wed, 11 Jan 2006 09:52:58 -0500 Subject: [Pythonmac-SIG] PyObjC: Errors initializing NSAttributedString using initWithHTML In-Reply-To: References: Message-ID: Bob Ippolito wrote: > On Jan 10, 2006, at 2:16 PM, Michael Glassford wrote: > > >>When trying to initialize an NSAttributedString like this: >> >>attributedString = >>AppKit.NSAttributedString.alloc >>().initWithHTML_baseURL_documentAttributes_(data, >>url, None) >> >>I get the error "TypeError: Need 2 arguments, got 3", although the >>documentation makes it pretty clear that there are in fact 3 >>arguments. >>Similarly, >> >>attributedString = >>AppKit.NSAttributedString.alloc().initWithHTML_documentAttributes_ >>(data, >>url) >> >>gives the error "TypeError: Need 1 arguments, got 2", although the >>documentation makes it pretty clear that there are in fact 2 >>arguments. > > > The reason is because the last parameter is an output parameter. > It's part of the result. That's the thing I hadn't noticed. Thanks for pointing it out--I've got it working now. Mike From Chris.Barker at noaa.gov Wed Jan 11 20:04:37 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 11 Jan 2006 11:04:37 -0800 Subject: [Pythonmac-SIG] MacPython documentation and webpages In-Reply-To: References: Message-ID: <43C556C5.6040507@noaa.gov> Mark, You got the ball rolling on this: Mark Asbach wrote: > From my point of view, it would be very helpful to concentrate > MacPython knowledge and information in a central place like > www.python.org / http://wiki.python.org and replace all outdated > information on the other web pages by a link to that central place. > I would invest some time and effort in revising documentation. Bob Ippolito wrote: >>Are you the webmaster of pythonmac.org? If so, how is that page >>produced? is it static html? > Yes and yes. >>If so, are you open to replacing it with a page that is better >>suited as the primary Front-End to the Python-on-OS-X world? > Patches accepted ;) If anyone wants to deal with it, I'm definitely > willing to dish out accounts. I think we have an answer: python.org does not, in general, have a lot of platform specific documentation, and we'd have to get the primary python folks to approve anything we want to put there. I think that makes pythonmac.org the best place for our new, improved, "Intro Page for Python on OS-X". Mark, are you willing to coordinate the writing of a new page[s]? I suggest we have a basic intro, and then perhaps a decision tree under the heading: What version of Python should I use? That decision tree would include things like: which version of OS-X are you running? Do you need python 2.4 features? Do you want to bundle apps for others to use? etc. And, of course, we need a pointer to a FAQ in the Wiki. I'd also suggest that we break the pythonmac.org/packages pages down into separate pages, one for each python version. I think that will make it much clearer to folks coming to it which set of packages they should look at. Anyone else? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From pecora at anvil.nrl.navy.mil Wed Jan 11 21:09:05 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 11 Jan 2006 15:09:05 -0500 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? Message-ID: <43C565E1.9020209@anvil.nrl.navy.mil> I just upgraded to Tiger (archive and install) and need to reinstall some of the Python packages. Googling shows many sites some of which are outdated, some ... who knows? What are the best sites to use to install Numeric and wxPython which will be used with the stock, Apple-installed Python? Thanks. I do this so infrequently that I never remember where the heck I got these things. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From charles.hartman at conncoll.edu Wed Jan 11 21:03:02 2006 From: charles.hartman at conncoll.edu (Charles Hartman) Date: Wed, 11 Jan 2006 15:03:02 -0500 Subject: [Pythonmac-SIG] MacPython documentation and webpages In-Reply-To: <43C556C5.6040507@noaa.gov> References: <43C556C5.6040507@noaa.gov> Message-ID: Bless you guys -- this is a very helpful-looking project. I'm ignorant, but I can write. If (for example) you want me to do any editing, or something like that, I'd be delighted to help. Charles Hartman Professor of English, Poet in Residence Connecticut College charles.hartman at conncoll.edu *the Scandroid* is at cherry.conncoll.edu/cohar/Programs.htm On Jan 11, 2006, at 2:04 PM, Christopher Barker wrote: > Mark, > > You got the ball rolling on this: > > Mark Asbach wrote: >> From my point of view, it would be very helpful to concentrate >> MacPython knowledge and information in a central place like >> www.python.org / http://wiki.python.org and replace all outdated >> information on the other web pages by a link to that central place. > >> I would invest some time and effort in revising documentation. > > Bob Ippolito wrote: >>> Are you the webmaster of pythonmac.org? If so, how is that page >>> produced? is it static html? > >> Yes and yes. > >>> If so, are you open to replacing it with a page that is better >>> suited as the primary Front-End to the Python-on-OS-X world? > >> Patches accepted ;) If anyone wants to deal with it, I'm definitely >> willing to dish out accounts. > > I think we have an answer: python.org does not, in general, have a lot > of platform specific documentation, and we'd have to get the primary > python folks to approve anything we want to put there. I think that > makes pythonmac.org the best place for our new, improved, "Intro Page > for Python on OS-X". > > Mark, are you willing to coordinate the writing of a new page[s]? > > I suggest we have a basic intro, and then perhaps a decision tree > under > the heading: > > What version of Python should I use? > > That decision tree would include things like: which version of OS-X > are > you running? Do you need python 2.4 features? Do you want to bundle > apps > for others to use? etc. > > And, of course, we need a pointer to a FAQ in the Wiki. > > I'd also suggest that we break the pythonmac.org/packages pages down > into separate pages, one for each python version. I think that will > make > it much clearer to folks coming to it which set of packages they > should > look at. > > Anyone else? > > -Chris > > > > > > > > > > > > > > > > -- > Christopher Barker, Ph.D. > Oceanographer > > NOAA/OR&R/HAZMAT (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > Chris.Barker at noaa.gov > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Wed Jan 11 21:48:28 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 11 Jan 2006 12:48:28 -0800 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: <43C565E1.9020209@anvil.nrl.navy.mil> References: <43C565E1.9020209@anvil.nrl.navy.mil> Message-ID: <43C56F1C.6050302@noaa.gov> Louis Pecora wrote: > What are the best sites to use to install Numeric and wxPython which > will be used with the stock, Apple-installed Python? pythonmac.org/packages Robin Dunn just released a brand-new wxPython: http://www.wxpython.org/download.php We'll probably put it on the pythonmac site at some point. It's also time for an update to Numeric, but the one there works fine. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From dave.opstad at monotypeimaging.com Wed Jan 11 21:36:51 2006 From: dave.opstad at monotypeimaging.com (Opstad, Dave) Date: Wed, 11 Jan 2006 14:36:51 -0600 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: <43C565E1.9020209@anvil.nrl.navy.mil> Message-ID: On 1/11/06 12:09 PM, "Louis Pecora" wrote: > What are the best sites to use to install Numeric and wxPython which > will be used with the stock, Apple-installed Python? http://pythonmac.org/packages/ is what I use. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060111/2457a05f/attachment.htm From kevino at theolliviers.com Wed Jan 11 22:06:19 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 11 Jan 2006 13:06:19 -0800 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: <43C565E1.9020209@anvil.nrl.navy.mil> References: <43C565E1.9020209@anvil.nrl.navy.mil> Message-ID: Hi Louis, On Jan 11, 2006, at 12:09 PM, Louis Pecora wrote: > I just upgraded to Tiger (archive and install) and need to reinstall > some of the Python packages. Googling shows many sites some of which > are outdated, some ... who knows? > > What are the best sites to use to install Numeric and wxPython which > will be used with the stock, Apple-installed Python? First, install Bob's TigerPython23Compat fix from here: http://undefined.org/python/ Then, for wxPython, just go to the wxPython.org downloads page. The binary says it's for Panther, but it really should say "Panther and up". I'm not sure about the best way to get Numeric for 2.3, so I'll leave that question to someone else. Kevin > Thanks. I do this so infrequently that I never remember where the > heck > I got these things. > > -- > Cheers, > > Lou Pecora > > Code 6362 > Naval Research Lab > Washington, DC 20375 > USA > Ph: +202-767-6002 > email: pecora at anvil.nrl.navy.mil > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From pecora at anvil.nrl.navy.mil Wed Jan 11 22:12:25 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 11 Jan 2006 16:12:25 -0500 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: References: Message-ID: <43C574B9.3050708@anvil.nrl.navy.mil> Opstad, Dave wrote: > On 1/11/06 12:09 PM, "Louis Pecora" wrote: > > > What are the best sites to use to install Numeric and wxPython which > > will be used with the stock, Apple-installed Python? > > http://pythonmac.org/packages/ is what I use. > > Dave > Thanks. I also went to the wxPython site and got the Panther build. Also got TigerPython23Compat since it said that was necessary. I am trying to find which Numeric from pythonmac.org/packages/ I should use. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From Chris.Barker at noaa.gov Wed Jan 11 22:27:11 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 11 Jan 2006 13:27:11 -0800 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: <43C574B9.3050708@anvil.nrl.navy.mil> References: <43C574B9.3050708@anvil.nrl.navy.mil> Message-ID: <43C5782F.2060304@noaa.gov> Louis Pecora wrote: > I am > trying to find which Numeric from pythonmac.org/packages/ > I should use. In theory, you want one in: Mac OS X 10.4 (stock Python 2.3.5) However, there isn't one there. The one in: Mac OS X 10.3 (stock Python 2.3.0) may work. If it doesn't then you are stuck with upgrading to Python2.4 or building Numeric yourself, which should "just work" including Vectlib lapack support. If you do that, it would be great if you'd build a package and it can be put on that site. Apparently most Tiger users are running Python 2.4 -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From pecora at anvil.nrl.navy.mil Wed Jan 11 22:56:56 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Wed, 11 Jan 2006 16:56:56 -0500 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: <43C5782F.2060304@noaa.gov> References: <43C574B9.3050708@anvil.nrl.navy.mil> <43C5782F.2060304@noaa.gov> Message-ID: <43C57F28.5040902@anvil.nrl.navy.mil> Christopher Barker wrote: > Louis Pecora wrote: > >> I am trying to find which Numeric from pythonmac.org/packages/ >> I should use. > > > In theory, you want one in: > Mac OS X 10.4 (stock Python 2.3.5) > > However, there isn't one there. The one in: > > Mac OS X 10.3 (stock Python 2.3.0) > > may work. That worked (so far). Thanks. I also had to reinstall kinds.py. I had that package and ran the python setup.py install in the terminal. Worked fine in Tiger 10.4.4. > If it doesn't then you are stuck with upgrading to Python2.4 or > building Numeric yourself, which should "just work" including Vectlib > lapack support. If you do that, it would be great if you'd build a > package and it can be put on that site. > > Apparently most Tiger users are running Python 2.4 Yeah, I've thought about going to 2.4, but I don't need more installation complications for now. If I can hold off, I will. Gracias. > > -Chris -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From Chris.Barker at noaa.gov Thu Jan 12 00:02:03 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 11 Jan 2006 15:02:03 -0800 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: <43C57F28.5040902@anvil.nrl.navy.mil> References: <43C574B9.3050708@anvil.nrl.navy.mil> <43C5782F.2060304@noaa.gov> <43C57F28.5040902@anvil.nrl.navy.mil> Message-ID: <43C58E6B.10506@noaa.gov> Louis Pecora wrote: > Yeah, I've thought about going to 2.4, but I don't need more > installation complications for now. If I can hold off, I will. well, it's easy to install 2.4, so if there is even one more ready-built package for it, then you're even, more than one, and you've saved time. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From robin at alldunn.com Wed Jan 11 05:59:16 2006 From: robin at alldunn.com (Robin Dunn) Date: Tue, 10 Jan 2006 20:59:16 -0800 Subject: [Pythonmac-SIG] ANN: wxPython 2.6.2.1 Message-ID: <0D8B5405-0E29-4CA3-8FD5-8E30403E1655@alldunn.com> Announcing ---------- The 2.6.2.1 release of wxPython is now available for download at http://wxpython.org/download.php. There have been many enhancements and fixes implemented in this version, listed below and at http://wxpython.org/recentchanges.php. What is wxPython? ----------------- wxPython is a GUI toolkit for the Python programming language. It allows Python programmers to create programs with a robust, highly functional graphical user interface, simply and easily. It is implemented as a Python extension module that wraps the GUI components of the popular wxWidgets cross platform library, which is written in C++. wxPython is a cross-platform toolkit. This means that the same program will usually run on multiple platforms without modifications. Currently supported platforms are 32-bit Microsoft Windows, most Linux or other Unix-like systems using GTK2, and Mac OS X 10.2+, in most cases the native widgets are used on each platform. Changes in 2.6.2.1 ------------------ wxMSW: Fix for bug #1211907, popup menu indenting inconsistent with bitmaps. wxMac: Don't send an event for wx.RadioButton deselections, just the selections. This was done to make it consistent with the other platforms. wxMSW: Always set flat toolbar style, even under XP with themes: this is necessary or separators aren't shown at all. Fixes for bug #1217872, pydocview.DocService not correctly initialized. Fix for bug #1217874, Error in parameter name in DocManager.CreateView. Added wrappers for the wx.RendererNative class. Added the wx.lib.splitter module, which contains the MultiSplitterWindow class. This class is much like the standard wx.SplitterWindow class, except it allows more than one split, so it can manage more than two child windows. Docview and IDE patch from Morgan Hua with fix for bug #1217890 "Closing view crashes Python" plus some new features:: New feature added to the IDE is 'Extensions'. Under Tools|Options|Extensions, you can add calls to external programs. For example you can add a "Notepad" extension (under windows) that will exec Notepad on the currently open file. A new "Notepad" menu item will appear under the Tools menu. Some fixes to XRCed to make encoding errors a bit more user friendly. XRCed changes from Roman Rolinsky: * Added new controls (Choicebook, Listbook, StatusBar, DatePicker), and completed style flags. Test window is opened for an available parent control if no specific view defined. Better handling of exceptions (highlighting does not 'stick' anymore). * Use system clipboard for Copy/Paste. * Improved some dialogs (window styles, growable cols). Changed the range for wxSpinCtrl min/max to all integers (default 0/100 is not always good). Updates for wx.lib.foldpanelbar and wx.lib.hyperlink from Andrea Gavana. Fix for Bug #1283496: wxPython TheClipboard class causes problems for pychecker. Ensure the app has been created before initializing wx.TheClipboard. Fix for Bug #1352602: FileBrowseButtonWithHistory can't type in Value. wxHTML: Added space after list item number. wx.lib.printout: Applied patch #1384440. wxMSW: Fix for Bug #1293225 Window_FromHWND crashes if parent is None. Fix for Bug #1261669, use a wx.TE_RICH2 style for the Process demo so it doesn't fill up too soon. Applied Patch #1354389: wxPython MenuItem SetBitmaps fix. Applied Patch #1239456: wxPython wx.DataObject.GetAllFormats fix. Applied Patch # #1230107 which allows image handlers to be written in Python by deriving from wx.PyImageHandler. Applied patch #1072210: generalize printout.py to allow text printing. Applied patch #1243907: Give Throbber much more flexibility by allowing the user to set the rest image, the direction, the current index, custom sequence. Allows user to manually step through the sequence with Next(), Previous(), Increment(), Decrement() & SetCurrent(). Very handy if you have multiple throbbers that you want to synchronize with a single timer. Fix for bug #1336711: wx.lib.calendar.CalenDlg can yield incorrect result. Applied patch from Morgan Hua for updates to ActiveGrid code (pydocview, ActiveGrid IDE, etc.) Applied patch #1326241: Supporting "setup.py install --install- headers=path" Applied patch from Morgan Hua to fix bug #1219423: CommandManager should not repeat old commands after a branch. Applied patch #1238825 adding search backward capabilities to the demo. Modified to use the up/down options in the wx.FindReplaceDialog instead of a separate menu item. Fix for bug #1266745 and #1387725 in the wx.FindReplaceDialog on MSW. Actually check we are using MSLU before doing the hack designed to workaround a bug in MSLU! wxMSW: wx.lib.iewin.IEHtmlWindow now properly handles tabbing, return and other special keys properly. Lots of PyCrust enhancments started by Franz Steinaeusler, Adi Sieker, and Sebastian Haase, and which in turn were further enhanced, fixed tweaked and finished up by me. The changes include the following: * The Autocomplete and Calltip windows can now be opened manually with Ctrl-Space and Ctrl-Shift-Space. * In the stand alone PyCrust app the various option settings, window size and position, and etc. are saved and restored at the next run. * Added a help dialog bound to the F1 key that shows the key bindings. * Added a new text completion function that suggests words from the history. Bound to Shift-Return. * F11 will toggle the maximized state of the frame. * switched to Bind() from wx.EVT_*(). * Display of line numbers can be toggled. * F12 toggles a "free edit" mode of the shell buffer. This mode is useful, for example, if you would like to remove some output or errors or etc. from the buffer before doing a copy/paste. The free edit mode is designated by the use of a red, non-flashing caret. * Ctrl-Shift-F will fold/unfold (hide/show) the selected lines. * General code cleanup and fixes. * Use wx.StandardPaths to determine the location of the config files. * Use wx.SP_LIVE_UPDATE on crust and filling windows. * Extended the saving of the config info and other new features to the PyShell app too. Additionally, other apps that embed a PyCrust or a PyShell can pass their own wx.Config object and have the Py code save/restore its settings to/from there. * All of the classes with config info get an opportunity to save/load their own settings instead of putting all the save/load code in one place that then has to reach all over the place to do anything. * Enable editing of the startup python code, which will either be the file pointed to by PYTHONSTARTUP or a file in the config dir if PYTHONSTARTUP is not set in the environment. * Added an option to skip the running of the startup code when PyShell or PyCrust starts. * PyCrust adds a pp(item) function to the shell's namespace that pretty prints the item in the Display tab of the notebook. Added code to raise that tab when pp() is called. * Added an option for whether to insert text for function parameters when popping up the call tip. * Added Find and Find-Next functions that use the wx.FindReplaceDialog. Applied patches from Will Sadkin for wx.lib.masked modules: * Now ignores kill focus events when being destroyed. * Added missing call to set insertion point on changing fields. * Modified SetKeyHandler() to accept None as means of removing one. * Fixed keyhandler processing for group and decimal character changes. * Fixed a problem that prevented input into the integer digit of a integerwidth=1 numctrl, if the current value was 0. * Fixed logic involving processing of "_signOk" flag, to remove default sign key handlers if false, so that SetAllowNegative(False) in the NumCtrl works properly. * Fixed selection logic for numeric controls so that if selectOnFieldEntry is true, and the integer portion of an integer format control is selected and the sign position is selected, the sign keys will always result in a negative value, rather than toggling the previous sign. wx.FontMapper.SetConfig is deprecated. You should instead just set an application-wide config object with wx.Config.Set, which wx.FontMapper will use by default. Added wx.GetMouseState which returns the current state of the mouse. It returns an instance of a wx.MouseState object that contains the current position of the mouse pointer in screen coordinants, as well as boolean values indicating the up/down status of the mouse buttons and the modifier keys. Added wx.SizerItem.SetUserData A variety of updates to wx.lib.floatcanvas, including Added DrawObjects, including a ScaledTextBox, with auto-wrapping, etc, and Scaled and Unscaled Bitmap Objects. WARNING: Changed all DrawObjects to take an (x,y) pair rather than individual x,y parameters. Also changed rectangles and ellipses to take (w,h) pair. This is an API change, but should be easy to accommodate, all you need to do is add a parenthesis pair: (...x, y, ...) ---> (...(x,y), ...) --------------------------------------------------------------------- To unsubscribe, e-mail: wx-users-unsubscribe at lists.wxwidgets.org For additional commands, e-mail: wx-users-help at lists.wxwidgets.org From janssen at parc.com Thu Jan 12 04:14:08 2006 From: janssen at parc.com (Bill Janssen) Date: Wed, 11 Jan 2006 19:14:08 PST Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: Your message of "Wed, 11 Jan 2006 13:27:11 PST." <43C5782F.2060304@noaa.gov> Message-ID: <06Jan11.191408pst."58633"@synergy1.parc.xerox.com> > Apparently most Tiger users are running Python 2.4 I strongly doubt that. Python 2.3.5 is what comes with the stock distribution; it should be supported. Bill From bob at redivi.com Thu Jan 12 04:37:46 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 11 Jan 2006 19:37:46 -0800 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: <06Jan11.191408pst."58633"@synergy1.parc.xerox.com> References: <06Jan11.191408pst."58633"@synergy1.parc.xerox.com> Message-ID: On Jan 11, 2006, at 7:14 PM, Bill Janssen wrote: >> Apparently most Tiger users are running Python 2.4 > > I strongly doubt that. Python 2.3.5 is what comes with the stock > distribution; it should be supported. It is supported, in that when I build a package or an egg I build it for both 2.4 and 2.3 -- but I never use Python 2.3, so those packages get no testing whatsoever. For my own Python packages, I run the test suite with Python 2.3, but that's as far as it goes if it supports 2.3 at all. I use Python 2.4 because it has fewer bugs, better performance, and a couple nice new features that people are starting to take advantage of. New builtins like set and sorted, new modules like subprocess, additions to the operator module (attrgetter, itemgetter), generator expressions, decorators, etc. I also need a non-vendor installation of Python anyway to build self-contained applications that will continue to work on future versions of Mac OS X, so installing an old version of Python would be pretty silly. -bob From gherman at darwin.in-berlin.de Thu Jan 12 11:44:50 2006 From: gherman at darwin.in-berlin.de (Dinu Gherman) Date: Thu, 12 Jan 2006 11:44:50 +0100 Subject: [Pythonmac-SIG] State of DrawBot, missing features Message-ID: Hi! Could someone, please, provide insight into the current state of DrawBot [1], a nice interactive graphics programming environment, originally written by Just van Rossum? I asked Just via private email some weeks ago, but either he's busy or his reply hasn't made it through my spam-filter. The website mentions an upcoming release 2.0 and the current pages describe features which I cannot reproduce in version 0.91a avail- able for download. Among these are all text-related commands shown on the respective reference webpage [2]. I screened the available source code and could not find any code implementing these features. I'm aware of Bob Ippolito's beefed-up version [3] of DrawBot, but it shows the same effects concerning these commands and Frederik Lundh seems to have abandoned his efforts to port DrawBot to Windows [4] due to its "overforking disease." So I wonder what is the current state of the art? At least it would be nice to be able to use features as advertised on the webpages. Thanks, Dinu [1] http://www.drawbot.com [2] http://www.drawbot.com/reference/text.html [3] http://pythonmac.org/wiki/DrawBot [4] http://effbot.org/zone/drawbot.htm From just at letterror.com Thu Jan 12 12:07:04 2006 From: just at letterror.com (Just van Rossum) Date: Thu, 12 Jan 2006 12:07:04 +0100 Subject: [Pythonmac-SIG] State of DrawBot, missing features In-Reply-To: Message-ID: Dinu Gherman wrote: > Could someone, please, provide insight into the current state of > DrawBot [1], a nice interactive graphics programming environment, > originally written by Just van Rossum? I asked Just via private > email some weeks ago, but either he's busy or his reply hasn't > made it through my spam-filter. > > The website mentions an upcoming release 2.0 and the current pages > describe features which I cannot reproduce in version 0.91a avail- > able for download. Among these are all text-related commands shown > on the respective reference webpage [2]. I screened the available > source code and could not find any code implementing these features. > > I'm aware of Bob Ippolito's beefed-up version [3] of DrawBot, but it > shows the same effects concerning these commands and Frederik Lundh > seems to have abandoned his efforts to port DrawBot to Windows [4] > due to its "overforking disease." > > So I wonder what is the current state of the art? At least it would > be nice to be able to use features as advertised on the webpages. It's slowly being worked on, a development version can be found here: http://just.letterror.com/~just/DrawBot.zip Not sure when I'll be able to spend significant time on it to make a proper release. Just From keith.ray at gmail.com Thu Jan 12 18:17:20 2006 From: keith.ray at gmail.com (Keith Ray) Date: Thu, 12 Jan 2006 09:17:20 -0800 Subject: [Pythonmac-SIG] distributed objects with PyObjC In-Reply-To: <207ec7f00601111147ge6120a1o41cd7c643ef576bb@mail.gmail.com> References: <207ec7f00601111147ge6120a1o41cd7c643ef576bb@mail.gmail.com> Message-ID: <207ec7f00601120917h319ae500tc77e4c43b176a4df@mail.gmail.com> I'm trying to test-implement Distributed Object using the example server / client from the book "Cocoa Programming" by Scott Anguish, Erik M. Buck, Donald A. Yacktman (chapter 23). I've kept the sample server in Objective C, and I'm trying to implement the client in PyFit. What I'm stuck on right now is a crash calling self.server.addMessageClient_( self ) in my method applicationDidFinishLaunching_ Do you have any suggestions? I can send the crash-log as well... Here's the python source code: ************************************ # # DOTestPythonClientAppDelegate.py # DOTestPythonClient # from Foundation import * from AppKit import * from PyObjCTools import * from objc import * MYMessageServerProtocol = formal_protocol( u'MYMessageServerProtocol', None, [ selector( None, selector='addMessageClient:', signature='Vv12 at 0:4 at 8'), selector( None, selector='removeMessageClient:', signature='c12 at 0:4 at 8'), selector( None, selector='broadcastMessageString:', signature='Vv12 at 0:4 at 8') ] ) class DOTestPythonClientAppDelegate(NibClassBuilder.AutoBaseClass): composeView = ivar(u'composeView') messageView = ivar(u'messageView') sendButton = ivar(u'sendButton') server = None def sendMessage_(self,aSender): NSLog( u"sendMessage_ ." ) self.server.broadcastMessageString_( self.composeView.string() ) self.composeView.setString_( u'' ) def appendMessageString_(self,aSstring): # called by server... NSLog( u"appendMessageString ." ) #NSRange appendRange = NSMakeRange( self.messageView.string().length(), 0); #Append text and scroll if neccessary self.messageView.replaceCharactersInRange_withString_( appendRange, aString ); self.messageView.scrollRangeToVisible_( appendRange ) return self def connectionDidDie_(self,aNotification): NSLog( u"Error: Connection to server is broken." ) def applicationDidFinishLaunching_(self,aNotification): NSLog( u"applicationDidFinishLaunching_ ." ) self.server = NSConnection.rootProxyForConnectionWithRegisteredName_host_( u"server", None ).retain() if None == self.server : NSLog( u"Error: Failed to connect to server." ) else: NSLog( u"did connect to server." ) connectionDidDie_SEL = selector( self.connectionDidDie_, selector='connectionDidDie:', signature="v12 at 0:4 at 8" ) NSNotificationCenter.defaultCenter().addObserver_selector_name_object_( self, connectionDidDie_SEL, NSConnectionDidDieNotification, None ) NSLog( u"called defaultCenter().addObserver_selector_name_object_." ) self.server.setProtocolForProxy_( MYMessageServerProtocol ) NSLog( u"called self.server.setProtocolForProxy_." ) self.server.addMessageClient_( self ) # crashing here... NSLog( u"called self.server.addMessageClient_." ) astr = u"Connected: %s %d" % NSProcessInfo.processInfo().processName(), NSProcessInfo.processInfo().processIdentifier() NSLog( u"astr = '%s'" % astr ) self.server.broadcastMessageString_( astr ) # convert to NSString NSLog( u"called self.server.broadcastMessageString_." ) def applicationWillTerminate_(self,aNotification): NSLog( u"applicationWillTerminate_ ." ) if NO == self.server.removeMessageClient_(self) : NSLog( u"Error: Failed to remove client." ) self.server.release() self.server = None -- C. Keith Ray From Chris.Barker at noaa.gov Thu Jan 12 18:32:22 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 12 Jan 2006 09:32:22 -0800 Subject: [Pythonmac-SIG] State of DrawBot, missing features In-Reply-To: References: Message-ID: <43C692A6.2060504@noaa.gov> Dinu Gherman wrote: > Frederik Lundh > seems to have abandoned his efforts to port DrawBot to Windows [4] > due to its "overforking disease." Well, if you want something cross-platform, maybe the wxPython FloatCanvas (written by me) would serve you well. What I like about it (and why I wrote it) are four key features: Generalized floating point coordinates: use whatever coordinate system you like, and it will scale everything for you. It even supports a limited projection option (I include a flat-earth projection for doing simple maps) Object Canvas: Add objects to the Canvas, then those objects can be removed, properties changed, whatever. Zooming, Panning, etc. Event binding to Mouse events on the Canvas. I even wrote a little demo that duplicates a DrawBot demo I saw somewhere. I've enclosed it. It should work with recent versions of wxPython. It does create an ugly Yellow. Can someone who better understands RGB fix that? By the way, you can use FloatCanvas with wxPython to generate PNGs, etc, without ever bringing up a Window, though the windowing system does need to be there, which I'm pretty sure it always is on OS-X. Note that FloatCanvas needs Numeric. The versions on pythonmac.org work fine. I have plans to put in a better rendering engine (maybe Agg), and in the process separate the rendering engine from wx, so that it could be used for non-GUI work without wx. No guarantee about when that might happen, however. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- A non-text attachment was scrubbed... Name: DrawBot.py Type: text/x-python Size: 1784 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060112/a7b42fef/attachment.py From Chris.Barker at noaa.gov Thu Jan 12 18:38:55 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 12 Jan 2006 09:38:55 -0800 Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: <06Jan11.191408pst.58633@synergy1.parc.xerox.com> References: <06Jan11.191408pst.58633@synergy1.parc.xerox.com> Message-ID: <43C6942F.7070408@noaa.gov> Bill Janssen wrote: >>Apparently most Tiger users are running Python 2.4 > > I strongly doubt that. Python 2.3.5 is what comes with the stock > distribution; I was not very precise. How's this: Apparently most Tiger users that are building and distributing packages are running Python 2.4 > it should be supported. coulda, woulda, shoulda. Bob accepts contributions to the pythonmac site. In fact, he's even said he'll give admin privileges to folks that want to help maintain it. That brings up an issue: In many cases, it is very easy to build a mpkg of a python package once you have it all compiled. If all of us that got packages working on our machines contributed them, the pythonmac site would get much more comprehensive. As for me, I'm still running 10.3, and I try to contribute packages for Python2.3 and python2.4 -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From janssen at parc.com Thu Jan 12 23:01:28 2006 From: janssen at parc.com (Bill Janssen) Date: Thu, 12 Jan 2006 14:01:28 PST Subject: [Pythonmac-SIG] Best site to get Numeric and wxPython for new Tiger 10.4 install? In-Reply-To: Your message of "Thu, 12 Jan 2006 09:38:55 PST." <43C6942F.7070408@noaa.gov> Message-ID: <06Jan12.140130pst."58633"@synergy1.parc.xerox.com> Christopher Barker wrote: > Bill Janssen wrote: > >>Apparently most Tiger users are running Python 2.4 > > > > I strongly doubt that. Python 2.3.5 is what comes with the stock > > distribution; > > I was not very precise. How's this: > > Apparently most Tiger users that are building and distributing packages > are running Python 2.4 Right. And that's a problem. Most *users* of those packages are running Python 2.3.5. That's what I meant. My guess is that this split causes most of the various MacPython problems brought up here. Bill From brownr at ucalgary.ca Fri Jan 13 00:56:02 2006 From: brownr at ucalgary.ca (Robert Brown) Date: Thu, 12 Jan 2006 16:56:02 -0700 Subject: [Pythonmac-SIG] distributed objects with PyObjC In-Reply-To: <207ec7f00601120917h319ae500tc77e4c43b176a4df@mail.gmail.com> References: <207ec7f00601111147ge6120a1o41cd7c643ef576bb@mail.gmail.com> <207ec7f00601120917h319ae500tc77e4c43b176a4df@mail.gmail.com> Message-ID: What sort of crash? It took me a while to get distributed objects working in PyObjC. One of the problems was that oneway void was broken in PyObjC for a while. It was fixed in the CVS version at the time, so if you're using an old copy try updating. On 12-Jan-06, at 10:17 AM, Keith Ray wrote: > I'm trying to test-implement Distributed Object using the example > server / client from the book "Cocoa Programming" by Scott Anguish, > Erik M. Buck, Donald A. Yacktman (chapter 23). > > > I've kept the sample server in Objective C, and I'm trying to > implement the client in PyFit. > > What I'm stuck on right now is a crash calling > > self.server.addMessageClient_( self ) > > in my method applicationDidFinishLaunching_ > > Do you have any suggestions? I can send the crash-log as well... > > Here's the python source code: > ************************************ > > # > # DOTestPythonClientAppDelegate.py > # DOTestPythonClient > # > > from Foundation import * > from AppKit import * > > from PyObjCTools import * > from objc import * > > MYMessageServerProtocol = formal_protocol > ( u'MYMessageServerProtocol', None, [ > selector( None, selector='addMessageClient:', > signature='Vv12 at 0:4 at 8'), > selector( None, selector='removeMessageClient:', > signature='c12 at 0:4 at 8'), > selector( None, selector='broadcastMessageString:', > signature='Vv12 at 0:4 at 8') ] ) > > class DOTestPythonClientAppDelegate(NibClassBuilder.AutoBaseClass): > > composeView = ivar(u'composeView') > messageView = ivar(u'messageView') > sendButton = ivar(u'sendButton') > server = None > > def sendMessage_(self,aSender): > NSLog( u"sendMessage_ ." ) > self.server.broadcastMessageString_( self.composeView.string > () ) > self.composeView.setString_( u'' ) > > def appendMessageString_(self,aSstring): # called by server... > NSLog( u"appendMessageString ." ) > #NSRange > appendRange = NSMakeRange( self.messageView.string().length > (), 0); > #Append text and scroll if neccessary > self.messageView.replaceCharactersInRange_withString_( > appendRange, aString ); > self.messageView.scrollRangeToVisible_( appendRange ) > return self > > def connectionDidDie_(self,aNotification): > NSLog( u"Error: Connection to server is broken." ) > > def applicationDidFinishLaunching_(self,aNotification): > NSLog( u"applicationDidFinishLaunching_ ." ) > self.server = > NSConnection.rootProxyForConnectionWithRegisteredName_host_( > u"server", None ).retain() > if None == self.server : > NSLog( u"Error: Failed to connect to server." ) > else: > NSLog( u"did connect to server." ) > connectionDidDie_SEL = selector( self.connectionDidDie_, > selector='connectionDidDie:', signature="v12 at 0:4 at 8" ) > NSNotificationCenter.defaultCenter > ().addObserver_selector_name_object_( > self, connectionDidDie_SEL, > NSConnectionDidDieNotification, None ) > NSLog( u"called > defaultCenter().addObserver_selector_name_object_." ) > > self.server.setProtocolForProxy_ > ( MYMessageServerProtocol ) > NSLog( u"called self.server.setProtocolForProxy_." ) > > self.server.addMessageClient_( self ) # crashing here... > NSLog( u"called self.server.addMessageClient_." ) > > astr = u"Connected: %s %d" % > NSProcessInfo.processInfo().processName(), > NSProcessInfo.processInfo().processIdentifier() > NSLog( u"astr = '%s'" % astr ) > > self.server.broadcastMessageString_( astr ) # convert > to NSString > NSLog( u"called self.server.broadcastMessageString_." ) > > def applicationWillTerminate_(self,aNotification): > NSLog( u"applicationWillTerminate_ ." ) > if NO == self.server.removeMessageClient_(self) : > NSLog( u"Error: Failed to remove client." ) > self.server.release() > self.server = None > > > > -- > > C. Keith Ray > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig --------------------------------------------------- Robb Brown Seaman Family MR Research Centre Calgary, Alberta, Canada -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060112/8facef50/attachment.html From smithsm at samuelsmith.org Fri Jan 13 02:46:37 2006 From: smithsm at samuelsmith.org (Samuel M. Smith) Date: Thu, 12 Jan 2006 18:46:37 -0700 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: <9407E9A8-ABC4-4EAA-9AA6-F8AE2BC6C6B1@redivi.com> References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> <4426B82A-0969-466E-BBD1-D9735672BCBA@samuelsmith.org> <43C1F4D3.5020901@wordtech-software.com> <9407E9A8-ABC4-4EAA-9AA6-F8AE2BC6C6B1@redivi.com> Message-ID: > > I'll repeat myself and be more explicit about why I said what I > said... > > You must run it with DYLD_FRAMEWORK_PATH=. if it's not installed > yet. It has *absolutely nothing* to do with the fact that there is > an existing framework somewhere else. In other words: it's not > linked wrong, you ran it incorrectly. > This worked for me. I think our emails crossed. Thanks for the help. For linux builds I was used to to being able to run the python.exe that is made by make before running install, as a check for a good build so I was surprised that it was giving me unexpected results. I didn't appreciate that there is some magic happening with framework builds. I hope these details make it onto the revised python documentation on the website. From bob at redivi.com Fri Jan 13 03:33:21 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 12 Jan 2006 18:33:21 -0800 Subject: [Pythonmac-SIG] python 2.4.2 source builds 2.4.1? In-Reply-To: References: <1A499251-0283-451C-9C18-F7C03994B49A@samuelsmith.org> <263640BA-1F40-4A72-A50A-0F62A17BF666@samuelsmith.org> <4426B82A-0969-466E-BBD1-D9735672BCBA@samuelsmith.org> <43C1F4D3.5020901@wordtech-software.com> <9407E9A8-ABC4-4EAA-9AA6-F8AE2BC6C6B1@redivi.com> Message-ID: <8D0E7BE8-5B83-49DD-82A0-D7FD8EC6D8E2@redivi.com> On Jan 12, 2006, at 5:46 PM, Samuel M. Smith wrote: >> >> I'll repeat myself and be more explicit about why I said what I >> said... >> >> You must run it with DYLD_FRAMEWORK_PATH=. if it's not installed >> yet. It has *absolutely nothing* to do with the fact that there >> is an existing framework somewhere else. In other words: it's not >> linked wrong, you ran it incorrectly. >> > > This worked for me. I think our emails crossed. Thanks for the > help. For linux builds I was used to > to being able to run the python.exe that is made by make before > running install, as a check for a good build > so I was surprised that it was giving me unexpected results. I > didn't appreciate that there is some magic happening with framework > builds. > > I hope these details make it onto the revised python documentation > on the website. It's actually magic that's *not* happening in the framework builds. IIRC, in the normal builds that you're used to, python.exe is an autoconf generated shell script that sets up the proper environment variables before running the real executable. If you had did a normal Python build, presumably autoconf would've known how to do the same tricks that it does on other platforms. -bob From nutbut at gmail.com Fri Jan 13 21:43:22 2006 From: nutbut at gmail.com (Nathaniel Rhein) Date: Fri, 13 Jan 2006 15:43:22 -0500 Subject: [Pythonmac-SIG] Problem with applets on MacPython Message-ID: <59a500c50601131243o78c60ea7rde911c47e750ffd4@mail.gmail.com> I know it'd be better to post this to a primarily MacPython group, but this is pretty much all I could find for Python. I'm very novice as far as programming languages go; basically I leanred Basic a while back and now, wanting to get into a more advanced langage, chose Python. I really don't know much about how languages work with operating systems (if you download just Python ? not MacPython ? for OS X you get a whole bunch of strange folders and files with Terminal icons), or any of that stuff, so I'm trying to start out pretty small. My problem right now is simply that whenever I build a simple program I have made in MacPython into an applet ? from PythonIDE, BuildApplet, or py2app, ? it never works. I open it up and it quits right away, without even an error message. I'm using ridiculously small programs (1-10 lines or so), and I don't know of anything else to do. Does anyone know how to fix this problem, or if I'm barking up the wrong tree, a better starting point for wanting to learn programming? Or is this just entirely the wrong place to ask? -- -Nat "Better to remain silent and be thought a fool than speak out and remove all doubt." -Abraham Lincoln -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060113/f055bcd9/attachment.html From bob at redivi.com Fri Jan 13 22:13:31 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 13 Jan 2006 13:13:31 -0800 Subject: [Pythonmac-SIG] Problem with applets on MacPython In-Reply-To: <59a500c50601131243o78c60ea7rde911c47e750ffd4@mail.gmail.com> References: <59a500c50601131243o78c60ea7rde911c47e750ffd4@mail.gmail.com> Message-ID: <0D0FF46E-0269-45C5-907F-3996FAF7D84C@redivi.com> On Jan 13, 2006, at 12:43 PM, Nathaniel Rhein wrote: > I know it'd be better to post this to a primarily MacPython group, > but this is pretty much all I could find for Python. > I'm very novice as far as programming languages go; basically I > leanred Basic a while back and now, wanting to get into a more > advanced langage, chose Python. I really don't know much about how > languages work with operating systems (if you download just Python > ? not MacPython ? for OS X you get a whole bunch of strange folders > and files with Terminal icons), or any of that stuff, so I'm trying > to start out pretty small. My problem right now is simply that > whenever I build a simple program I have made in MacPython into an > applet ? from PythonIDE, BuildApplet, or py2app, ? it never works. > I open it up and it quits right away, without even an error > message. I'm using ridiculously small programs (1-10 lines or so), > and I don't know of anything else to do. Does anyone know how to > fix this problem, or if I'm barking up the wrong tree, a better > starting point for wanting to learn programming? Or is this just > entirely the wrong place to ask? Your programs are probably behaving correctly. What's happening is that none of those application building tools have an option that attaches a console to them, so your simple console interaction isn't going to work. In order to make an applet with that sort of console, you'll need to use a windowing toolkit such as wxPython, Tkinter, or PyObjC. There are probably other, not Python specific, tools designed to generically wrap unix style terminal applications with an interactive console, but I'm not aware of any specifically. -bob From Chris.Barker at noaa.gov Fri Jan 13 23:59:11 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 13 Jan 2006 14:59:11 -0800 Subject: [Pythonmac-SIG] Problem with applets on MacPython In-Reply-To: <0D0FF46E-0269-45C5-907F-3996FAF7D84C@redivi.com> References: <59a500c50601131243o78c60ea7rde911c47e750ffd4@mail.gmail.com> <0D0FF46E-0269-45C5-907F-3996FAF7D84C@redivi.com> Message-ID: <43C830BF.7000009@noaa.gov> > Your programs are probably behaving correctly. What's happening is > that none of those application building tools have an option that > attaches a console to them, so your simple console interaction isn't > going to work. Your output is probably going to the "Console" open that up and you should see your output. > In order to make an applet with that sort of console, > you'll need to use a windowing toolkit such as wxPython, Tkinter, or > PyObjC. Which is a bit much for a beginner. I'd get started with using the unix terminal to start to learn and run python. You really don't want to have to build your app into a App bundle while testing it anyway. Start up the "terminal" app. Use "cd" to put yourself in the folder (directory) that your python script is in. Then type: python MyScriptName.py and it should run. You're off and running! If none of that makes sense, then look for tutorials on the web about using the unix command line in OS-X--there's lots of them, and it's well worth learning a bit about. A utility I find invaluable is "Open terminal Here" -- google it and you should find it. by the way, there are a number of IDEs for python on OS-X, and last I heard, none of them were really bug-free enough to use for a newbie. Has that changed? How's SPE on OS-X now? How's PyOxide coming along? etc. If you don't mind spending a little money, WingIDE and Komodo are reported to work well. WingIDE has a non-commercial version that's pretty cheap. Or you can use the command line and an editor--that's served me well for years. Just make sure you get a good, python-aware editor, I'll leave that up to you to research! good luck, -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From ken at sparklight.com Sat Jan 14 00:18:12 2006 From: ken at sparklight.com (Ken Brooks) Date: Fri, 13 Jan 2006 18:18:12 -0500 Subject: [Pythonmac-SIG] Trouble installing PIL package Message-ID: OS: Tiger 10.4.4 System: 1GHz / 1GB RAM Python: 2.3.5 Using PackageManager to install PIL, came to following problem (at end of quoted text): -------------------------------------------------------------------- PIL 1.1.5 BUILD SUMMARY -------------------------------------------------------------------- version 1.1.5 platform darwin 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] -------------------------------------------------------------------- --- TKINTER support ok --- JPEG support ok --- ZLIB (PNG/ZIP) support ok *** FREETYPE2 support not available -------------------------------------------------------------------- To add a missing option, make sure you have the required library, and set the corresponding ROOT variable in the setup.py script. To check the build, run the selftest.py script. running build_scripts creating build/scripts-2.3 copying and adjusting Scripts/pilconvert.py -> build/scripts-2.3 copying and adjusting Scripts/pildriver.py -> build/scripts-2.3 copying and adjusting Scripts/pilfile.py -> build/scripts-2.3 copying Scripts/pilfont.py -> build/scripts-2.3 copying and adjusting Scripts/pilprint.py -> build/scripts-2.3 changing mode of build/scripts-2.3/pilconvert.py from 644 to 755 changing mode of build/scripts-2.3/pildriver.py from 644 to 755 changing mode of build/scripts-2.3/pilfile.py from 644 to 755 changing mode of build/scripts-2.3/pilfont.py from 664 to 775 changing mode of build/scripts-2.3/pilprint.py from 644 to 755 running install_lib copying build/lib.darwin-8.4.0-Power_Macintosh-2.3/_imaging.so -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-8.4.0-Power_Macintosh-2.3/_imagingtk.so -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL running install_scripts copying build/scripts-2.3/pilconvert.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/bin error: /System/Library/Frameworks/Python.framework/Versions/2.3/bin/pilconvert.py: Permission denied install PIL-1.1.5-source: running ""/Applications/MacPython-2.3/PackageManager.app/Contents/MacOS/Python" setup.py install " failed It really did fail: when I try PIL's selftest.py, it says, *** The _imaging C module is not installed If it was just a matter of copying files, I would use sudo and do it myself - but I've searched that setup.py script and I can't even find in it where the copy commands are being issued! I also tried downloading PIL separately and saying: sudo python setup.py install which got farther but still doesn't pass the selftest check. Help?? Ken Brooks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060113/ea86885b/attachment.htm From Chris.Barker at noaa.gov Sat Jan 14 00:32:45 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 13 Jan 2006 15:32:45 -0800 Subject: [Pythonmac-SIG] Trouble installing PIL package In-Reply-To: References: Message-ID: <43C8389D.8070704@noaa.gov> Ken Brooks wrote: > OS: Tiger 10.4.4 > System: 1GHz / 1GB RAM > Python: 2.3.5 > > Using PackageManager to install PIL Don't use PackageManager, it's outdated. Use the packages at: http://pythonmac.org/packages/ I think the ones for: Mac OS X 10.3 (stock Python 2.3.0) might work with your system, but you're probably better off installing python 2.4 from: http://undefined.org/python/ and using these: Mac OS X 10.3+ (Python 2.4.1 framework build) They'll work on 10.4 We really need to update the pythonmac.org web site! (and Jack's Page) -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From hraban at fiee.net Sat Jan 14 02:53:07 2006 From: hraban at fiee.net (Henning Hraban Ramm) Date: Sat, 14 Jan 2006 02:53:07 +0100 Subject: [Pythonmac-SIG] Problem with applets on MacPython In-Reply-To: <43C830BF.7000009@noaa.gov> References: <59a500c50601131243o78c60ea7rde911c47e750ffd4@mail.gmail.com> <0D0FF46E-0269-45C5-907F-3996FAF7D84C@redivi.com> <43C830BF.7000009@noaa.gov> Message-ID: <1DA4883E-5E1F-49CF-A796-E3DA250B02DA@fiee.net> Am 2006-01-13 um 23:59 schrieb Christopher Barker: > by the way, there are a number of IDEs for python on OS-X, and last I > heard, none of them were really bug-free enough to use for a > newbie. Has > that changed? > > How's SPE on OS-X now? It works and is becoming better and better, but you must start it on the command line, no Mac app yet. (You need wxPython 2.6.x) see http://spe.stani.be/ (On my G4/400 with OSX 10.4, all GUI scripts are very slow, so using SPE with all of its functions, intellisense etc., is not really fun.) Greetlings from Lake Constance --- Henning Hraban Ramm http://www.fiee.net http://www.cacert.org (I'm an assurer) From sw at wordtech-software.com Sat Jan 14 03:01:39 2006 From: sw at wordtech-software.com (Kevin Walzer) Date: Fri, 13 Jan 2006 21:01:39 -0500 Subject: [Pythonmac-SIG] Problem with applets on MacPython In-Reply-To: <1DA4883E-5E1F-49CF-A796-E3DA250B02DA@fiee.net> References: <59a500c50601131243o78c60ea7rde911c47e750ffd4@mail.gmail.com> <0D0FF46E-0269-45C5-907F-3996FAF7D84C@redivi.com> <43C830BF.7000009@noaa.gov> <1DA4883E-5E1F-49CF-A796-E3DA250B02DA@fiee.net> Message-ID: <43C85B83.6020103@wordtech-software.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henning Hraban Ramm wrote: > Am 2006-01-13 um 23:59 schrieb Christopher Barker: >> by the way, there are a number of IDEs for python on OS-X, and last I >> heard, none of them were really bug-free enough to use for a >> newbie. Has >> that changed? >> >> How's SPE on OS-X now? > > It works and is becoming better and better, but you must start it on > the command line, no Mac app yet. > (You need wxPython 2.6.x) > see http://spe.stani.be/ > > (On my G4/400 with OSX 10.4, all GUI scripts are very slow, so using > SPE with all of its functions, intellisense etc., is not really fun.) > > Greetlings from Lake Constance > --- > Henning Hraban Ramm > http://www.fiee.net > http://www.cacert.org (I'm an assurer) > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > > I used to maintain packages of SPE on OS X: it was a nicely-designed application but very unstable. It crashed constantly. I've looked at the new version: it seems even more slick than before. Not sure about how stable it is. Komodo (commercial IDE from ActiveState) is now available on OS X, has excellent Python support, runs natively (e.g. no X11), and is a real bargain (the personal/non-commercial version is around $30 USD). - -- Cheers, Kevin Walzer, PhD WordTech Software - "Tame the Terminal" http://www.wordtech-software.com sw at wordtech-software.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDyFuCJmdQs+6YVcoRAmS3AJsHUP6Uu8dzuX9AHQdrDzaLuNQ1bQCfdKij OtohFFCi3jIo67T4wMHiM2U= =lhO/ -----END PGP SIGNATURE----- From rroberts at adobe.com Sat Jan 14 03:48:44 2006 From: rroberts at adobe.com (Read Roberts) Date: Fri, 13 Jan 2006 18:48:44 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app Message-ID: I would like to distribute about 30 Python command-line programs that use a single stand-alone Python distribution. Looking at py2app, I only see the following two ways of doing it. Can anyone suggest a better approach? In all cases: build a *.app bundle app with py2app, and then use relative sym-links to run the command-line binary which is at ".app/Contents/MacOS/". so the user can see and access the CLI program without having to cd within the bundle app. 1) Build a single CLI app that runs a differnet CLI Python file based on the first command-line argument. - Build a single Python ".app" that imports everything needed by any of my separate Python apps. - copy my Python programs into ".app/Contents/Resources" - have the main "" Python program simply do execfile with sys.argv[1] + ".py" - document that to run the program in the package, the user needs to say: " .app" start-up data so that you can have several CLI apps in ".app/Contents/MacOS", usch that one each runs a different Python program under ".app/Contents/Resources". I notice that the ".app/Contents/Info.plist" file contains the key-value pair " PyMainFileNames"-"". The CLI program ".app/Contents/MacOS/" references this key name to get the list of strings, and for each name, will try to run the matching Python boot file in ".app/Contents/Resources". This boot file in turn fixes up the Python sys paths, and then uses execfile to run the Python file ".py". I verified that I can achieve what I want to do here by a crude manual approach : - make multiple copies of the "" file under ".app/Contents/MacOS/" - edit the data string " PyMainFileNames" in each one to be a different string (of the same length!) - add key-value pairs to ".app/Contents/Info.plist" defining a different boot-file name value for each different key value - make multiple copies of the boot file under ".app/Contents/Resources", one for each name I supplied in the Info.plist file, and edit each so that it starts a different CLI program. Obviously, for production, I would modify the py2app code to do this. Any better ideas? Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days From bob at redivi.com Sat Jan 14 13:32:02 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 14 Jan 2006 04:32:02 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: References: Message-ID: <92424062-C956-47A7-8837-FFA0CAC13B8B@redivi.com> On Jan 13, 2006, at 6:48 PM, Read Roberts wrote: > I would like to distribute about 30 Python command-line programs > that use a > single stand-alone Python distribution. Looking at py2app, I only > see the > following two ways of doing it. Can anyone suggest a better approach? What do you want to happen, ideally? Clearly you don't want 30 CLI apps with 30 full Python distributions. There are several workarounds, but in order to make py2app serve your needs I'm going to need to know what that is. Also, you probably have the same need on other platforms, so cx_freeze and/or py2exe should be capable of doing the same thing. -bob From rroberts at adobe.com Sat Jan 14 18:34:40 2006 From: rroberts at adobe.com (Read Roberts) Date: Sat, 14 Jan 2006 09:34:40 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: <92424062-C956-47A7-8837-FFA0CAC13B8B@redivi.com> Message-ID: Thank you for your response. I am distributing a set of tools for editing fonts. Five are quite large and complex, the rest are small programs for doing very specific teaks to the font files. They are all usually run in batch-mode to be applied to many font files, and typically take as input only ad input and output file names and a few option setting, hence the implementation as command-line tools. My current plan is to use py2app to build a single bundle app, and then build a shell command file for each tool to wrap a call to the CLI program inside the bundle app with the name of the desired Python file to to run. - Read Roberts On 1/14/06 4:32 AM, "Bob Ippolito" wrote: > > On Jan 13, 2006, at 6:48 PM, Read Roberts wrote: > >> I would like to distribute about 30 Python command-line programs >> that use a >> single stand-alone Python distribution. Looking at py2app, I only >> see the >> following two ways of doing it. Can anyone suggest a better approach? > > What do you want to happen, ideally? Clearly you don't want 30 CLI > apps with 30 full Python distributions. There are several > workarounds, but in order to make py2app serve your needs I'm going > to need to know what that is. Also, you probably have the same need > on other platforms, so cx_freeze and/or py2exe should be capable of > doing the same thing. > > -bob > Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days From bob at redivi.com Sat Jan 14 22:33:08 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 14 Jan 2006 13:33:08 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: References: Message-ID: <2BD1C256-7395-42E9-ABFC-FC33CAE64534@redivi.com> Given the current implementation, I would build one application that takes the action name as the first argument. This would be similar in style to something like subversion "svn update", "svn commit" or distutils "setup.py install", "setup.py build", etc. One huge advantage to this approach is that the command with no arguments (or help as an argument) can list all of the things you can do with the tool, where 30 commands would get easily lost amongst the bin folder, or even conflict with some other tool. -bob On Jan 14, 2006, at 9:34 AM, Read Roberts wrote: > Thank you for your response. > > I am distributing a set of tools for editing fonts. Five are quite > large and > complex, the rest are small programs for doing very specific teaks > to the > font files. They are all usually run in batch-mode to be applied to > many > font files, and typically take as input only ad input and output > file names > and a few option setting, hence the implementation as command-line > tools. > > My current plan is to use py2app to build a single bundle app, and > then > build a shell command file for each tool to wrap a call to the CLI > program > inside the bundle app with the name of the desired Python file to > to run. > > - Read Roberts > > > On 1/14/06 4:32 AM, "Bob Ippolito" wrote: > >> >> On Jan 13, 2006, at 6:48 PM, Read Roberts wrote: >> >>> I would like to distribute about 30 Python command-line programs >>> that use a >>> single stand-alone Python distribution. Looking at py2app, I only >>> see the >>> following two ways of doing it. Can anyone suggest a better >>> approach? >> >> What do you want to happen, ideally? Clearly you don't want 30 CLI >> apps with 30 full Python distributions. There are several >> workarounds, but in order to make py2app serve your needs I'm going >> to need to know what that is. Also, you probably have the same need >> on other platforms, so cx_freeze and/or py2exe should be capable of >> doing the same thing. >> >> -bob >> > > Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days > From ken at sparklight.com Sun Jan 15 02:41:16 2006 From: ken at sparklight.com (Ken Brooks) Date: Sat, 14 Jan 2006 20:41:16 -0500 Subject: [Pythonmac-SIG] Drag and drop apps? Message-ID: Just curious, has anyone ever managed to make a drag-and-drop MacOS app with Python? I'd love to make an image-batch-processing app that works this way (to pad photos to match my extra-wide Powerbook 17' screen). If so, what is the protocol for discovering what file(s) have been dropped on you? Ken Brooks Sparkling Light Software From bob at redivi.com Sun Jan 15 03:01:44 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 14 Jan 2006 18:01:44 -0800 Subject: [Pythonmac-SIG] Drag and drop apps? In-Reply-To: References: Message-ID: On Jan 14, 2006, at 5:41 PM, Ken Brooks wrote: > Just curious, has anyone ever managed to make a drag-and-drop MacOS > app with Python? I'd love to make an image-batch-processing app > that works this way (to pad photos to match my extra-wide Powerbook > 17' screen). Yes, of course. > If so, what is the protocol for discovering what file(s) have been > dropped on you? Depends on what UI toolkit you're using. For PyObjC/Cocoa, here's Apple's documentation: http://developer.apple.com/documentation/Cocoa/Conceptual/DragandDrop/ If it's just a droplet with no UI (a command line tool that takes filenames on sys.argv), you can get away with py2app's argv_emulation option. -bob From ken at sparklight.com Fri Jan 13 19:07:53 2006 From: ken at sparklight.com (Ken Brooks) Date: Fri, 13 Jan 2006 13:07:53 -0500 Subject: [Pythonmac-SIG] Trouble installing PIL package Message-ID: OS: Tiger 10.4.4 System: 1GHz / 1GB RAM Python: 2.3.5 Using PackageManager to install PIL, came to following problem (at end of quoted text): -------------------------------------------------------------------- PIL 1.1.5 BUILD SUMMARY -------------------------------------------------------------------- version 1.1.5 platform darwin 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] -------------------------------------------------------------------- --- TKINTER support ok --- JPEG support ok --- ZLIB (PNG/ZIP) support ok *** FREETYPE2 support not available -------------------------------------------------------------------- To add a missing option, make sure you have the required library, and set the corresponding ROOT variable in the setup.py script. To check the build, run the selftest.py script. running build_scripts creating build/scripts-2.3 copying and adjusting Scripts/pilconvert.py -> build/scripts-2.3 copying and adjusting Scripts/pildriver.py -> build/scripts-2.3 copying and adjusting Scripts/pilfile.py -> build/scripts-2.3 copying Scripts/pilfont.py -> build/scripts-2.3 copying and adjusting Scripts/pilprint.py -> build/scripts-2.3 changing mode of build/scripts-2.3/pilconvert.py from 644 to 755 changing mode of build/scripts-2.3/pildriver.py from 644 to 755 changing mode of build/scripts-2.3/pilfile.py from 644 to 755 changing mode of build/scripts-2.3/pilfont.py from 664 to 775 changing mode of build/scripts-2.3/pilprint.py from 644 to 755 running install_lib copying build/lib.darwin-8.4.0-Power_Macintosh-2.3/_imaging.so -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL copying build/lib.darwin-8.4.0-Power_Macintosh-2.3/_imagingtk.so -> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/PIL running install_scripts copying build/scripts-2.3/pilconvert.py -> /System/Library/Frameworks/Python.framework/Versions/2.3/bin error: /System/Library/Frameworks/Python.framework/Versions/2.3/bin/pilconvert.py: Permission denied install PIL-1.1.5-source: running ""/Applications/MacPython-2.3/PackageManager.app/Contents/MacOS/Python" setup.py install " failed It really did fail: when I try PIL's selftest.py, it says, *** The _imaging C module is not installed If it was just a matter of copying files, I would use sudo and do it myself - but I've searched that setup.py script and I can't even find in it where the copy commands are being issued! I also tried downloading PIL separately and saying: sudo python setup.py install which got farther but still doesn't pass the selftest check. Help?? Ken Brooks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060113/444acec3/attachment.html From niko at alum.mit.edu Mon Jan 16 09:20:46 2006 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 16 Jan 2006 09:20:46 +0100 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes Message-ID: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> I have a program which identifies duplicates in iTunes and attempts to delete them automatically. It seems to work like a charm, except for one problem: once I have identified the set of songs to delete, I have to go through them one-by-one and delete them. So, if I have accumulated the database_IDs for a set of songs into a list 'songdbids', I do something like: allsongs = app ('iTunes').sources['Library'].playlists ['Library'].tracks for songdbid in songdbids: allsongs.filter (its.database_ID == songdbid).get()[0].delete () This works fine when I test on small music collections, but when I try to run it across my full set of music it takes forever (as you might imagine). Now, the number one rule of appscript performance which has been drilled into my head is to avoid AppleEvents like the plague. To that end, it seems like what I want to do is something like: allsongs.filter (its.database_ID in songdbids]).delete () except I don't think that the 'in' operator works, and it looks like I'm missing a get() in there in any case. Can anyone think of a better way to do this? Perhaps I am on the wrong track altogether in working with database_IDs? I can't select by album or artist, however, as that would delete both copies of the duplicated album (naturally). thanks, Niko From niko at alum.mit.edu Mon Jan 16 15:30:58 2006 From: niko at alum.mit.edu (Niko Matsakis) Date: Mon, 16 Jan 2006 15:30:58 +0100 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes In-Reply-To: References: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> Message-ID: > >> To that end, it seems like what I want to do is something like: >> >> allsongs.filter (its.database_ID in songdbids]).delete () >> >> except I don't think that the 'in' operator works, > > See ch.8 of the appscript manual for a list of supported comparison > forms. Not all Python operators were amenable to overloading; in > this case you need to use 'its.database_ID.isin(songdbids)'. I'll give this a try, thanks! Sorry, I did try looking through the docs for a list precisely like the one you pointed me at, but somehow missed it. Niko From chrisporter9 at wi.rr.com Mon Jan 16 17:56:15 2006 From: chrisporter9 at wi.rr.com (Chris Porter) Date: Mon, 16 Jan 2006 10:56:15 -0600 Subject: [Pythonmac-SIG] MySQLdb Lib Help Message-ID: Hello, complete python newbie here. I've got: OSX 10.4.3 Python 2.3.5 MySQL 4.1.15-standard (of course, all pre-installed, except for MySQL) I don't seem to have the right python module that will allow python to interact with my MySQL databases. I am completely not a programmer, but I can follow a cookbook-type instruction set in Terminal, and have already set up several MySQL databases and php on my personal intranet. Now I want to run a python program (by someone else, of course) that also interacts with my MySQL databases. I've run the test query that searches for the MySQLdb python module, and found I don't have it, so I need to install it. So, I found this list. Looked for the past year for information about this issue: Bob said in June: "You can download a MySQL-python 1.2 installer from: http://pythonmac.org/packages/" So I did. And installed it (though it's for 10.3) and ran the test I found on the web in Terminal: >>> import MySQLdb Traceback (most recent call last): File "", line 1, in ? ImportError: No module named MySQLdb >>> Would someone be kind enough to help me out, please? I'm sort of betting the package installed the lib into the wrong place. Is that possible? -- Chris Porter Illustration chrisporter at wi.rr.com, chrisporter at huntingthesnark.com http://chrisporter.huntingthesnark.com phone/fax: 262.843.3697 From hengist.podd at virgin.net Mon Jan 16 17:56:27 2006 From: hengist.podd at virgin.net (has) Date: Mon, 16 Jan 2006 16:56:27 +0000 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes In-Reply-To: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> References: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> Message-ID: Niko Matsakis wrote: >I have a program which identifies duplicates in iTunes and attempts to delete them automatically. It seems to work like a charm, except for one problem: once I have identified the set of songs to delete, I have to go through them one-by-one and delete them. So, if I have accumulated the database_IDs for a set of songs into a list 'songdbids', I do something like: > > allsongs = app ('iTunes').sources['Library'].playlists ['Library'].tracks > for songdbid in songdbids: > allsongs.filter (its.database_ID == songdbid).get()[0].delete () > >This works fine when I test on small music collections, but when I try to run it across my full set of music it takes forever (as you might imagine). Running a filter test across all tracks is expensive. On a large playlist, doing it repeatedly is going to be murder. So this is the operation you want to minimize/eliminate. >Now, the number one rule of appscript performance which has been drilled into my head is to avoid AppleEvents like the plague. Yes, although dispatching the events themselves are relatively cheap these days (context switching in OS X doesn't suck like it did in OS 9); it's the cost of packing and unpacking their payloads, evaluating queries against the application's object model, etc. that sucks up most of the cycles. Of course, the fewer events you send, the less packing/unpacking/querying/etc. is going to be done as well, so it all pans out in the end. :) >To that end, it seems like what I want to do is something like: > > allsongs.filter (its.database_ID in songdbids]).delete () > >except I don't think that the 'in' operator works, See ch.8 of the appscript manual for a list of supported comparison forms. Not all Python operators were amenable to overloading; in this case you need to use 'its.database_ID.isin(songdbids)'. >and it looks like I'm missing a get() in there in any case. Depends what you're trying to get. iTunes scripting interface is pretty extensive, but a lot of the implementation is rather crude and many commands won't work on more than one object at a time. So the above might work as-is, but it probably won't, in which case you need to get a list of track references and tell iTunes to delete each individually: for song in allsongs.filter (its.database_ID.isin(songdbids)): song.delete() >Can anyone think of a better way to do this? Perhaps I am on the wrong track altogether in working with database_IDs? They seem to be the obvious way to check for dupes. You just don't want to perform multiple filter tests across your entire playlist to locate tracks by DB ID. But a single test shouldn't be too punishing (assuming iTunes can manage it ok). >I can't select by album or artist, however, as that would delete both copies of the duplicated album (naturally). And you'd still be running tons of filter tests to do it. Anyway, try the fixes shown above. If it still doesn't work out well for you, another option would be to try an alternative approach like: tracksRef = app('iTunes').playlists['Library'].tracks d = {} for id, track in zip(tracksRef.database_ID(), tracksRef()): d[id] = d.get(id, []) + [track] for dupes in [i for i in d.values() if len(i) > 1]: for dupe in dupes[1:]: dupe.delete() No idea how that'll compare; getting a list of references to every single track won't be cheap due to packing/unpacking costs. You just have to experiment. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From cdamundsen at gmail.com Mon Jan 16 18:27:32 2006 From: cdamundsen at gmail.com (Craig Amundsen) Date: Mon, 16 Jan 2006 09:27:32 -0800 Subject: [Pythonmac-SIG] MySQLdb Lib Help In-Reply-To: References: Message-ID: <8dc0c28f0601160927h45f3f02kdf32c0a54ba0edfc@mail.gmail.com> Hi - > >>> import MySQLdb > Traceback (most recent call last): > File "", line 1, in ? > ImportError: No module named MySQLdb What is the output from ls /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ That's where you should find the MySQLdb directory if it got installed correctly. - Craig From Larry.A.Meyn at nasa.gov Mon Jan 16 18:45:25 2006 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Mon, 16 Jan 2006 09:45:25 -0800 Subject: [Pythonmac-SIG] MySQLdb Lib Help In-Reply-To: References: Message-ID: <6EC92987-9D8A-4C1F-982B-0F038BA42214@nasa.gov> My guess is that your PATH needs to have /usr/local/bin prepended to it to make sure the correct python installation is being used when running from the terminal. --Larry On Jan 16, 2006, at 8:56 AM, Chris Porter wrote: > Hello, complete python newbie here. > > I've got: > > OSX 10.4.3 > Python 2.3.5 > MySQL 4.1.15-standard > (of course, all pre-installed, except for MySQL) > > I don't seem to have the right python module that will allow python > to interact with my MySQL > databases. > > I am completely not a programmer, but I can follow a cookbook-type > instruction set in Terminal, and > have already set up several MySQL databases and php on my personal > intranet. Now I want to run a > python program (by someone else, of course) that also interacts > with my MySQL databases. I've run > the test query that searches for the MySQLdb python module, and > found I don't have it, so I need to > install it. So, I found this list. Looked for the past year for > information about this issue: > > Bob said in June: > "You can download a MySQL-python 1.2 installer from: > http://pythonmac.org/packages/" > > So I did. And installed it (though it's for 10.3) and ran the > test I found on the web in Terminal: > >>>> import MySQLdb > Traceback (most recent call last): > File "", line 1, in ? > ImportError: No module named MySQLdb >>>> > > > Would someone be kind enough to help me out, please? > > I'm sort of betting the package installed the lib into > the wrong place. Is that possible? > -- Chris Porter Illustration > chrisporter at wi.rr.com, chrisporter at huntingthesnark.com > http://chrisporter.huntingthesnark.com > phone/fax: 262.843.3697 > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Larry.A.Meyn at nasa.gov Mon Jan 16 18:53:13 2006 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Mon, 16 Jan 2006 09:53:13 -0800 Subject: [Pythonmac-SIG] MySQLdb Lib Help In-Reply-To: References: Message-ID: Chris, You can create or modify the .bash_profile file in your home directory to modify PATH. An example is shown below. Larry # .bash_profile # Get the aliases and functions if [ -f ~/.bashrc ]; then . ~/.bashrc fi # User specific environment and startup programs PATH=/usr/local/bin:$PATH;export PATH On Jan 16, 2006, at 8:56 AM, Chris Porter wrote: > Hello, complete python newbie here. > > I've got: > > OSX 10.4.3 > Python 2.3.5 > MySQL 4.1.15-standard > (of course, all pre-installed, except for MySQL) > > I don't seem to have the right python module that will allow python > to interact with my MySQL > databases. > > I am completely not a programmer, but I can follow a cookbook-type > instruction set in Terminal, and > have already set up several MySQL databases and php on my personal > intranet. Now I want to run a > python program (by someone else, of course) that also interacts > with my MySQL databases. I've run > the test query that searches for the MySQLdb python module, and > found I don't have it, so I need to > install it. So, I found this list. Looked for the past year for > information about this issue: > > Bob said in June: > "You can download a MySQL-python 1.2 installer from: > http://pythonmac.org/packages/" > > So I did. And installed it (though it's for 10.3) and ran the > test I found on the web in Terminal: > >>>> import MySQLdb > Traceback (most recent call last): > File "", line 1, in ? > ImportError: No module named MySQLdb >>>> > > > Would someone be kind enough to help me out, please? > > I'm sort of betting the package installed the lib into > the wrong place. Is that possible? > -- Chris Porter Illustration > chrisporter at wi.rr.com, chrisporter at huntingthesnark.com > http://chrisporter.huntingthesnark.com > phone/fax: 262.843.3697 > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060116/06bfefbe/attachment.htm From Larry.A.Meyn at nasa.gov Mon Jan 16 18:59:45 2006 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Mon, 16 Jan 2006 09:59:45 -0800 Subject: [Pythonmac-SIG] MySQLdb Lib Help In-Reply-To: References: Message-ID: <4BEA5A23-E534-4D06-93B2-3D1EE0284FD7@nasa.gov> Chris, My previous comments assumed that you had installed the framework build of Python, which if I had read your message better I would have know was wrong. Sorry, no morning coffee yet. It is possible that the MySQLdb was installed in the wrong location. As Craig said it should be in /Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/site-packages/ Sorry about the misunderstanding. Larry On Jan 16, 2006, at 8:56 AM, Chris Porter wrote: > Hello, complete python newbie here. > > I've got: > > OSX 10.4.3 > Python 2.3.5 > MySQL 4.1.15-standard > (of course, all pre-installed, except for MySQL) > > I don't seem to have the right python module that will allow python > to interact with my MySQL > databases. > > I am completely not a programmer, but I can follow a cookbook-type > instruction set in Terminal, and > have already set up several MySQL databases and php on my personal > intranet. Now I want to run a > python program (by someone else, of course) that also interacts > with my MySQL databases. I've run > the test query that searches for the MySQLdb python module, and > found I don't have it, so I need to > install it. So, I found this list. Looked for the past year for > information about this issue: > > Bob said in June: > "You can download a MySQL-python 1.2 installer from: > http://pythonmac.org/packages/" > > So I did. And installed it (though it's for 10.3) and ran the > test I found on the web in Terminal: > >>>> import MySQLdb > Traceback (most recent call last): > File "", line 1, in ? > ImportError: No module named MySQLdb >>>> > > > Would someone be kind enough to help me out, please? > > I'm sort of betting the package installed the lib into > the wrong place. Is that possible? > -- Chris Porter Illustration > chrisporter at wi.rr.com, chrisporter at huntingthesnark.com > http://chrisporter.huntingthesnark.com > phone/fax: 262.843.3697 > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Mon Jan 16 19:10:20 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 Jan 2006 10:10:20 -0800 Subject: [Pythonmac-SIG] MySQLdb Lib Help In-Reply-To: <4BEA5A23-E534-4D06-93B2-3D1EE0284FD7@nasa.gov> References: <4BEA5A23-E534-4D06-93B2-3D1EE0284FD7@nasa.gov> Message-ID: <8F57CE84-2E40-4C0A-B72E-416ED83BD0BB@redivi.com> That's not where it should be. It should be in /Library/Python/2.3/ site-packages -- the thing is that since he's using the system Python and old packages, he must install TigerPython23Compat before any of those old packages will work. -bob On Jan 16, 2006, at 9:59 AM, Larry Meyn wrote: > Chris, > > My previous comments assumed that you had installed the framework > build of Python, which if I had read your message better I would have > know was wrong. Sorry, no morning coffee yet. It is possible that > the MySQLdb was installed in the wrong location. As Craig said it > should be in /Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/ > > Sorry about the misunderstanding. > > Larry > > On Jan 16, 2006, at 8:56 AM, Chris Porter wrote: > >> Hello, complete python newbie here. >> >> I've got: >> >> OSX 10.4.3 >> Python 2.3.5 >> MySQL 4.1.15-standard >> (of course, all pre-installed, except for MySQL) >> >> I don't seem to have the right python module that will allow python >> to interact with my MySQL >> databases. >> >> I am completely not a programmer, but I can follow a cookbook-type >> instruction set in Terminal, and >> have already set up several MySQL databases and php on my personal >> intranet. Now I want to run a >> python program (by someone else, of course) that also interacts >> with my MySQL databases. I've run >> the test query that searches for the MySQLdb python module, and >> found I don't have it, so I need to >> install it. So, I found this list. Looked for the past year for >> information about this issue: >> >> Bob said in June: >> "You can download a MySQL-python 1.2 installer from: >> http://pythonmac.org/packages/" >> >> So I did. And installed it (though it's for 10.3) and ran the >> test I found on the web in Terminal: >> >>>>> import MySQLdb >> Traceback (most recent call last): >> File "", line 1, in ? >> ImportError: No module named MySQLdb >>>>> >> >> >> Would someone be kind enough to help me out, please? >> >> I'm sort of betting the package installed the lib into >> the wrong place. Is that possible? >> -- Chris Porter Illustration >> chrisporter at wi.rr.com, chrisporter at huntingthesnark.com >> http://chrisporter.huntingthesnark.com >> phone/fax: 262.843.3697 >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From chrisporter9 at wi.rr.com Mon Jan 16 20:20:59 2006 From: chrisporter9 at wi.rr.com (Chris Porter) Date: Mon, 16 Jan 2006 13:20:59 -0600 Subject: [Pythonmac-SIG] MySQLdb Lib Help In-Reply-To: <8dc0c28f0601160927h45f3f02kdf32c0a54ba0edfc@mail.gmail.com> Message-ID: > Hi - > > > >>> import MySQLdb > > Traceback (most recent call last): > > File "", line 1, in ? > > ImportError: No module named MySQLdb > > What is the output from > > ls /Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages/ > > That's where you should find the MySQLdb directory if it got installed > correctly. > > - Craig Seems to be missing. In Library/Frameworks, there is only iMoviePluginAPI.framework, StuffIt.framework, and PrintMeSSL.framework. I have TinkerTool set to display hidden and system files. (Tried this, because I couldn't cd to the directory you indicated--it isn't there) From chrisporter9 at wi.rr.com Mon Jan 16 20:24:56 2006 From: chrisporter9 at wi.rr.com (Chris Porter) Date: Mon, 16 Jan 2006 13:24:56 -0600 Subject: [Pythonmac-SIG] MySQLdb Lib Help In-Reply-To: <4BEA5A23-E534-4D06-93B2-3D1EE0284FD7@nasa.gov> Message-ID: > Chris, > > My previous comments assumed that you had installed the framework > build of Python, which if I had read your message better I would have > know was wrong. Sorry, no morning coffee yet. It is possible that > the MySQLdb was installed in the wrong location. As Craig said it > should be in /Library/Frameworks/Python.framework/Versions/2.3/lib/ > python2.3/site-packages/ > > Sorry about the misunderstanding. > > Larry That's OK. Yes, whatever that MySQL_python installation package did, it didn't install the module in Library/Frameworks/ I will have to go looking for it, maybe move it. I didn't see information about what the package did, I'll try searching for that next. And, yes, using just the regular old python that came with Tiger. From chrisporter9 at wi.rr.com Mon Jan 16 20:56:14 2006 From: chrisporter9 at wi.rr.com (Chris Porter) Date: Mon, 16 Jan 2006 13:56:14 -0600 Subject: [Pythonmac-SIG] MySQLdb Lib Help Message-ID: Found the files, possibly in the wrong place. I found this: System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/site-packages(alias) Clicking on the alias brings up these files: Extras.pth README .DS_Store(system file, I know) I also found this: Library/Python/2.3/ Opening 2.3 shows me these files and directories _mysql_exceptions.py _mysql_exceptions.pyc _mysql_exceptions.pyo _mysql.so MySQLdb/(full of stuff) site-packages/(three files) Ss, should the files in Library/Python/2.3/ be moved to the System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3? From chrisporter9 at wi.rr.com Mon Jan 16 21:04:25 2006 From: chrisporter9 at wi.rr.com (Chris Porter) Date: Mon, 16 Jan 2006 14:04:25 -0600 Subject: [Pythonmac-SIG] MySQLdb Lib Help In-Reply-To: <8F57CE84-2E40-4C0A-B72E-416ED83BD0BB@redivi.com> Message-ID: > That's not where it should be. It should be in /Library/Python/2.3/ > site-packages -- the thing is that since he's using the system Python > and old packages, he must install TigerPython23Compat before any of > those old packages will work. > > -bob You folks rock!. Thank you so much, I now have a python connection to my MySQL databases. Installing the TigerPython23Compat apparently gave python the necessary information to use the MySQLdb lib. I'm very grateful for your help. From rroberts at adobe.com Mon Jan 16 21:59:41 2006 From: rroberts at adobe.com (Read Roberts) Date: Mon, 16 Jan 2006 12:59:41 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: <2BD1C256-7395-42E9-ABFC-FC33CAE64534@redivi.com> Message-ID: I've run into a glitch in this approach. Although I can easily build a py2app application that takes the action name as the first argument, and invoke it from the command line with: FDK.app/Contents/MacOS/FDK, I cannot execute a symbolic link to the same file, The following produces an error: Ln -s FDK.app/Contents/MacOS/FDK pythonFDK PythonFDK -u -> pythonFDK[834] The Info.plist file must have values for the CFBundleName or CFBundleExecutable strings. I'd rather not expose an average user to typing a path into the middle of a bundle app. Do you know offhand if this issue is fixable, or if there is a way to run the bundle app from the command line and provide sys.argv arguments? If this is documented somewhere, just a pointer to the docs would be helpful. - Read Roberts On 1/14/06 1:33 PM, "Bob Ippolito" wrote: > Given the current implementation, I would build one application that > takes the action name as the first argument. This would be similar > in style to something like subversion "svn update", "svn commit" or > distutils "setup.py install", "setup.py build", etc. > > One huge advantage to this approach is that the command with no > arguments (or help as an argument) can list all of the things you can > do with the tool, where 30 commands would get easily lost amongst the > bin folder, or even conflict with some other tool. > > -bob > > On Jan 14, 2006, at 9:34 AM, Read Roberts wrote: > >> Thank you for your response. >> >> I am distributing a set of tools for editing fonts. Five are quite >> large and >> complex, the rest are small programs for doing very specific teaks >> to the >> font files. They are all usually run in batch-mode to be applied to >> many >> font files, and typically take as input only ad input and output >> file names >> and a few option setting, hence the implementation as command-line >> tools. >> >> My current plan is to use py2app to build a single bundle app, and >> then >> build a shell command file for each tool to wrap a call to the CLI >> program >> inside the bundle app with the name of the desired Python file to >> to run. >> >> - Read Roberts >> >> >> On 1/14/06 4:32 AM, "Bob Ippolito" wrote: >> >>> >>> On Jan 13, 2006, at 6:48 PM, Read Roberts wrote: >>> >>>> I would like to distribute about 30 Python command-line programs >>>> that use a >>>> single stand-alone Python distribution. Looking at py2app, I only >>>> see the >>>> following two ways of doing it. Can anyone suggest a better >>>> approach? >>> >>> What do you want to happen, ideally? Clearly you don't want 30 CLI >>> apps with 30 full Python distributions. There are several >>> workarounds, but in order to make py2app serve your needs I'm going >>> to need to know what that is. Also, you probably have the same need >>> on other platforms, so cx_freeze and/or py2exe should be capable of >>> doing the same thing. >>> >>> -bob >>> >> >> Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days >> > Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days From njriley at uiuc.edu Mon Jan 16 22:16:40 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Mon, 16 Jan 2006 15:16:40 -0600 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: References: <2BD1C256-7395-42E9-ABFC-FC33CAE64534@redivi.com> Message-ID: <20060116211640.GA91812@uiuc.edu> On Mon, Jan 16, 2006 at 12:59:41PM -0800, Read Roberts wrote: > I've run into a glitch in this approach. Although I can easily build a > py2app application that takes the action name as the first argument, and > invoke it from the command line with: > FDK.app/Contents/MacOS/FDK, > > I cannot execute a symbolic link to the same file, The following produces an > error: > > Ln -s FDK.app/Contents/MacOS/FDK pythonFDK > PythonFDK -u > -> pythonFDK[834] The Info.plist file must have values for the CFBundleName > or CFBundleExecutable strings. > > I'd rather not expose an average user to typing a path into the middle of a > bundle app. Do you know offhand if this issue is fixable, or if there is a > way to run the bundle app from the command line and provide sys.argv > arguments? If this is documented somewhere, just a pointer to the docs would > be helpful. Try using a shell script, for example: #!/bin/zsh -f exec FDK.app/Contents/MacOS/FDK $* If the app can be relocated, as opposed to living in a framework or similar, you might consider writing a small executable which uses Launch Services to look up the location of FDK (best by bundle ID, e.g. com.adobe.FDK) and execs it passing through the arguments as above. You could hack the source code of my launch tool to do so (http://web.sabi.net/nriley/software/#launch). -- Nicholas Riley | From bob at redivi.com Mon Jan 16 22:50:51 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 Jan 2006 13:50:51 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: References: Message-ID: py2app is not designed to build command-line tools, and Mac OS X application bundles are not designed to be used as such, so whatever you do is a workaround. What you'll need is a shell script that executes the application with its full path. You could use something like this , which would allow the .app to still be movable: #!/usr/bin/env python2.4 from Carbon.Launch import LSFindApplicationForInfo from Carbon.CoreFoundation import kCFURLPOSIXPathStyle import os kLSUnknownCreator = '\x00\x00\x00\x00' fsRef, cfURL = LSFindApplicationForInfo(kLSUnknownCreator, None, "FDK.app") path = os.path.join(fsRef.as_pathname(), 'Contents', 'MacOS', 'FDK') os.execv(path, [path] + sys.argv[1:]) If you need to reduce startup time you might want to ask users to put it in a specific place and just do something like this: #!/bin/sh /Applications/FDK.app/Contents/MacOS/FDK $@ -bob On Jan 16, 2006, at 12:59 PM, Read Roberts wrote: > I've run into a glitch in this approach. Although I can easily build a > py2app application that takes the action name as the first > argument, and > invoke it from the command line with: > FDK.app/Contents/MacOS/FDK, > > I cannot execute a symbolic link to the same file, The following > produces an > error: > > Ln -s FDK.app/Contents/MacOS/FDK pythonFDK > PythonFDK -u > -> pythonFDK[834] The Info.plist file must have values for the > CFBundleName > or CFBundleExecutable strings. > > I'd rather not expose an average user to typing a path into the > middle of a > bundle app. Do you know offhand if this issue is fixable, or if > there is a > way to run the bundle app from the command line and provide sys.argv > arguments? If this is documented somewhere, just a pointer to the > docs would > be helpful. > > - Read Roberts > > > On 1/14/06 1:33 PM, "Bob Ippolito" wrote: > >> Given the current implementation, I would build one application that >> takes the action name as the first argument. This would be similar >> in style to something like subversion "svn update", "svn commit" or >> distutils "setup.py install", "setup.py build", etc. >> >> One huge advantage to this approach is that the command with no >> arguments (or help as an argument) can list all of the things you can >> do with the tool, where 30 commands would get easily lost amongst the >> bin folder, or even conflict with some other tool. >> >> -bob >> >> On Jan 14, 2006, at 9:34 AM, Read Roberts wrote: >> >>> Thank you for your response. >>> >>> I am distributing a set of tools for editing fonts. Five are quite >>> large and >>> complex, the rest are small programs for doing very specific teaks >>> to the >>> font files. They are all usually run in batch-mode to be applied to >>> many >>> font files, and typically take as input only ad input and output >>> file names >>> and a few option setting, hence the implementation as command-line >>> tools. >>> >>> My current plan is to use py2app to build a single bundle app, and >>> then >>> build a shell command file for each tool to wrap a call to the CLI >>> program >>> inside the bundle app with the name of the desired Python file to >>> to run. >>> >>> - Read Roberts >>> >>> >>> On 1/14/06 4:32 AM, "Bob Ippolito" wrote: >>> >>>> >>>> On Jan 13, 2006, at 6:48 PM, Read Roberts wrote: >>>> >>>>> I would like to distribute about 30 Python command-line programs >>>>> that use a >>>>> single stand-alone Python distribution. Looking at py2app, I only >>>>> see the >>>>> following two ways of doing it. Can anyone suggest a better >>>>> approach? >>>> >>>> What do you want to happen, ideally? Clearly you don't want 30 CLI >>>> apps with 30 full Python distributions. There are several >>>> workarounds, but in order to make py2app serve your needs I'm going >>>> to need to know what that is. Also, you probably have the same >>>> need >>>> on other platforms, so cx_freeze and/or py2exe should be capable of >>>> doing the same thing. >>>> >>>> -bob >>>> >>> >>> Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days >>> >> > > Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days > From Larry.A.Meyn at nasa.gov Tue Jan 17 00:36:34 2006 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Mon, 16 Jan 2006 15:36:34 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: References: Message-ID: You might try using Platypus to give an interface to your application. I haven't used it in awhile, but it may be worth a look. --Larry On Jan 16, 2006, at 12:59 PM, Read Roberts wrote: > I've run into a glitch in this approach. Although I can easily build a > py2app application that takes the action name as the first > argument, and > invoke it from the command line with: > FDK.app/Contents/MacOS/FDK, > > I cannot execute a symbolic link to the same file, The following > produces an > error: > > Ln -s FDK.app/Contents/MacOS/FDK pythonFDK > PythonFDK -u > -> pythonFDK[834] The Info.plist file must have values for the > CFBundleName > or CFBundleExecutable strings. > > I'd rather not expose an average user to typing a path into the > middle of a > bundle app. Do you know offhand if this issue is fixable, or if > there is a > way to run the bundle app from the command line and provide sys.argv > arguments? If this is documented somewhere, just a pointer to the > docs would > be helpful. > > - Read Roberts > > > On 1/14/06 1:33 PM, "Bob Ippolito" wrote: > >> Given the current implementation, I would build one application that >> takes the action name as the first argument. This would be similar >> in style to something like subversion "svn update", "svn commit" or >> distutils "setup.py install", "setup.py build", etc. >> >> One huge advantage to this approach is that the command with no >> arguments (or help as an argument) can list all of the things you can >> do with the tool, where 30 commands would get easily lost amongst the >> bin folder, or even conflict with some other tool. >> >> -bob >> >> On Jan 14, 2006, at 9:34 AM, Read Roberts wrote: >> >>> Thank you for your response. >>> >>> I am distributing a set of tools for editing fonts. Five are quite >>> large and >>> complex, the rest are small programs for doing very specific teaks >>> to the >>> font files. They are all usually run in batch-mode to be applied to >>> many >>> font files, and typically take as input only ad input and output >>> file names >>> and a few option setting, hence the implementation as command-line >>> tools. >>> >>> My current plan is to use py2app to build a single bundle app, and >>> then >>> build a shell command file for each tool to wrap a call to the CLI >>> program >>> inside the bundle app with the name of the desired Python file to >>> to run. >>> >>> - Read Roberts >>> >>> >>> On 1/14/06 4:32 AM, "Bob Ippolito" wrote: >>> >>>> >>>> On Jan 13, 2006, at 6:48 PM, Read Roberts wrote: >>>> >>>>> I would like to distribute about 30 Python command-line programs >>>>> that use a >>>>> single stand-alone Python distribution. Looking at py2app, I only >>>>> see the >>>>> following two ways of doing it. Can anyone suggest a better >>>>> approach? >>>> >>>> What do you want to happen, ideally? Clearly you don't want 30 CLI >>>> apps with 30 full Python distributions. There are several >>>> workarounds, but in order to make py2app serve your needs I'm going >>>> to need to know what that is. Also, you probably have the same >>>> need >>>> on other platforms, so cx_freeze and/or py2exe should be capable of >>>> doing the same thing. >>>> >>>> -bob >>>> >>> >>> Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days >>> >> > > Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Tue Jan 17 00:51:21 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 16 Jan 2006 15:51:21 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: References: Message-ID: That solves a different problem. Presumably he's using py2app because it collects all of the dependencies (python, dylibs, packages, modules and extensions) for a Python-based application in such a way that it works correctly on a stock machine. Platypus just wraps a CLI tool with a GUI, and does nothing about dependencies. You'd definitely have to do some ugly stuff in order to wrap platypus around an app bundle that's supposed to be used as a CLI tool. -bob On Jan 16, 2006, at 3:36 PM, Larry Meyn wrote: > You might try using Platypus > to give an interface to your application. I haven't used it in > awhile, but it may be worth a look. > --Larry > > On Jan 16, 2006, at 12:59 PM, Read Roberts wrote: > >> I've run into a glitch in this approach. Although I can easily >> build a >> py2app application that takes the action name as the first >> argument, and >> invoke it from the command line with: >> FDK.app/Contents/MacOS/FDK, >> >> I cannot execute a symbolic link to the same file, The following >> produces an >> error: >> >> Ln -s FDK.app/Contents/MacOS/FDK pythonFDK >> PythonFDK -u >> -> pythonFDK[834] The Info.plist file must have values for the >> CFBundleName >> or CFBundleExecutable strings. >> >> I'd rather not expose an average user to typing a path into the >> middle of a >> bundle app. Do you know offhand if this issue is fixable, or if >> there is a >> way to run the bundle app from the command line and provide sys.argv >> arguments? If this is documented somewhere, just a pointer to the >> docs would >> be helpful. >> >> - Read Roberts >> >> >> On 1/14/06 1:33 PM, "Bob Ippolito" wrote: >> >>> Given the current implementation, I would build one application that >>> takes the action name as the first argument. This would be similar >>> in style to something like subversion "svn update", "svn commit" or >>> distutils "setup.py install", "setup.py build", etc. >>> >>> One huge advantage to this approach is that the command with no >>> arguments (or help as an argument) can list all of the things you >>> can >>> do with the tool, where 30 commands would get easily lost amongst >>> the >>> bin folder, or even conflict with some other tool. >>> >>> -bob >>> >>> On Jan 14, 2006, at 9:34 AM, Read Roberts wrote: >>> >>>> Thank you for your response. >>>> >>>> I am distributing a set of tools for editing fonts. Five are quite >>>> large and >>>> complex, the rest are small programs for doing very specific teaks >>>> to the >>>> font files. They are all usually run in batch-mode to be applied to >>>> many >>>> font files, and typically take as input only ad input and output >>>> file names >>>> and a few option setting, hence the implementation as command-line >>>> tools. >>>> >>>> My current plan is to use py2app to build a single bundle app, and >>>> then >>>> build a shell command file for each tool to wrap a call to the CLI >>>> program >>>> inside the bundle app with the name of the desired Python file to >>>> to run. >>>> >>>> - Read Roberts >>>> >>>> >>>> On 1/14/06 4:32 AM, "Bob Ippolito" wrote: >>>> >>>>> >>>>> On Jan 13, 2006, at 6:48 PM, Read Roberts wrote: >>>>> >>>>>> I would like to distribute about 30 Python command-line programs >>>>>> that use a >>>>>> single stand-alone Python distribution. Looking at py2app, I only >>>>>> see the >>>>>> following two ways of doing it. Can anyone suggest a better >>>>>> approach? >>>>> >>>>> What do you want to happen, ideally? Clearly you don't want 30 >>>>> CLI >>>>> apps with 30 full Python distributions. There are several >>>>> workarounds, but in order to make py2app serve your needs I'm >>>>> going >>>>> to need to know what that is. Also, you probably have the same >>>>> need >>>>> on other platforms, so cx_freeze and/or py2exe should be >>>>> capable of >>>>> doing the same thing. >>>>> >>>>> -bob >>>>> >>>> >>>> Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days >>>> >>> >> >> Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days >> >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From rroberts at adobe.com Tue Jan 17 03:00:03 2006 From: rroberts at adobe.com (Read Roberts) Date: Mon, 16 Jan 2006 18:00:03 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: Message-ID: I think I will go for the shell script option. That works very nicely, and I can provide a small Python script that will create a sym-link from the /Applications directory to the top level of my distribution dir tree. Thank you very much for help! Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days From niko at alum.mit.edu Tue Jan 17 14:15:58 2006 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 17 Jan 2006 14:15:58 +0100 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes In-Reply-To: References: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> Message-ID: >> and it looks like I'm missing a get() in there in any case. > > Depends what you're trying to get. iTunes scripting interface is > pretty extensive, but a lot of the implementation is rather crude > and many commands won't work on more than one object at a time. So > the above might work as-is, but it probably won't, in which case > you need to get a list of track references and tell iTunes to > delete each individually: Okay, so this error is probably iTunes' fault? > appscript.specifier.CommandError: Application Error -10014: Handler > only handles single objects. > Failed command: app(u'/Applications/iTunes.app').sources > ['Library'].playlists['Library'].tracks.filter(its.database_ID.isin > ([7253, 7255, 7257, 7259, 7261, 7263, 7265, 7267, 7269, 7271, 7273, > 7275, 7277])).get() Niko From niko at alum.mit.edu Tue Jan 17 14:24:42 2006 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 17 Jan 2006 14:24:42 +0100 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes In-Reply-To: References: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> Message-ID: <19A5379F-EBFC-4A1F-824D-06560A216538@alum.mit.edu> Shoot, fired that last e-mail off a bit early. Please ignore in favor of this more complete version. > Depends what you're trying to get. iTunes scripting interface is > pretty extensive, but a lot of the implementation is rather crude > and many commands won't work on more than one object at a time. So > the above might work as-is, but it probably won't, in which case > you need to get a list of track references and tell iTunes to > delete each individually: Okay, so this error is probably iTunes' fault? > appscript.specifier.CommandError: Application Error -10014: Handler > only handles single objects. > Failed command: app(u'/Applications/iTunes.app').sources > ['Library'].playlists['Library'].tracks.filter(its.database_ID.isin > ([7253, 7255, 7257, 7259, 7261, 7263, 7265, 7267, 7269, 7271, 7273, > 7275, 7277])).get() As you can see, I am just trying to fetch a list of references in this case, not delete them in one step. Here is my python code: handlers = _get_tracks().filter (its.database_ID.isin (idlist)).get () for handle in handlers: handle.delete () where _get_tracks() is: def _get_tracks (): return app ('iTunes').sources['Library'].playlists['Library'].tracks Is there something wrong with what I am doing? If I modify its.database_ID.isin() to be its.database_ID == id, and iterate through idlist, it works fine (but, as we know, slow); this makes me think it is correct. If this *is* just a limitation in iTunes, I have to admit I'm a bit of a loss as to how to proceed. I guess one option is just to purge the files themselves, and then use one of these scripts which purges all tracks that have no corresponding file. Well, that or clear the iTunes library entirely and re-build based on the files that still exist. While these two solutions would work for me, they are clearly hacks and I was hoping to roll this into something useful to a wider audience some day. thanks again, Niko From hengist.podd at virgin.net Tue Jan 17 14:43:21 2006 From: hengist.podd at virgin.net (has) Date: Tue, 17 Jan 2006 13:43:21 +0000 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes In-Reply-To: <19A5379F-EBFC-4A1F-824D-06560A216538@alum.mit.edu> References: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> <19A5379F-EBFC-4A1F-824D-06560A216538@alum.mit.edu> Message-ID: Niko Matsakis wrote: >>Depends what you're trying to get. iTunes scripting interface is pretty extensive, but a lot of the implementation is rather crude and many commands won't work on more than one object at a time. > >Okay, so this error is probably iTunes' fault? Yes. >>appscript.specifier.CommandError: Application Error -10014: Handler only handles single objects. >> Failed command: app(u'/Applications/iTunes.app').sources['Library'].playlists['Library'].tracks.filter(its.database_ID.isin([7253, 7255, 7257, 7259, 7261, 7263, 7265, 7267, 7269, 7271, 7273, 7275, 7277])).get() > >As you can see, I am just trying to fetch a list of references in this case, not delete them in one step. Here is my python code: > > handlers = _get_tracks().filter (its.database_ID.isin (idlist)).get () > >Is there something wrong with what I am doing? The code's well-formed, but iTunes isn't smart enough to handle your request. Its implementation is second-rate, as I say. >If this *is* just a limitation in iTunes, I have to admit I'm a bit of a loss as to how to proceed. Did you try the alternative script I suggested? How did that fare? has -- http://freespace.virgin.net/hamish.sanderson/ From niko at alum.mit.edu Tue Jan 17 15:17:29 2006 From: niko at alum.mit.edu (Niko Matsakis) Date: Tue, 17 Jan 2006 15:17:29 +0100 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes In-Reply-To: References: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> <19A5379F-EBFC-4A1F-824D-06560A216538@alum.mit.edu> Message-ID: <615F8B88-8135-44AB-B2BE-B5A2C478C5B3@alum.mit.edu> >> If this *is* just a limitation in iTunes, I have to admit I'm a >> bit of a loss as to how to proceed. > > Did you try the alternative script I suggested? How did that fare? Well, your alternative doesn't quite do what I want. The duplicates don't actually have the same database_ID: instead, there are two songs that have the same artist/album/tracknumber, or other conditions. I did, however, come up with another possibility along the same lines; I've implemented it, but I haven't been able to test it for speed against the whole library. What I've ended up with is something that's actually somewhat similar: I extract from each set of duplicates the artist name, and then select all songs with that artist, and their database ID. I then delete the track if the database ID is in the list of IDs to kill. But now, closer to your original suggestion, I am thinking of just selecting the song handle and database ID of EVERY track, once, and then iterating through. After all, when I start up I load a lot of information about every track (artist, album, etc) this way and it's not *that* slow. Well, I'll benchmark the two approaches against my full library and report back on the results :). The question is whether having more AppleEvents will be slower than selecting way too much data. thanks for your help, Niko From ken at sparklight.com Tue Jan 17 18:10:22 2006 From: ken at sparklight.com (Ken Brooks) Date: Tue, 17 Jan 2006 12:10:22 -0500 Subject: [Pythonmac-SIG] Newbie environment questions In-Reply-To: References: Message-ID: 1. I create a window, define my little function in it, save it as "foo.py", then: I>>> import foo fine. I now find a bug, or want to add more functions to foo.py. I edit, save, and: I>>> import foo nothing changes! New functions not recognized. I>>> del foo I>>> import foo Still nothing changes! So how does the debug loop work? How can I reload a module short of relaunching the environment?? 2. I really wish for the "doskey" feature that lets you easily retrieve and edit a line previously typed to the interactive interpreter. Does it exist here? (Do you think it would be easy to add?) Thanks, Ken Brooks Sparkling Light Software From Chris.Barker at noaa.gov Tue Jan 17 18:55:36 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 17 Jan 2006 09:55:36 -0800 Subject: [Pythonmac-SIG] Newbie environment questions In-Reply-To: References: Message-ID: <43CD2F98.5050303@noaa.gov> Ken Brooks wrote: > Still nothing changes! So how does the debug loop work? How can I > reload a module short of relaunching the environment?? ^^^^^^ You've just inadvertently answered your own question. That's what we mean when we say "Python fits your brain": >>> reload(foo) Python caches modules so that if one module is imported in ten different places, it doesn't reload them each time. To force a reload you use, appropriately enough, the reload function. > 2. I really wish for the "doskey" feature that lets you easily > retrieve and edit a line previously typed to the interactive > interpreter. Does it exist here? Yup. It's called readline. Apple doesn't ship it with OS-X, because it's licensed under the GPL, but you can install in separately, or you can install a new version of python that has it. See: http://undefined.org/python/ for a newer Python, and: http://www.pythonmac.org/packages/ For an assortment of add-on packages There is a readline for th python 2.3 that came with OS-X 10.4 there. It may work with 10.4 also, if you install "TigerPython23Compat" from that page also. All that being said, you might want to try one of the fancier python shells for interactive use, like ipython. Or, just write your entire script in a file (or multiple files) and restart python each time. It's rare that something take that long to run that re-starting is a problem. You can start it with: $ python -i MyScript.py and you'll get the interpreter prompt when it's done running. -Chris - Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Tue Jan 17 18:57:35 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 17 Jan 2006 09:57:35 -0800 Subject: [Pythonmac-SIG] Problem with applets on MacPython In-Reply-To: <43C85B83.6020103@wordtech-software.com> References: <59a500c50601131243o78c60ea7rde911c47e750ffd4@mail.gmail.com> <0D0FF46E-0269-45C5-907F-3996FAF7D84C@redivi.com> <43C830BF.7000009@noaa.gov> <1DA4883E-5E1F-49CF-A796-E3DA250B02DA@fiee.net> <43C85B83.6020103@wordtech-software.com> Message-ID: <43CD300F.3090404@noaa.gov> Kevin Walzer wrote: > I used to maintain packages of SPE on OS X: it was a nicely-designed > application but very unstable. It crashed constantly. > > I've looked at the new version: it seems even more slick than before. > Not sure about how stable it is. Someone gave Stani a Mac, and I know he's been submitting bug reports for various wxPython stuff on the Mac, so I imagine it's much better. I need to go give it a try some day. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From Chris.Barker at noaa.gov Tue Jan 17 19:11:22 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 17 Jan 2006 10:11:22 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: <92424062-C956-47A7-8837-FFA0CAC13B8B@redivi.com> References: <92424062-C956-47A7-8837-FFA0CAC13B8B@redivi.com> Message-ID: <43CD334A.6050302@noaa.gov> Bob Ippolito wrote: > What do you want to happen, ideally? Clearly you don't want 30 CLI > apps with 30 full Python distributions. There are several > workarounds, but in order to make py2app serve your needs I'm going > to need to know what that is. I've thought about this, and I think the solutions proposed will probably work well for the OP. However, I'd like to have another option. I'd like to be able to install a complete Python distribution that has all the packages my apps need, all in one bundle. Then the individual scripts would use that, rather than the regular installed python. Perhaps you'd have a #! line like: /usr/bin/env MySpecialPython in each script. MySpecialPython would be installed somewhere on the path, and it would be a link or small script that started up a python installed in a bundle somewhere. That bundle would have all the packages installed that all my Scripts need. Currently, what I do is supply a bunch of *.mpkg files for all the packages I need, and my users (of which there are only a couple now anyway) just need to install them all. Not a big deal, but a single, customized "run time" that doesn't interfere in any way with the installed python would be pretty cool. It seems that the Py2App infrastructure could be useful for making such a beast. You'd need to add a way to give it multiple scripts to search for dependencies, then make the primary interpreter something that could be called just like regular python. Once we've got that, we'd also need a way to build "applets", or application bundles that would use the "run time", but would otherwise behave like an application bundle: point and click start-up, icons, etc. This sounds like a good idea to me, because I have a growing collection of small wxPython programs. Each one is pretty small, maybe a few hundred lines of code, but making a full Py2App bundle of each one results in a pretty darn set of bundles! Does anyone else think this would be useful? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From pecora at anvil.nrl.navy.mil Tue Jan 17 19:14:01 2006 From: pecora at anvil.nrl.navy.mil (Louis Pecora) Date: Tue, 17 Jan 2006 13:14:01 -0500 Subject: [Pythonmac-SIG] Newbie environment questions In-Reply-To: <43CD2F98.5050303@noaa.gov> References: <43CD2F98.5050303@noaa.gov> Message-ID: <43CD33E9.9090008@anvil.nrl.navy.mil> Ken, Chris gave some good advice there on reload and iPython. You can also run python from inside some code editors. I use BBEdit (a full featured code editor for $), but plenty of people use TextWrangler (free little brother of BBEdit). You edit the code, select run from a menu (I usually set cmd-R to do that) and you pop over to the Terminal with python and your module launched. Quite fast. You can close the Terminal window and jump right back to the editor to change things. I find it a nice way to develop in Python. -- Cheers, Lou Pecora Code 6362 Naval Research Lab Washington, DC 20375 USA Ph: +202-767-6002 email: pecora at anvil.nrl.navy.mil From bob at redivi.com Tue Jan 17 20:11:12 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 17 Jan 2006 11:11:12 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: <43CD334A.6050302@noaa.gov> References: <92424062-C956-47A7-8837-FFA0CAC13B8B@redivi.com> <43CD334A.6050302@noaa.gov> Message-ID: <07A7F477-1B50-43C1-BF49-9A014E5571CC@redivi.com> On Jan 17, 2006, at 10:11 AM, Christopher Barker wrote: > Bob Ippolito wrote: >> What do you want to happen, ideally? Clearly you don't want 30 >> CLI apps with 30 full Python distributions. There are several >> workarounds, but in order to make py2app serve your needs I'm >> going to need to know what that is. > > I've thought about this, and I think the solutions proposed will > probably work well for the OP. However, I'd like to have another > option. I'd like to be able to install a complete Python > distribution that has all the packages my apps need, all in one > bundle. Then the individual scripts would use that, rather than the > regular installed python. Perhaps you'd have a #! line like: > > /usr/bin/env MySpecialPython ... > Does anyone else think this would be useful? Not really... this would require an installer, so you might as well use a regular Python distro. There's no way I'm gonna implement it, but patches accepted if enough people want it. -bob From rowen at cesmail.net Tue Jan 17 22:13:36 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Tue, 17 Jan 2006 13:13:36 -0800 Subject: [Pythonmac-SIG] Building extensions on 10.4 that can be used on 10.3? Message-ID: Are there any tips or tricks to building 3rd party python extensions on MacOS X 10.4 in such a way that 10.3 users can use them? I maintain a cross-platform application written in Python. I really want my MacOS X bundle to run on both 10.3 and 10.4. So far the simplest way to do this is to just stay on 10.3, but that is getting less tenable over time. has most or all the extensions I need, but some of the ones I use are fairly outdated (especially numarray). So another option is to contribute modern versions built on 10.3 before I upgrade. But I'm not sure how practical that is; I only have 10.3/Python 2.3 (and a unix/X11 python 2.4.1), so probably I could only supply a useful build of the former, and only with instructions on how to create the package. Any help would be appreciated. -- Russell P.S. I realize that I can abandon 10.3 eventually, but probably not for many months, and presumably 10.5 will bring up the whole issue again. From Chris.Barker at noaa.gov Tue Jan 17 23:17:39 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 17 Jan 2006 14:17:39 -0800 Subject: [Pythonmac-SIG] Building extensions on 10.4 that can be used on 10.3? In-Reply-To: References: Message-ID: <43CD6D03.7090505@noaa.gov> Russell E. Owen wrote: > Are there any tips or tricks to building 3rd party python extensions on > MacOS X 10.4 in such a way that 10.3 users can use them? It can be done, but I think it's PITA > has most or all the extensions I need, > but some of the ones I use are fairly outdated (especially numarray). So > another option is to contribute modern versions built on 10.3 before I > upgrade. But I'm not sure how practical that is; I only have 10.3/Python > 2.3 Installing 2.4.1 from undefined.org/python is pretty trivial. In fact, using the 2.4.1 Framework build for OS-X 10.3, and installing it on both 10.3 and 10.4 might well do what you want. I know the 10.3 stuff will all run on 10.4, it's just a question of what C libs get linked if you build on 10.4, using the 10.3 Python. I suspect that if you use distutils, it might all work, but if you build everything on 10.3, you're all set. > with instructions on how to create > the package. This is very easy for anything that builds with distutils. Py2App comes with bdist_mpkg, which will build a *.mpkg from setup.py. The only tricky part is external libs. For instance, for matplotlib, I need to make sure it statically linked libpng and libfreetype, so that the package would run on a stock OS-X. It would be great if you contributed some upgraded packages to pythonmac. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From dshahbaz at fcoe.k12.ca.us Wed Jan 18 02:01:39 2006 From: dshahbaz at fcoe.k12.ca.us (Dimi Shahbaz) Date: Tue, 17 Jan 2006 17:01:39 -0800 Subject: [Pythonmac-SIG] Resource forks and HFS-metadata Message-ID: Hi, My program deals with zip transferring archives. I'm curious as to whether Python (namely the 'zip' and 'zipfile') modules can be made to be aware of resource forks and HFS-metadata? Or is this a limitation of the zip format itself? According to this (old) hint: http://www.macosxhints.com/article.php?story=20031118111144197 I will have to have my program interact with `cpio` to preserve the metadata, which I'm trying to avoid. Thanks From bob at redivi.com Wed Jan 18 03:24:45 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 17 Jan 2006 18:24:45 -0800 Subject: [Pythonmac-SIG] Resource forks and HFS-metadata In-Reply-To: References: Message-ID: On Jan 17, 2006, at 5:01 PM, Dimi Shahbaz wrote: > My program deals with zip transferring archives. I'm curious as to > whether Python (namely the 'zip' and 'zipfile') modules can be made > to be aware of resource forks and HFS-metadata? Or is this a > limitation of the zip format itself? According to this (old) hint: > > http://www.macosxhints.com/article.php?story=20031118111144197 > > I will have to have my program interact with `cpio` to preserve the > metadata, which I'm trying to avoid. You could certainly write code on top of the zipfile module that understands HFS metadata, since you have access to the zip directory and such. However, I'm not sure that the way that Apple decided to extend the format is documented anywhere. You'd have to look at the Darwin diffs for zip and unzip to see. On Mac OS X 10.4, you could just run zip/unzip in a subprocess and they'd do the right thing. -bob From chrisporter at wi.rr.com Mon Jan 16 17:44:08 2006 From: chrisporter at wi.rr.com (Chris Porter) Date: Mon, 16 Jan 2006 10:44:08 -0600 Subject: [Pythonmac-SIG] MySQLdb lib help Message-ID: Hello, complete python newbie here. I've got: OSX 10.4.3 Python 2.3.5 MySQL 4.1.15-standard (of course, all pre-installed, except for MySQL) I don't seem to have the right python module that will allow python to interact with my MySQL databases. I am completely not a programmer, but I can follow a cookbook-type instruction set in Terminal, and have already set up several MySQL databases and php on my personal intranet. Now I want to run a python program (by someone else, of course) that also interacts with my MySQL databases. I've run the test query that searches for the MySQLdb python module, and found I don't have it, so I need to install it. So, I found this list. Looked for the past year for information about this issue: Bob said in June: "You can download a MySQL-python 1.2 installer from: http://pythonmac.org/packages/" So I did. And installed it (though it's for 10.3) and ran the test I found on the web in Terminal: >>> import MySQLdb Traceback (most recent call last): File "", line 1, in ? ImportError: No module named MySQLdb >>> Would someone be kind enough to help me out, please? I'm sort of betting the package installed the lib into the wrong place. Is that possible? -- Chris Porter Illustration chrisporter at wi.rr.com, chrisporter at huntingthesnark.com http://chrisporter.huntingthesnark.com phone/fax: 262.843.3697 From david.warde.farley at utoronto.ca Wed Jan 18 09:31:34 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Wed, 18 Jan 2006 03:31:34 -0500 Subject: [Pythonmac-SIG] MySQLdb lib help In-Reply-To: References: Message-ID: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> On 16-Jan-06, at 11:44 AM, Chris Porter wrote: > Hello, complete python newbie here. > > I've got: > > OSX 10.4.3 > Python 2.3.5 > MySQL 4.1.15-standard > (of course, all pre-installed, except for MySQL) > > I don't seem to have the right python module that will allow python > to interact with my MySQL > databases. > The MySQLdb module doesn't come standard. And seeing as how I can't get it to build properly with Apple's Python (and Apple's Python is kind of icky anyway), here's the rundown: Firstly, you'll probably want to install Python 2.4 from http:// undefined.org/python/, and the Tiger fix. You'll want to modify your shell's PATH variable so that /usr/local/bin comes before /usr/bin. If you use bash (other people: is this the default in OS X? I honestly can't remember), this should be as simple as adding the line export PATH=/usr/local/bin:$PATH to the end of .bash_profile in your user directory. Finally, grab the zip file for the MySQLdb module from pythonmac.org/ packages and install it that way. Now run python at the command prompt (make sure to start a new terminal window after changing .bash_profile ), make sure it's Python 2.4.1 you're running, and try importing again. Hope that helps, - Dave From niko at alum.mit.edu Wed Jan 18 10:24:10 2006 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 18 Jan 2006 10:24:10 +0100 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes In-Reply-To: <615F8B88-8135-44AB-B2BE-B5A2C478C5B3@alum.mit.edu> References: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> <19A5379F-EBFC-4A1F-824D-06560A216538@alum.mit.edu> <615F8B88-8135-44AB-B2BE-B5A2C478C5B3@alum.mit.edu> Message-ID: <6A36B749-2376-4DA0-81DE-11CD367BB58E@alum.mit.edu> > Well, I'll benchmark the two approaches against my full library and > report back on the results :). The question is whether having more > AppleEvents will be slower than selecting way too much data. > Neither is stupendously fast; the bottleneck is definitely issuing the individual delete commands for each track. Both took around 30 minutes to execute. It seems to take around one second for a delete command to take effect, judged solely on watching the total track count decrease one by one. Anyhow, while not great, it's fast enough for me. Thanks for all the help. Actually, I have one final question: is it possible for handles to "time out?" I remember seeing such an error once in my life in an earlier time playing with appscript, but the version of the script at that time was so inefficient . Given that I have times as long as 30-45 minutes from .get()ting the handle to calling .remove() on it, it seems possible I might elapse some kind of sanity check timers. Niko From hengist.podd at virgin.net Wed Jan 18 16:03:20 2006 From: hengist.podd at virgin.net (has) Date: Wed, 18 Jan 2006 15:03:20 +0000 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes In-Reply-To: <6A36B749-2376-4DA0-81DE-11CD367BB58E@alum.mit.edu> References: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> <19A5379F-EBFC-4A1F-824D-06560A216538@alum.mit.edu> <615F8B88-8135-44AB-B2BE-B5A2C478C5B3@alum.mit.edu> <6A36B749-2376-4DA0-81DE-11CD367BB58E@alum.mit.edu> Message-ID: Niko Matsakis wrote: >>Well, I'll benchmark the two approaches against my full library and >>report back on the results :). The question is whether having more >>AppleEvents will be slower than selecting way too much data. >> > >Neither is stupendously fast; the bottleneck is definitely issuing the individual delete commands for each track. Both took around 30 minutes to execute. It seems to take around one second for a delete command to take effect, judged solely on watching the total track count decrease one by one. Still sounds very slow. What OS & iTunes versions; how big's the playlist and what % is duplicates? I mocked up a 550-item playlist containing 500 duplicates and my script took 50 secs to get through that (iTunes 6.0.1; OS 10.4.3); 10 secs if I close the playlist window first so iTunes doesn't have to update that each time. >Actually, I have one final question: is it possible for handles to "time out?" What you mean by 'handles'? If you mean application object references, remember those are just queries, so they're only as durable as they are unique. A by-id specifier should always identify the same object for as long as that object exists; a by-index specifier will identify whatever object happens to be at the specified position at the time, which may well be different objects at different times if you're moving them around and stuff. Individual Apple events can time out if the application takes too long to handle them; e.g. try getting the 'entire contents' a large chunk of your filesystem in Finder, and, assuming Finder doesn't just collapse in a heap from the strain of it, chances are the Finder won't have completed the operation and sent its reply before the default 60 second timeout expires, in which case AEM sends a timeout error back to your script. (You can adjust the timeout delay if you need to; see ch.10 of the appscript manual.) has -- http://freespace.virgin.net/hamish.sanderson/ From niko at alum.mit.edu Wed Jan 18 16:20:21 2006 From: niko at alum.mit.edu (Niko Matsakis) Date: Wed, 18 Jan 2006 16:20:21 +0100 Subject: [Pythonmac-SIG] appscript: selecting many songs in iTunes In-Reply-To: References: <6F949AC3-6D68-4EA0-B074-1F9F90B6F917@alum.mit.edu> <19A5379F-EBFC-4A1F-824D-06560A216538@alum.mit.edu> <615F8B88-8135-44AB-B2BE-B5A2C478C5B3@alum.mit.edu> <6A36B749-2376-4DA0-81DE-11CD367BB58E@alum.mit.edu> Message-ID: > Still sounds very slow. What OS & iTunes versions; how big's the > playlist and what % is duplicates? I mocked up a 550-item playlist > containing 500 duplicates and my script took 50 secs to get through > that (iTunes 6.0.1; OS 10.4.3); 10 secs if I close the playlist > window first so iTunes doesn't have to update that each time. It's not a playlist, the script is running across the entire iTunes library of many gigabytes. > What you mean by 'handles'? I meant what you get when you do something like app('iTunes').library ['playlist'].tracks.filter (its.database_ID=someid).get(). Sorry for my inaccurate terminology. I suspect what I saw was an individual apple event timing out. Niko From hraban at fiee.net Wed Jan 18 16:52:11 2006 From: hraban at fiee.net (Henning Hraban Ramm) Date: Wed, 18 Jan 2006 16:52:11 +0100 Subject: [Pythonmac-SIG] Resource forks and HFS-metadata In-Reply-To: References: Message-ID: <2A990AA1-1B7E-463B-BCEF-EEC06B40258B@fiee.net> Am 2006-01-18 um 02:01 schrieb Dimi Shahbaz: > My program deals with zip transferring archives. I'm curious as to > whether Python (namely the 'zip' and 'zipfile') modules can be made > to be aware of resource forks and HFS-metadata? Or is this a > limitation of the zip format itself? According to this (old) hint: I experienced that the zipfile module doesn't work at all (at least in Python 2.3); the files were often broken (i.e. no other zip program could open them), and it couldn't handle a lot of zip files by other apps. AFAIK the only *known* limitation is with really huge files, though. Thus I always use an external app for archive handling, even if I don't like that approach. Gr??lis vom Hraban! --- http://www.fiee.net/texnique/ http://contextgarden.net http://www.cacert.org (I'm an assurer) From rroberts at adobe.com Wed Jan 18 17:35:50 2006 From: rroberts at adobe.com (Read Roberts) Date: Wed, 18 Jan 2006 08:35:50 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: <07A7F477-1B50-43C1-BF49-9A014E5571CC@redivi.com> Message-ID: One good reason for a stand-alone Python is when the distribution contains third=-party extension modules, which are of necessity bound to a particular version of Python, and the interval between updates is likely to be several years. However, the need can be met with a py2app program which just assumes the first command-line argument is a Python script file and executes it, much as does the _boot_.py script inside the py2app-generated bundle app. py2app does allow you to include all the modules you could ever need. The only extension that might be useful would be a py2app switch which says "include every module possible". I have so far found only two issues to work around in the scenario above: - the command-line program at .app/Conyents/MacOS/ cannot be accessed via a symbolic link; to make it accessible to the user, you must provide a shell script which invokes it by an absolute path. - when your Python file is executed, the current working directory has been changed to .app/Conyents/Resource. This happens before _boot_.py is called. Fortunately, the Unix environment variable PWD still holds the original current working directory, so adding os.chdir(os.environ["PWD"]) to your py2app'd script restores this bit of lost context. Apart from these two issues, my "pythonFDK" works as expected, which is great. On the separate issue of distributing many py2app'd Python programs, It has also occurred to me than frameworks can be accessed via symbolic link, so you can avoid the file-size overhead of a a Python distribution for each app just by building one of the apps with the modules necessary for any app, and in all the other apps, replacing the .app/Conyents/Resource/Python/pythonframework directory with a symbolic link to the matching directory in the first app. Of course, all the apps must then stay in a fixed relative position within a directory tree, but this is a common requirement. - Read Roberts On 1/17/06 11:11 AM, "Bob Ippolito" wrote: > > On Jan 17, 2006, at 10:11 AM, Christopher Barker wrote: > >> Bob Ippolito wrote: >>> What do you want to happen, ideally? Clearly you don't want 30 >>> CLI apps with 30 full Python distributions. There are several >>> workarounds, but in order to make py2app serve your needs I'm >>> going to need to know what that is. >> >> I've thought about this, and I think the solutions proposed will >> probably work well for the OP. However, I'd like to have another >> option. I'd like to be able to install a complete Python >> distribution that has all the packages my apps need, all in one >> bundle. Then the individual scripts would use that, rather than the >> regular installed python. Perhaps you'd have a #! line like: >> >> /usr/bin/env MySpecialPython > ... >> Does anyone else think this would be useful? > > Not really... this would require an installer, so you might as well > use a regular Python distro. There's no way I'm gonna implement it, > but patches accepted if enough people want it. > > -bob > > Read Roberts Adobe SJ on Weds, home office 415-642-5642 other days From charles at nemetschek.net Wed Jan 18 17:40:06 2006 From: charles at nemetschek.net (Charles Chandler) Date: Wed, 18 Jan 2006 11:40:06 -0500 Subject: [Pythonmac-SIG] Resource forks and HFS-metadata In-Reply-To: <2A990AA1-1B7E-463B-BCEF-EEC06B40258B@fiee.net> Message-ID: <046601c61c4d$d6fcd070$dc01a8c0@nemetschek.net> I use ditto to create zips... openObj = popen2.Popen4('ditto -c -k --keepParent -sequesterRsrc ' + sourceFolderName + ' ' + targetZipName) ...then the zipfile method to unzip the files... data = theZipFile.read(relPathAndFileName) outfile = open(fullTargetName, "wb") outfile.write(data) outfile.close() ...then a Mac BSD call to rebuild the data and resource forks... popen2.popen2("/System/Library/CoreServices/FixupResourceForks \"" + destination + "\"") ...assuming that the developer tools are installed. Charles > -----Original Message----- > From: pythonmac-sig-bounces+charles=nemetschek.net at python.org > [mailto:pythonmac-sig-bounces+charles=nemetschek.net at python.org] On Behalf > Of Henning Hraban Ramm > Sent: Wednesday, January 18, 2006 10:52 > To: pythonmac-sig at python.org > Subject: Re: [Pythonmac-SIG] Resource forks and HFS-metadata > > Am 2006-01-18 um 02:01 schrieb Dimi Shahbaz: > > > My program deals with zip transferring archives. I'm curious as to > > whether Python (namely the 'zip' and 'zipfile') modules can be made > > to be aware of resource forks and HFS-metadata? Or is this a > > limitation of the zip format itself? According to this (old) hint: > > I experienced that the zipfile module doesn't work at all (at least > in Python 2.3); the files were often broken (i.e. no other zip > program could open them), and it couldn't handle a lot of zip files > by other apps. > AFAIK the only *known* limitation is with really huge files, though. > > Thus I always use an external app for archive handling, even if I > don't like that approach. > > Gr??lis vom Hraban! > --- > http://www.fiee.net/texnique/ > http://contextgarden.net > http://www.cacert.org (I'm an assurer) > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Wed Jan 18 18:35:28 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 18 Jan 2006 09:35:28 -0800 Subject: [Pythonmac-SIG] Building multiple command-line( ( CLI ) programs with py2app In-Reply-To: <07A7F477-1B50-43C1-BF49-9A014E5571CC@redivi.com> References: <92424062-C956-47A7-8837-FFA0CAC13B8B@redivi.com> <43CD334A.6050302@noaa.gov> <07A7F477-1B50-43C1-BF49-9A014E5571CC@redivi.com> Message-ID: <43CE7C60.2090402@noaa.gov> Bob Ippolito wrote: >>I'd like to be able to install a complete Python >>distribution that has all the packages my apps need, all in one >>bundle. >>Does anyone else think this would be useful? > > Not really... this would require an installer, so you might as well > use a regular Python distro. I don't follow. All you'd need is a *.mpkg of the "runtime", and then one for each applet. Or you could put them all in one. One of the issues with a regular python distro is that the user could be using that distro for something else. If they are doing that they may well need/install different versions of various libraries, upgrade it, whatever, and my applets could break. What I'd like is for my stuff to depend only on a Python distro that I have control over. I thought maybe Py2App would be an easy way to build such a thing. I suppose I could create a python distro in: /Library/Frameworks/MySpecialPythonFramework and put what I need into that. How hard would that be? Could I just make a copy of the regular one and go from there, or is that path hard coded all over the place? The other thing I need to learn is how to put a bunch of *.mpkgs together into one meta-mpkg, so that I can install a bunch of stuff with one click. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From rowen at cesmail.net Wed Jan 18 20:25:35 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Wed, 18 Jan 2006 11:25:35 -0800 Subject: [Pythonmac-SIG] MySQLdb lib help References: Message-ID: In article , Chris Porter wrote: > Hello, complete python newbie here. > > I've got: > > OSX 10.4.3 > Python 2.3.5 > MySQL 4.1.15-standard > (of course, all pre-installed, except for MySQL) > > I don't seem to have the right python module that will allow python to > interact with my MySQL > databases. > > I am completely not a programmer, but I can follow a cookbook-type > instruction set in Terminal, and > have already set up several MySQL databases and php on my personal intranet. > Now I want to run a > python program (by someone else, of course) that also interacts with my MySQL > databases. I've run > the test query that searches for the MySQLdb python module, and found I don't > have it, so I need to > install it. So, I found this list. Looked for the past year for information > about this issue: > > Bob said in June: > "You can download a MySQL-python 1.2 installer from: > http://pythonmac.org/packages/" > > So I did. And installed it (though it's for 10.3) and ran the > test I found on the web in Terminal: The 10.3 version of that package should work fine on your system (that's why it says "10.3+"). Do make sure you got the version for python 2.3, not 2.4, since you're using the preinstalled python. I'm not sure why it might have failed. Some things to try: - make sure you only have one python because if you have more MySQLdb might have installed on the "wrong" python. - Try installing it from source. It is trivial and it works for me (on MacOS X 10.3.9 and its built-in python). It includes instructions, but it uses the standard distutils dance: - download source - unpack source - use Terminal to "cd" into the unpacked source % python setup.py build % sudo python setup.py install Good luck. -- Russell From rowen at cesmail.net Wed Jan 18 20:28:15 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Wed, 18 Jan 2006 11:28:15 -0800 Subject: [Pythonmac-SIG] MySQLdb lib help References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> Message-ID: In article <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B at utoronto.ca>, David Warde-Farley wrote: >... > The MySQLdb module doesn't come standard. And seeing as how I can't > get it to build properly with Apple's Python (and Apple's Python is > kind of icky anyway), here's the rundown: > > Firstly, you'll probably want to install Python 2.4 from http:// > undefined.org/python/, and the Tiger fix.... Could you expand on "Apple's Python is kind of icky anyway"? The python 2.3 that came with MacOS X 10.3 works fine for me (including with 3rd party libraries); did it go downhill on 10.4? I don't mean to argue, I'm just curious. Python 2.4 has some nifty enhancements (though if you're going to share your code widely you might want to wait to use them until 2.4 becomes better established). -- Russell From bob at redivi.com Wed Jan 18 20:45:35 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 18 Jan 2006 11:45:35 -0800 Subject: [Pythonmac-SIG] MySQLdb lib help In-Reply-To: References: Message-ID: <6669F2F3-3BD4-4E0E-B672-D9F6797E5DDF@redivi.com> On Jan 18, 2006, at 11:25 AM, Russell E. Owen wrote: > In article > , > Chris Porter wrote: > >> Hello, complete python newbie here. >> >> I've got: >> >> OSX 10.4.3 >> Python 2.3.5 >> MySQL 4.1.15-standard >> (of course, all pre-installed, except for MySQL) >> >> I don't seem to have the right python module that will allow >> python to >> interact with my MySQL >> databases. >> >> I am completely not a programmer, but I can follow a cookbook-type >> instruction set in Terminal, and >> have already set up several MySQL databases and php on my personal >> intranet. >> Now I want to run a >> python program (by someone else, of course) that also interacts >> with my MySQL >> databases. I've run >> the test query that searches for the MySQLdb python module, and >> found I don't >> have it, so I need to >> install it. So, I found this list. Looked for the past year for >> information >> about this issue: >> >> Bob said in June: >> "You can download a MySQL-python 1.2 installer from: >> http://pythonmac.org/packages/" >> >> So I did. And installed it (though it's for 10.3) and ran the >> test I found on the web in Terminal: > > The 10.3 version of that package should work fine on your system > (that's > why it says "10.3+"). Do make sure you got the version for python 2.3, > not 2.4, since you're using the preinstalled python. > > I'm not sure why it might have failed. Some things to try: I'm exactly sure why it failed. Just like the other day, you must install the TigerPython23Compat before any of those 10.3 packages will be importable by the Python 2.3 on Mac OS X 10.4. All TigerPython23Compat does is add a pth file to /Library/Python/2.3/ site-packages that points to /Library/Python/2.3 -bob From bob at redivi.com Wed Jan 18 20:55:32 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 18 Jan 2006 11:55:32 -0800 Subject: [Pythonmac-SIG] MySQLdb lib help In-Reply-To: References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> Message-ID: On Jan 18, 2006, at 11:28 AM, Russell E. Owen wrote: > In article <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B at utoronto.ca>, > David Warde-Farley wrote: > >> ... >> The MySQLdb module doesn't come standard. And seeing as how I can't >> get it to build properly with Apple's Python (and Apple's Python is >> kind of icky anyway), here's the rundown: >> >> Firstly, you'll probably want to install Python 2.4 from http:// >> undefined.org/python/, and the Tiger fix.... > > Could you expand on "Apple's Python is kind of icky anyway"? The > python 2.3 that came with MacOS X 10.3 works fine for me (including > with > 3rd party libraries); did it go downhill on 10.4? It's fine, unless you want to create redistributable applications. If you build an app with a vendor Python, it will only reliably work on that version of the OS. Future versions of Mac OS X will absolutely throw away Python 2.3 for Python 2.4 (or 2.5, depending on when that happens) and none of your applications will still work. Other than the benefits of a non-vendor installation, Python 2.4 is better in every way. Faster, more features, less bugs, more popular amongst developers (which means more stability in third party code), etc. Python 2.4 is certainly established enough to use, especially on Mac OS X and Windows. -bob From ronaldoussoren at mac.com Wed Jan 18 21:39:06 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 18 Jan 2006 21:39:06 +0100 Subject: [Pythonmac-SIG] Building extensions on 10.4 that can be used on 10.3? In-Reply-To: References: Message-ID: <036D9BBA-4E3F-4E25-BF5F-420674F1994F@mac.com> On 17-jan-2006, at 22:13, Russell E. Owen wrote: > Are there any tips or tricks to building 3rd party python > extensions on > MacOS X 10.4 in such a way that 10.3 users can use them? Building them on 10.3 is the easiest way to get 10.3 compatible extensions. You'll have to test them on 10.3 anyway, so you may as wel build them there. In theory extension you build on 10.4 will work on 10.3 if you use weak-linking for symbols that don't exist on 10.3 (or just don't use 10.4 specific API's). BTW. You don't have to stay on 10.3, you just have to build all extensions there. You can do all your development in 10.4, py2app will build a 10.3 compatible app bundle on 10.4 if all extensions and Python itself were build on 10.3. Ronald From dshahbaz at fcoe.k12.ca.us Wed Jan 18 22:03:00 2006 From: dshahbaz at fcoe.k12.ca.us (Dimi Shahbaz) Date: Wed, 18 Jan 2006 13:03:00 -0800 Subject: [Pythonmac-SIG] Resource forks and HFS-metadata In-Reply-To: <046601c61c4d$d6fcd070$dc01a8c0@nemetschek.net> References: <046601c61c4d$d6fcd070$dc01a8c0@nemetschek.net> Message-ID: <671231AB-E366-45B8-8670-492479713831@fcoe.k12.ca.us> Yes, I think I'm going to have to do this. One question though, since you are using an external process to fix the metadata anyway, why not just use ditto again to unzip, so you could avoid the extra unzip step? -Dimi On Jan 18, 2006, at 8:40 AM, Charles Chandler wrote: > I use ditto to create zips... > > openObj = popen2.Popen4('ditto -c -k --keepParent -sequesterRsrc ' + > sourceFolderName + ' ' + targetZipName) > > ...then the zipfile method to unzip the files... > > data = theZipFile.read(relPathAndFileName) > outfile = open(fullTargetName, "wb") > outfile.write(data) > outfile.close() > > ...then a Mac BSD call to rebuild the data and resource forks... > > popen2.popen2("/System/Library/CoreServices/FixupResourceForks \"" + > destination + "\"") > > ...assuming that the developer tools are installed. > > Charles From bob at redivi.com Wed Jan 18 23:21:28 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 18 Jan 2006 14:21:28 -0800 Subject: [Pythonmac-SIG] Resource forks and HFS-metadata In-Reply-To: <671231AB-E366-45B8-8670-492479713831@fcoe.k12.ca.us> References: <046601c61c4d$d6fcd070$dc01a8c0@nemetschek.net> <671231AB-E366-45B8-8670-492479713831@fcoe.k12.ca.us> Message-ID: <4248800C-F1B6-49B8-8A40-A01BFCBF6C63@redivi.com> The popen call in the below example is bad -- don't use that, it will totally explode if either path has spaces in it. You want to use the subprocess module instead. It comes with Python 2.4, but you can just copy subprocess.py over if you're using Python 2.3. The subprocess module avoids quoting altogether by taking a list for arguments and passing it directly to execve after the fork. The second example does try to quote, but it doesn't do it correctly. Quotes are valid in paths, so the second snippet would explode if the path had a quote in it (unlikely.. but possible). I would also recommend against using FixupResourceForks if it requires dev tools to be installed. -bob On Jan 18, 2006, at 1:03 PM, Dimi Shahbaz wrote: > Yes, I think I'm going to have to do this. > > One question though, since you are using an external process to fix > the metadata anyway, why not just use ditto again to unzip, so you > could avoid the extra unzip step? > > -Dimi > > > On Jan 18, 2006, at 8:40 AM, Charles Chandler wrote: > >> I use ditto to create zips... >> >> openObj = popen2.Popen4('ditto -c -k --keepParent -sequesterRsrc ' + >> sourceFolderName + ' ' + targetZipName) >> >> ...then the zipfile method to unzip the files... >> >> data = theZipFile.read(relPathAndFileName) >> outfile = open(fullTargetName, "wb") >> outfile.write(data) >> outfile.close() >> >> ...then a Mac BSD call to rebuild the data and resource forks... >> >> popen2.popen2("/System/Library/CoreServices/FixupResourceForks \"" + >> destination + "\"") >> >> ...assuming that the developer tools are installed. >> >> Charles > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From david.warde.farley at utoronto.ca Thu Jan 19 06:10:43 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Thu, 19 Jan 2006 00:10:43 -0500 Subject: [Pythonmac-SIG] MySQLdb lib help In-Reply-To: References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> Message-ID: <8956913E-FE81-49C3-B9AB-8378E39BE21E@utoronto.ca> On 18-Jan-06, at 2:55 PM, Bob Ippolito wrote: > It's fine, unless you want to create redistributable applications. > If you build an app with a vendor Python, it will only reliably work > on that version of the OS. Future versions of Mac OS X will > absolutely throw away Python 2.3 for Python 2.4 (or 2.5, depending on > when that happens) and none of your applications will still work. (bah, sorry Bob, I always just hit reply) Exactly what Bob said. Other than that, Apple's Python build wasn't linked against GNU readline and thus is not very nice to use on the interpreter command prompt (try the arrow keys with /usr/bin/python; I find it's a real pain not being able to at least up-arrow to repeat previous commands a la bash/DOSkey/etc.). - Dave From bob at redivi.com Thu Jan 19 06:26:15 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 18 Jan 2006 21:26:15 -0800 Subject: [Pythonmac-SIG] MySQLdb lib help In-Reply-To: <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> Message-ID: <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> On Jan 18, 2006, at 9:10 PM, David Warde-Farley wrote: > > On 18-Jan-06, at 2:55 PM, Bob Ippolito wrote: > >> It's fine, unless you want to create redistributable applications. >> If you build an app with a vendor Python, it will only reliably work >> on that version of the OS. Future versions of Mac OS X will >> absolutely throw away Python 2.3 for Python 2.4 (or 2.5, depending on >> when that happens) and none of your applications will still work. > > Exactly what Bob said. Other than that, Apple's Python build wasn't > linked against GNU readline and thus is not very nice to use on the > interpreter command prompt (try the arrow keys with /usr/bin/ > python; I find it's a real pain not being able to at least up-arrow > to repeat previous commands a la bash/DOSkey/etc.). Dave forgot to CC the list... but if you want readline support for Apple Python 2.3 you can download the package from http:// pythonmac.org/packages/ and there are eggs up on Cheese Shop for use with easy_install. Note also that ActiveState's Python 2.4.2 also ships sans-readline due to license (same reason as Apple). I don't have a package for that, but there is an egg. -bob From whamoo at rknet.it Thu Jan 19 18:40:10 2006 From: whamoo at rknet.it (whamoo) Date: Thu, 19 Jan 2006 18:40:10 +0100 Subject: [Pythonmac-SIG] AutoUpdate application? Message-ID: <8AE027CA-C250-452A-ACCB-108515160FF6@rknet.it> Hi all, I've written some pyobjc application bundled with py2app, and i'm wondering what is the best way for doing the self update of the application.... I will explain, after the application check that a new version is available and have downloaded it, how to delete the older one that is running and replace with the new one? The only idea i have is to use a second script in the bundle, launched independently of the app when the update is needed, it is a suitable method? I think it can be done better but i don't know how ;-) Any idea will be appreciated. Thanks all Bye Matteo Rattotti www.rknet.it Powered by: - MacOsX - Gnu / Linux Debian Sarge - Amiga Os 3.9 - Milk -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060119/2d84beae/attachment.htm From Chris.Barker at noaa.gov Thu Jan 19 19:44:16 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 19 Jan 2006 10:44:16 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> Message-ID: <43CFDE00.7030607@noaa.gov> Bob Ippolito wrote: There are eggs up on Cheese Shop for use with easy_install. This brings up a question. I think it's a really good idea if we can decide, as a community, what the canonical way is to distribute packages to the MacPython world. Currently, I think putting a *.mpkg on pythonmac.org is that way. Should we keep doing that? or is it time to switch to putting eggs in the cheese shop ? or eggs on python mac? thoughts? By the way we really do need to update and improve the pythonmac web page. I hope to get to it soon, but if someone beats me to it, that would be great! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From ronaldoussoren at mac.com Thu Jan 19 20:28:52 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 19 Jan 2006 20:28:52 +0100 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43CFDE00.7030607@noaa.gov> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> Message-ID: On 19-jan-2006, at 19:44, Christopher Barker wrote: > Bob Ippolito wrote: > There are eggs up on Cheese Shop for use with easy_install. > > This brings up a question. I think it's a really good idea if we can > decide, as a community, what the canonical way is to distribute > packages > to the MacPython world. > > Currently, I think putting a *.mpkg on pythonmac.org is that way. > Should > we keep doing that? or is it time to switch to putting eggs in the > cheese shop ? or eggs on python mac? > > thoughts? IMHO both eggs and mpkg's have their place: eggs are great for automaticly downloading dependencies, mpkgs are better when you also want to install other stuff, such as examples or documentation, as well. IIRC Bob is leaning towards teaching bdist_mpkg to include, and install, eggs instead of "naked" packages. The actual location of packages is not very important, as long as there is an easy way to get to them (such as an index on pythonmac.org). Ronald From bob at redivi.com Thu Jan 19 21:10:28 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 19 Jan 2006 12:10:28 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> Message-ID: On Jan 19, 2006, at 11:28 AM, Ronald Oussoren wrote: > > On 19-jan-2006, at 19:44, Christopher Barker wrote: > >> Bob Ippolito wrote: >> There are eggs up on Cheese Shop for use with easy_install. >> >> This brings up a question. I think it's a really good idea if we can >> decide, as a community, what the canonical way is to distribute >> packages >> to the MacPython world. >> >> Currently, I think putting a *.mpkg on pythonmac.org is that way. >> Should >> we keep doing that? or is it time to switch to putting eggs in the >> cheese shop ? or eggs on python mac? >> >> thoughts? > > IMHO both eggs and mpkg's have their place: eggs are great for > automaticly downloading dependencies, mpkgs are better when you also > want to install other stuff, such as examples or documentation, as > well. IIRC Bob is leaning towards teaching bdist_mpkg to include, and > install, eggs instead of "naked" packages. > > The actual location of packages is not very important, as long as > there is an easy way to get to them (such as an index on > pythonmac.org). I'd like to see eggs used for everything that can be distributed as an egg... but as Ronald says, mpkgs still have their place for packages that need to install Other Stuff, and as a transitional means. py2app doesn't support eggs yet, so that's why I haven't said much about eggs here. There's no good reason to prefer eggs on pythonmac.org. setuptools has built-in support for uploading source packages and eggs to Cheese Shop. If the package is already registered by someone else on Cheese Shop, just track them down and ask them to add your user as a maintainer role, which should allow you to upload eggs. -bob From Chris.Barker at noaa.gov Fri Jan 20 02:02:27 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 19 Jan 2006 17:02:27 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> Message-ID: <43D036A3.7000107@noaa.gov> Bob Ippolito wrote: > I'd like to see eggs used for everything that can be distributed as an > egg... but as Ronald says, mpkgs still have their place for packages > that need to install Other Stuff, and as a transitional means. Can you put an egg in a mpkg? > There's no good reason to prefer eggs on pythonmac.org. I don't quite follow. Are you suggesting that we don't put any eggs on pythonmac? If so, then we do put non-egg packages there? I am concerned that that will just confuse the users more. I'd really like to be able to tell people: go to this place, and all available packages for Python on OS-X are there. > setuptools has > built-in support for uploading source packages and eggs to Cheese > Shop. If the package is already registered by someone else on Cheese > Shop, just track them down and ask them to add your user as a > maintainer role, which should allow you to upload eggs. yes, that does look pretty cool. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Fri Jan 20 03:04:41 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 19 Jan 2006 18:04:41 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D036A3.7000107@noaa.gov> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> Message-ID: <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> On Jan 19, 2006, at 5:02 PM, Christopher Barker wrote: > Bob Ippolito wrote: > >> I'd like to see eggs used for everything that can be distributed >> as an >> egg... but as Ronald says, mpkgs still have their place for packages >> that need to install Other Stuff, and as a transitional means. > > Can you put an egg in a mpkg? Not yet. >> There's no good reason to prefer eggs on pythonmac.org. > > I don't quite follow. Are you suggesting that we don't put any eggs on > pythonmac? If so, then we do put non-egg packages there? I am > concerned > that that will just confuse the users more. I'd really like to be able > to tell people: go to this place, and all available packages for > Python > on OS-X are there. We could mine Cheese Shop and list the pure python packages, the packages that have Mac OS X eggs, and the mpkgs. -bob From replies-06-020 at moax.net Fri Jan 20 08:20:02 2006 From: replies-06-020 at moax.net (Mathew James Oakes) Date: Fri, 20 Jan 2006 18:20:02 +1100 Subject: [Pythonmac-SIG] py2app and tkinter Message-ID: <9a36fafc2b64775635c69d83367d632a@moax.net> py2app documentation says it is compatible with Tk... I happily build apps with pygame dependency. scripts run fine from command line. Tk interfaces just 'unexpectedly quit' when launched every time in app form... anyone got any tips for this??? osx 10.3.9, tcl/tk 8.4, python 2.3 produces the following crash log... ********** Host Name: xxxx.local Date/Time: 2005-12-09 14:16:45 +1030 OS Version: 10.3.9 (Build 7W98) Report Version: 2 Command: search_index_gui_app Path: /Users/matoakes/Documents/Archive Index System/dist/search_index_gui_app.app/Contents/MacOS/ search_index_gui_app Version: 0.0.0 (0.0.0) PID: 24420 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0 Crashed: 0 <<00000000>> 0x00000000 0 + 0 1 com.tcltk.tklibrary 0x0b05109c TkRegisterObjTypes + 0x24 2 com.tcltk.tklibrary 0x0b07451c Tk_SafeInit + 0x4c 3 _tkinter.so 0x0044a670 Tcl_AppInit + 0x2c 4 _tkinter.so 0x0044912c init_tkinter + 0x3894 5 _tkinter.so 0x00448bf0 init_tkinter + 0x3358 6 org.python.Python.framework 0x95fa94a8 PyEval_GetFuncDesc + 0x1dc 7 org.python.Python.framework 0x95fa6c64 PyEval_EvalCode + 0x2560 8 org.python.Python.framework 0x95fa7e30 PyEval_EvalCodeEx + 0x850 9 org.python.Python.framework 0x95f5f354 PyFunction_SetClosure + 0xd6c 10 org.python.Python.framework 0x95f4a8d0 PyObject_Call + 0x30 11 org.python.Python.framework 0x95f529e8 PyMethod_New + 0xbf0 12 org.python.Python.framework 0x95f4a8d0 PyObject_Call + 0x30 13 org.python.Python.framework 0x95fa91ec PyEval_CallObjectWithKeywords + 0x100 14 org.python.Python.framework 0x95f4de40 PyInstance_New + 0x140 15 org.python.Python.framework 0x95f4a8d0 PyObject_Call + 0x30 16 org.python.Python.framework 0x95fa9ba8 PyEval_GetFuncDesc + 0x8dc 17 org.python.Python.framework 0x95fa9598 PyEval_GetFuncDesc + 0x2cc 18 org.python.Python.framework 0x95fa6c64 PyEval_EvalCode + 0x2560 19 org.python.Python.framework 0x95fa7e30 PyEval_EvalCodeEx + 0x850 20 org.python.Python.framework 0x95fa4734 PyEval_EvalCode + 0x30 21 org.python.Python.framework 0x95fc85f0 PyRun_FileExFlags + 0xe4 22 org.python.Python.framework 0x95f9db44 _PyUnicodeUCS2_IsAlpha + 0xfe4 23 org.python.Python.framework 0x95fa94a8 PyEval_GetFuncDesc + 0x1dc 24 org.python.Python.framework 0x95fa6c64 PyEval_EvalCode + 0x2560 25 org.python.Python.framework 0x95fa7e30 PyEval_EvalCodeEx + 0x850 26 org.python.Python.framework 0x95fa97dc PyEval_GetFuncDesc + 0x510 27 org.python.Python.framework 0x95fa9580 PyEval_GetFuncDesc + 0x2b4 28 org.python.Python.framework 0x95fa6c64 PyEval_EvalCode + 0x2560 29 org.python.Python.framework 0x95fa7e30 PyEval_EvalCodeEx + 0x850 30 org.python.Python.framework 0x95fa4734 PyEval_EvalCode + 0x30 31 org.python.Python.framework 0x95fc85f0 PyRun_FileExFlags + 0xe4 32 org.python.Python.framework 0x95fc7668 PyRun_SimpleFileExFlags + 0x1bc 33 ...cified.search_index_gui_app 0x00003db0 0x1000 + 0x2db0 34 ...cified.search_index_gui_app 0x00003e50 0x1000 + 0x2e50 35 ...cified.search_index_gui_app 0x00002414 0x1000 + 0x1414 36 dyld 0x8fe1a278 _dyld_start + 0x64 Thread 1: 0 libSystem.B.dylib 0x94a0b46c select + 0xc 1 com.tcltk.tcllibrary 0x0a079e88 Tcl_WaitForEvent + 0x508 2 libSystem.B.dylib 0x94a24990 _pthread_body + 0x28 PPC Thread State: srr0: 0x00000000 srr1: 0x4000d030 vrsave: 0x00000000 cr: 0x22004244 xer: 0x20000005 lr: 0x0054cb18 ctr: 0x00000000 r0: 0x0054cafc r1: 0xbfffe4f0 r2: 0xa4a016b4 r3: 0x005853c0 r4: 0x0b09ffb0 r5: 0x00000020 r6: 0x00000030 r7: 0x00003f9c r8: 0x0000007f r9: 0x00000000 r10: 0x00000000 r11: 0x00584d74 r12: 0x00000000 r13: 0x003bc320 r14: 0x00000000 r15: 0x000b7bb0 r16: 0x00000000 r17: 0x00000000 r18: 0x00000000 r19: 0x00000000 r20: 0x00000003 r21: 0x001284f0 r22: 0x00000001 r23: 0x02082ab0 r24: 0xbfffea2c r25: 0x00000150 r26: 0x00448ec4 r27: 0xa4a0170c r28: 0xa4a02360 r29: 0x0b0b2020 r30: 0x005853c0 r31: 0x0054cad8 Binary Images Description: 0x1000 - 0x4fff org.pythonmac.unspecified.search_index_gui_app 0.0.0 /Users/matoakes/Documents/Archive Index System/dist/search_index_gui_app.app/Contents/MacOS/ search_index_gui_app 0xf8000 - 0xfbfff strop.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/strop.so 0x24d000 - 0x251fff _AE.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/_AE.so 0x25f000 - 0x260fff _Evt.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/_Evt.so 0x267000 - 0x268fff MacOS.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/MacOS.so 0x270000 - 0x271fff time.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/time.so 0x2c6000 - 0x2c9fff struct.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/struct.so 0x2e5000 - 0x2edfff _File.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/_File.so 0x3a4000 - 0x3a9fff _Res.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/_Res.so 0x3fe000 - 0x400fff zlib.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/zlib.so 0x417000 - 0x427fff cPickle.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/cPickle.so 0x42f000 - 0x430fff cStringIO.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/cStringIO.so 0x436000 - 0x436fff pwd.so /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ python2.3/lib-dynload/pwd.so 0x444000 - 0x44bfff _tkinter.so /Users/matoakes/Documents/Archive Index System/dist/search_index_gui_app.app/Contents/Resources/Python/lib- dynload/_tkinter.so 0x4f5000 - 0x57bfff com.tcltk.tcllibrary 8.4.9 /Library/Frameworks/Tcl.framework/Versions/8.4/Tcl 0xa000000 - 0xa086fff com.tcltk.tcllibrary 8.4.9 /Users/matoakes/Documents/Archive Index System/dist/search_index_gui_app.app/Contents/MacOS/../Frameworks/ Tcl.framework/Versions/8.4/Tcl 0xb000000 - 0xb0b1fff com.tcltk.tklibrary 8.4.9 /Users/matoakes/Documents/Archive Index System/dist/search_index_gui_app.app/Contents/MacOS/../Frameworks/ Tk.framework/Versions/8.4/Tk 0x80830000 - 0x8090efff libxml2.2.dylib /usr/lib/libxml2.2.dylib 0x8fe00000 - 0x8fe4ffff dyld /usr/lib/dyld 0x90000000 - 0x90067fff com.apple.audio.CoreAudio 2.1.3 /System/Library/Frameworks/CoreAudio.framework/Versions/A/ CoreAudio 0x90529000 - 0x90577fff com.apple.print.framework.Print 3.3 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ Print.framework/Versions/A/Print 0x905a0000 - 0x90610fff com.apple.framework.IOKit 1.3.6 (???) /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit 0x91347000 - 0x9137ffff com.apple.LaunchServices 10.3.5 (98.4) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/LaunchServices.framework/Versions/A/ LaunchServices 0x913a0000 - 0x9145ffff ColorSync /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ColorSync.framework/Versions/A/ColorSync 0x9173a000 - 0x91743fff com.apple.DiskArbitration 2.0.5 /System/Library/PrivateFrameworks/DiskArbitration.framework/ Versions/A/DiskArbitration 0x91760000 - 0x917f3fff com.apple.print.framework.PrintCore 3.3 /System/Library/Frameworks/ApplicationServices.framework/Versions/ A/Frameworks/PrintCore.framework/Versions/A/PrintCore 0x91836000 - 0x91846fff com.apple.speech.recognition.framework 3.3 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ SpeechRecognition.framework/Versions/A/SpeechRecognition 0x91953000 - 0x91953fff com.apple.Carbon 10.3 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/Carbon 0x91955000 - 0x91955fff com.apple.CoreServices 10.3 (???) /System/Library/Frameworks/CoreServices.framework/Versions/A/ CoreServices 0x91957000 - 0x91957fff com.apple.ApplicationServices 1.0 (???) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/ApplicationServices 0x91a2f000 - 0x91aa2fff com.apple.NavigationServices 3.3.3 /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/NavigationServices.framework/Versions/A/NavigationServices 0x91b30000 - 0x91b44fff libCGATS.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/libCGATS.A.dylib 0x91b60000 - 0x91b6bfff libCSync.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/libCSync.A.dylib 0x91c7b000 - 0x91d34fff com.apple.QD 3.4.70 (???) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/QD.framework/Versions/A/QD 0x91ee4000 - 0x91efcfff com.apple.WebServices 1.1.1 (1.1.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/WebServicesCore.framework/Versions/A/WebServicesCore 0x92035000 - 0x9204ffff libresolv.9.dylib /usr/lib/libresolv.9.dylib 0x92070000 - 0x92096fff com.apple.FindByContent 1.4 (1.2) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/FindByContent.framework/Versions/A/FindByContent 0x92109000 - 0x92124fff com.apple.SystemConfiguration 1.7.1 (???) /System/Library/Frameworks/SystemConfiguration.framework/ Versions/A/SystemConfiguration 0x92170000 - 0x92357fff com.apple.security 2.4 (179) /System/Library/Frameworks/Security.framework/Versions/A/Security 0x92647000 - 0x9269afff com.apple.bom 1.2.5 (63.2) /System/Library/PrivateFrameworks/Bom.framework/Versions/A/Bom 0x927f0000 - 0x92827fff com.apple.CFNetwork 1.2.2 (7) /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/CFNetwork.framework/Versions/A/CFNetwork 0x92880000 - 0x92c05fff com.apple.HIToolbox 1.3.7 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/HIToolbox.framework/Versions/A/HIToolbox 0x92d7c000 - 0x92d96fff com.apple.openscripting 1.2.1 (???) /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/OpenScripting.framework/Versions/A/OpenScripting 0x92de0000 - 0x92e30fff com.apple.HIServices 1.4.1 (0.0.1d1) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices 0x92e70000 - 0x9336ffff com.apple.AppKit 6.3.9 (743.41) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x93680000 - 0x93958fff com.apple.CoreGraphics 1.203.30 (???) /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/CoreGraphics.framework/Versions/A/CoreGraphics 0x939d0000 - 0x939d4fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib 0x93a50000 - 0x93a64fff libcups.2.dylib /usr/lib/libcups.2.dylib 0x93a6a000 - 0x93a7dfff com.apple.speech.synthesis.framework 3.2 /System/Library/Frameworks/ApplicationServices.framework/Versions/ A/Frameworks/SpeechSynthesis.framework/Versions/A/SpeechSynthesis 0x9438a000 - 0x94396fff com.apple.help 1.0.1 /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/Help.framework/Versions/A/Help 0x943a0000 - 0x943affff libPSRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/libPSRIP.A.dylib 0x94580000 - 0x9458bfff com.apple.securityhi 1.2 (90) /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ SecurityHI.framework/Versions/A/SecurityHI 0x945b0000 - 0x945b9fff libz.1.dylib /usr/lib/libz.1.dylib 0x94610000 - 0x9462afff libPDFRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/ libPDFRIP.A.dylib 0x94650000 - 0x946affff com.apple.SearchKit 1.0.2 /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/SearchKit.framework/Versions/A/SearchKit 0x946ed000 - 0x946fafff com.apple.CommonPanels 1.2.1 (1.0) /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/CommonPanels.framework/Versions/A/CommonPanels 0x94703000 - 0x94716fff libRIP.A.dylib /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/CoreGraphics.framework/Versions/A/Resources/libRIP.A.dylib 0x94723000 - 0x94792fff libobjc.A.dylib /usr/lib/libobjc.A.dylib 0x94800000 - 0x9488cfff com.apple.ink.framework 101.1.4 (55.12) /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/Ink.framework/Versions/A/Ink 0x948fa000 - 0x949b2fff com.apple.audio.toolbox.AudioToolbox 1.3.4 /System/Library/Frameworks/AudioToolbox.framework/Versions/A/ AudioToolbox 0x94a00000 - 0x94b4ffff libSystem.B.dylib /usr/lib/libSystem.B.dylib 0x94c57000 - 0x94cdffff com.apple.CoreServices.OSServices 3.0.1 /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/OSServices.framework/Versions/A/OSServices 0x94d34000 - 0x94da7fff com.apple.DesktopServices 1.2.5 /System/Library/PrivateFrameworks/DesktopServicesPriv.framework/ Versions/A/DesktopServicesPriv 0x94e77000 - 0x94e77fff com.apple.audio.units.AudioUnit 1.3.3 /System/Library/Frameworks/AudioUnit.framework/Versions/A/ AudioUnit 0x94efd000 - 0x94f66fff com.apple.htmlrendering 1.1.2 /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/HTMLRendering.framework/Versions/A/HTMLRendering 0x951ce000 - 0x9527bfff com.apple.CoreFoundation 6.3.8 (299.36) /System/Library/Frameworks/CoreFoundation.framework/Versions/ A/CoreFoundation 0x952ed000 - 0x953b5fff libcrypto.0.9.7.dylib /usr/lib/libcrypto.0.9.7.dylib 0x954c0000 - 0x95ac6fff libBLAS.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ vecLib.framework/Versions/A/libBLAS.dylib 0x95b20000 - 0x95df0fff libLAPACK.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ vecLib.framework/Versions/A/libLAPACK.dylib 0x95f00000 - 0x95f20fff libvMisc.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ vecLib.framework/Versions/A/libvMisc.dylib 0x95f40000 - 0x96008fff org.python.Python.framework 2.2 /System/Library/Frameworks/Python.framework/Versions/2.3/Python 0x968d0000 - 0x969b2fff libicucore.A.dylib /usr/lib/libicucore.A.dylib 0x96a04000 - 0x96a71fff libvDSP.dylib /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/ vecLib.framework/Versions/A/libvDSP.dylib 0x96aa0000 - 0x96acefff libssl.0.9.7.dylib /usr/lib/libssl.0.9.7.dylib 0x96ade000 - 0x96afbfff com.apple.audio.SoundManager 3.9 /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/ CarbonSound.framework/Versions/A/CarbonSound 0x96b50000 - 0x96bdffff ATS /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ Frameworks/ATS.framework/Versions/A/ATS 0x96c00000 - 0x96c38fff com.apple.AE 1.4 /System/Library/Frameworks/ApplicationServices.framework/Versions/ A/Frameworks/AE.framework/Versions/A/AE 0x96cb0000 - 0x96d9efff libiconv.2.dylib /usr/lib/libiconv.2.dylib 0x96de0000 - 0x96df0fff com.apple.vecLib 3.0.3 (vecLib 3.0.3) /System/Library/Frameworks/vecLib.framework/Versions/A/vecLib 0x96e92000 - 0x96ea9fff com.apple.LangAnalysis 1.5.4 /System/Library/Frameworks/ApplicationServices.framework/ Versions/A/Frameworks/LangAnalysis.framework/Versions/A/LangAnalysis 0x96eb5000 - 0x96ec5fff com.apple.ImageCapture 2.1.5 /System/Library/Frameworks/Carbon.framework/Versions/A/ Frameworks/ImageCapture.framework/Versions/A/ImageCapture 0x96ee0000 - 0x96ee8fff libbsm.dylib /usr/lib/libbsm.dylib 0x977d1000 - 0x9792cfff com.apple.Foundation 6.3.7 (500.59) /System/Library/Frameworks/Foundation.framework/Versions/C/ Foundation 0x97a47000 - 0x97cc0fff com.apple.CoreServices.CarbonCore 10.3.7 /System/Library/Frameworks/CoreServices.framework/Versions/A/ Frameworks/CarbonCore.framework/Versions/A/CarbonCore From Chris.Barker at noaa.gov Fri Jan 20 18:20:04 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 20 Jan 2006 09:20:04 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> Message-ID: <43D11BC4.50105@noaa.gov> Bob Ippolito wrote: > Not yet. Not yet at all? or not yet with bdist_mpkg ? > We could mine Cheese Shop and list the pure python packages, the > packages that have Mac OS X eggs, and the mpkgs. And put the results on the pythonmac site? I like that. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Fri Jan 20 18:31:27 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 20 Jan 2006 09:31:27 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D11BC4.50105@noaa.gov> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D11BC4.50105@noaa.gov> Message-ID: <45C64DA6-7C8B-4AEC-96ED-84116178A971@redivi.com> On Jan 20, 2006, at 9:20 AM, Christopher Barker wrote: > Bob Ippolito wrote: > >> Not yet. > > Not yet at all? or not yet with bdist_mpkg ? Is there a difference? pkg bundles can contain anything that you can put on a filesystem plus arbitrary executable code to run at various points during the installation process, so there's nothing they can't do from a technical perspective. -bob From Chris.Barker at noaa.gov Fri Jan 20 18:48:59 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 20 Jan 2006 09:48:59 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <45C64DA6-7C8B-4AEC-96ED-84116178A971@redivi.com> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D11BC4.50105@noaa.gov> <45C64DA6-7C8B-4AEC-96ED-84116178A971@redivi.com> Message-ID: <43D1228B.3090800@noaa.gov> Bob Ippolito wrote: > Is there a difference? pkg bundles can contain anything that you can > put on a filesystem plus arbitrary executable code to run at various > points during the installation process, so there's nothing they can't > do from a technical perspective. That was my question. I know nothing about pkg bundles. Thanks for all your work on this. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From rowen at cesmail.net Fri Jan 20 23:30:41 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Fri, 20 Jan 2006 14:30:41 -0800 Subject: [Pythonmac-SIG] Building extensions on 10.4 that can be used on 10.3? References: <43CD6D03.7090505@noaa.gov> Message-ID: In article <43CD6D03.7090505 at noaa.gov>, Christopher Barker wrote: > Russell E. Owen wrote: > > Are there any tips or tricks to building 3rd party python extensions on > > MacOS X 10.4 in such a way that 10.3 users can use them? > > It can be done, but I think it's PITA > > > has most or all the extensions I need, > > but some of the ones I use are fairly outdated (especially numarray). So > > another option is to contribute modern versions built on 10.3 before I > > upgrade. But I'm not sure how practical that is; I only have 10.3/Python > > 2.3 > > Installing 2.4.1 from undefined.org/python is pretty trivial. > > In fact, using the 2.4.1 Framework build for OS-X 10.3, and installing > it on both 10.3 and 10.4 might well do what you want. I know the 10.3 > stuff will all run on 10.4, it's just a question of what C libs get > linked if you build on 10.4, using the 10.3 Python. I suspect that if > you use distutils, it might all work, but if you build everything on > 10.3, you're all set. > > > with instructions on how to create > > the package. > > This is very easy for anything that builds with distutils. Py2App comes > with bdist_mpkg, which will build a *.mpkg from setup.py. The only > tricky part is external libs. For instance, for matplotlib, I need to > make sure it statically linked libpng and libfreetype, so that the > package would run on a stock OS-X. > > It would be great if you contributed some upgraded packages to pythonmac. Gladly! Mostly I want to see numarray 1.5 there. It has C code and links to LAPACK and BLAS. So...do I somehow need to make it statically link? If so, how do I do that? The instructions for building numarray don't say and several searches on the topic didn't turn up anything. As to Ronald Oussoren's reply: you're absolutely right. I'll have to keep a MacOS X 10.3 machine around anyway for testing, so I might as well build the application on that. Sigh. -- Russell From Chris.Barker at noaa.gov Fri Jan 20 23:56:44 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 20 Jan 2006 14:56:44 -0800 Subject: [Pythonmac-SIG] Building extensions on 10.4 that can be used on 10.3? In-Reply-To: References: <43CD6D03.7090505@noaa.gov> Message-ID: <43D16AAC.1080807@noaa.gov> Russell E. Owen wrote: >>It would be great if you contributed some upgraded packages to pythonmac. > Gladly! > > Mostly I want to see numarray 1.5 there. Go for it. I've been meaning to do it, but haven't gotten around to it. > It has C code and links to > LAPACK and BLAS. So...do I somehow need to make it statically link? nope, that one is a piece of Cake. Apple provides LAPACK as part of it's veclib, and I think the numarray setup.py knows how to find it. python setup.py build should do it. > I'll have to > keep a MacOS X 10.3 machine around anyway for testing, so I might as > well build the application on that. Sigh. I think he said that you could build your app on 10.4, as long as all the python modules you use (and python itself) were built on 10.3. As long as you have a 10.3 machine around, you should be all set. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From silashundt at gmail.com Sat Jan 21 04:18:26 2006 From: silashundt at gmail.com (Silas Hundt) Date: Fri, 20 Jan 2006 21:18:26 -0600 Subject: [Pythonmac-SIG] dumping characters into a list Message-ID: <4EA955B6-7277-439B-8493-53DBAA18B156@gmail.com> I am at wits end. I need to do something that I would think python almost has automated: Receive input, cut that string up into individual characters (ALL characters, including spaces), put them in order into a list, then pull them out in order to convert them to a number. So... should I go ahead and create a [freeking] translate() table, or does anybody else have some better creative answers? in the mean time, I will work on that table thanks, -silas From sheila at thinkspot.net Sat Jan 21 04:24:47 2006 From: sheila at thinkspot.net (Sheila King) Date: Fri, 20 Jan 2006 19:24:47 -0800 Subject: [Pythonmac-SIG] dumping characters into a list In-Reply-To: <4EA955B6-7277-439B-8493-53DBAA18B156@gmail.com> References: <4EA955B6-7277-439B-8493-53DBAA18B156@gmail.com> Message-ID: --On January 20, 2006 9:18:26 PM -0600 Silas Hundt wrote: > Receive input, cut that string up into individual characters (ALL > characters, including spaces), put them in order into a list, then > pull them out in order to convert them to a number. > > So... should I go ahead and create a [freeking] translate() table, or > does anybody else have some better creative answers? Does this work for you? Python 2.3.5 (#1, Mar 20 2005, 20:38:20) [GCC 3.3 20030304 (Apple Computer, Inc. build 1809)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> s = "This is a string." >>> list(s) ['T', 'h', 'i', 's', ' ', 'i', 's', ' ', 'a', ' ', 's', 't', 'r', 'i', 'n', 'g', '.'] >>> -- Sheila King sheila at thinkspot.net http://www.thinkspot.net/sheila/ From sheila at thinkspot.net Sat Jan 21 04:37:55 2006 From: sheila at thinkspot.net (Sheila) Date: Fri, 20 Jan 2006 19:37:55 -0800 Subject: [Pythonmac-SIG] dumping characters into a list In-Reply-To: References: <4EA955B6-7277-439B-8493-53DBAA18B156@gmail.com> Message-ID: <3EC68BF2314405E0715F647B@Sheila-Kings-Computer.local> --On January 20, 2006 7:24:47 PM -0800 Sheila King wrote: > --On January 20, 2006 9:18:26 PM -0600 Silas Hundt > wrote: ... >> Receive input, cut that string up into individual characters (ALL >> characters, including spaces), put them in order into a list, then >> pull them out in order to convert them to a number. ... >>>> s = "This is a string." >>>> list(s) > ['T', 'h', 'i', 's', ' ', 'i', 's', ' ', 'a', ' ', 's', 't', 'r', 'i', > 'n', 'g', '.'] I'm not sure what numbers exactly you want to convert the characters to, but the one that springs to my mind are the ordinals for each character. So, if that's what you want, you could further do this: >>> chars = list(s) >>> chars ['T', 'h', 'i', 's', ' ', 'i', 's', ' ', 'a', ' ', 's', 't', 'r', 'i', 'n', 'g', '.'] >>> ords = map(ord, chars) >>> ords [84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103, 46] >>> -- Sheila King sheila at thinkspot.net http://www.thinkspot.net/sheila/ From bob at redivi.com Sat Jan 21 05:26:44 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 20 Jan 2006 20:26:44 -0800 Subject: [Pythonmac-SIG] dumping characters into a list In-Reply-To: <3EC68BF2314405E0715F647B@Sheila-Kings-Computer.local> References: <4EA955B6-7277-439B-8493-53DBAA18B156@gmail.com> <3EC68BF2314405E0715F647B@Sheila-Kings-Computer.local> Message-ID: <69504069-E8C2-4346-9418-0828432788E3@redivi.com> On Jan 20, 2006, at 7:37 PM, Sheila wrote: > --On January 20, 2006 7:24:47 PM -0800 Sheila King > > wrote: > >> --On January 20, 2006 9:18:26 PM -0600 Silas Hundt >> >> wrote: > ... >>> Receive input, cut that string up into individual characters (ALL >>> characters, including spaces), put them in order into a list, then >>> pull them out in order to convert them to a number. > ... >>>>> s = "This is a string." >>>>> list(s) >> ['T', 'h', 'i', 's', ' ', 'i', 's', ' ', 'a', ' ', 's', 't', 'r', >> 'i', >> 'n', 'g', '.'] > > I'm not sure what numbers exactly you want to convert the > characters to, > but the one that springs to my mind are the ordinals for each > character. > So, if that's what you want, you could further do this: > >>>> chars = list(s) >>>> chars > ['T', 'h', 'i', 's', ' ', 'i', 's', ' ', 'a', ' ', 's', 't', 'r', > 'i', 'n', > 'g', '.'] >>>> ords = map(ord, chars) >>>> ords > [84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, > 110, 103, > 46] You don't need that intermediate list, strings are iterable. If you want the big endian byte representation as a big number, you could do something like this: >>> chars = 'asdf' >>> sum([ord(c) << (8L * i) for i, c in enumerate(chars[::-1])]) 1634952294L >>> struct.unpack('>I', 'asdf')[0] # verify the result 1634952294L >>> chars = 'This is a string.' >>> sum([ord(c) << (8L * i) for i, c in enumerate(chars[::-1])]) 28722506059135649064412913099795503933230L You can also cheat by (ab)using built-in functionality in strange ways >>> long('This is a string.'.encode('hex'), 16) 28722506059135649064412913099795503933230L Little endian is the almost the same.. >>> chars = 'asdf' >>> sum([ord(c) << (8L * i) for i, c in enumerate(chars)]) 1717859169L >>> struct.unpack('>> chars = 'This is a string.' >>> sum([ord(c) << (8L * i) for i, c in enumerate(chars)]) 15790472653304512835830923089317093533780L >>> long('This is a string.'[::-1].encode('hex'), 16) 15790472653304512835830923089317093533780L You will need some kind of translation table if you want a value other than the ord, unless it's something like hex which has built-in support... -bob From sheila at thinkspot.net Sat Jan 21 07:01:58 2006 From: sheila at thinkspot.net (Sheila King) Date: Fri, 20 Jan 2006 22:01:58 -0800 Subject: [Pythonmac-SIG] dumping characters into a list In-Reply-To: <69504069-E8C2-4346-9418-0828432788E3@redivi.com> References: <4EA955B6-7277-439B-8493-53DBAA18B156@gmail.com> <3EC68BF2314405E0715F647B@Sheila-Kings-Computer.local> <69504069-E8C2-4346-9418-0828432788E3@redivi.com> Message-ID: <49AF0C53EF016503F065CFEF@Sheila-Kings-Computer.local> --On January 20, 2006 8:26:44 PM -0800 Bob Ippolito wrote: > You don't need that intermediate list, strings are iterable. No, you don't. I was just sort of thinking out loud here on the list...only solved half of his problem on the first round. This certainly works too: >>> map(ord, s) [84, 104, 105, 115, 32, 105, 115, 32, 97, 32, 115, 116, 114, 105, 110, 103, 46] >>> -- Sheila King sheila at thinkspot.net http://www.thinkspot.net/sheila/ From matsakis at mit.edu Sat Jan 21 08:01:28 2006 From: matsakis at mit.edu (Nicholas Matsakis) Date: Sat, 21 Jan 2006 02:01:28 -0500 (EST) Subject: [Pythonmac-SIG] Spotlight Importing without .py Message-ID: http://www.apple.com/downloads/macosx/spotlight/pythonmetadataimporter.html I really dig the Spotlight Metadata Importer for python, but it only works for files ending in ".py" which excludes various shell scripts I have written that have no filename extension. Anyone have a super elegant solution to this problem? Here's my thoughts on the matter. To my knowledge, Mac OS X has only three ways of knowing the type of a file: the HFS type code, the filename extension, and the presence of an executable bit on a file* (in order of precidence). I've already nixed filename extensions and the executable bit only seems to be able to identify something as a "Unix Executable File". So, that leaves HFS type codes. The first question is whether this is an HFS type code lying around from the days of yore that identified a python executable script? If not, would anyone mind if I registered one? (Once we've got a suitable type code, modifying the Spotlight Metadata Importer to claim it is no big deal). The more challenging part is to actually affix that type code on all extension-less python executables; As far as Mac OS X is concerned these files have no type, so there isn't a trivial way to write a script that would search for them and tag them. Using spotlight, you can at least limit your search to text and executable files, but you would still need to example their contents individually to know whether they should be tagged. This script would have to be run periodically or, if you put all such scripts in a common location you could create a launch item for it. As a crazy alternative to all of the above, the python metadata importer could be written to work in conjunction with spotmeta (http://www.fluffy.co.uk/spotmeta/) to additionally run on all text or executable files and only add the python metadata if the file actually is a python file. Not that I'm suggesting this be done or anything, but I think its an interesting idea. Hopefully Leopard will provide a more elegant solution to this problem. Nick Matsakis * The saddest part of this story is that /usr/bin/file has been on Mac OS X since day one and understands perfectly well what a "a python script text executable" is. Yet, when the Finder encounters a file without an extension or HFS code rather than, say, looking at the file to see what kind it is, it absolves all responsibility and forces you to find an application that might open it. From ronaldoussoren at mac.com Sat Jan 21 15:27:12 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 21 Jan 2006 15:27:12 +0100 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> Message-ID: On 20-jan-2006, at 3:04, Bob Ippolito wrote: > > On Jan 19, 2006, at 5:02 PM, Christopher Barker wrote: > >>> There's no good reason to prefer eggs on pythonmac.org. >> >> I don't quite follow. Are you suggesting that we don't put any >> eggs on >> pythonmac? If so, then we do put non-egg packages there? I am >> concerned >> that that will just confuse the users more. I'd really like to be >> able >> to tell people: go to this place, and all available packages for >> Python >> on OS-X are there. > > We could mine Cheese Shop and list the pure python packages, the > packages that have Mac OS X eggs, and the mpkgs. I'd prefer to see a list of packages that are known to work on OSX complemented with a link to the cheese shop for people that want to find more software. Otherwise you could just point people to the cheese shop. "pure python" doesn't mean software will work OSX, it may well have assumptions on the host system that aren't valid on OSX (parsing linux-style / proc, using APIs in the os module that are not available on OSX, ...). BTW. "known to work" can be very lightweight such as someone that has used the library and adds it to a list on the Wiki. BTW2. This reminds me of the old PackageManager, Jack's plan about it was to provide a list of easy-to-install packages that are known to work on OSX. Much can, and has, been said about the actual implementation, but the idea is a good one. Ronald > > -bob > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From ronaldoussoren at mac.com Sat Jan 21 15:30:24 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sat, 21 Jan 2006 15:30:24 +0100 Subject: [Pythonmac-SIG] Building extensions on 10.4 that can be used on 10.3? In-Reply-To: References: <43CD6D03.7090505@noaa.gov> Message-ID: <099ED32D-ED29-4B0E-BFFD-2EA3BD17B90B@mac.com> On 20-jan-2006, at 23:30, Russell E. Owen wrote: > > > As to Ronald Oussoren's reply: you're absolutely right. I'll have to > keep a MacOS X 10.3 machine around anyway for testing, so I might as > well build the application on that. Sigh. Just build the extensions there. Assuming that you do most of your development in Python you'll just have to boot into 10.3 whenever one of the extensions you use changes. If you use Bob's python 2.4 distribution and build all packages containing extensions on 10.3 py2app will happily create a 10.3 compatible application bundle on 10.4. Ronald > > -- Russell > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From jwight_lists at toxicsoftware.com Sat Jan 21 18:04:16 2006 From: jwight_lists at toxicsoftware.com (Jonathan Wight) Date: Sat, 21 Jan 2006 12:04:16 -0500 Subject: [Pythonmac-SIG] Spotlight Importing without .py In-Reply-To: References: Message-ID: <5CB4DD63-7354-4244-9665-939C8E5F9C09@toxicsoftware.com> On Jan 21, 2006, at 2:01 AM, Nicholas Matsakis wrote: > http://www.apple.com/downloads/macosx/spotlight/ > pythonmetadataimporter.html > > I really dig the Spotlight Metadata Importer for python, but it > only works > for files ending in ".py" which excludes various shell scripts I have > written that have no filename extension. Anyone have a super elegant > solution to this problem? > > Here's my thoughts on the matter. To my knowledge, Mac OS X has only > three ways of knowing the type of a file: the HFS type code, the > filename > extension, and the presence of an executable bit on a file* (in > order of > precidence). I've already nixed filename extensions and the > executable bit > only seems to be able to identify something as a "Unix Executable > File". > So, that leaves HFS type codes. The first question is whether this > is an > HFS type code lying around from the days of yore that identified a > python > executable script? If not, would anyone mind if I registered one? > (Once > we've got a suitable type code, modifying the Spotlight Metadata > Importer > to claim it is no big deal). > As a crazy alternative to all of the above, the python metadata > importer > could be written to work in conjunction with spotmeta > (http://www.fluffy.co.uk/spotmeta/) to additionally run on all text or > executable files and only add the python metadata if the file > actually is > a python file. Not that I'm suggesting this be done or anything, > but I > think its an interesting idea. Hopefully Leopard will provide a more > elegant solution to this problem. Hi Nicholas, I'm the author of Python Metadata Importer. There should already be a HFS type code for Python source. I can add the type code to Python Metadata Importer to wide its search. Getting the importer to work with Spotmeta is AFAICT a non-starter - all Spotmeta seems to do is add extra metadata to a file - it doesn't change the importer that a file is imported with. Jon. From matsakis at mit.edu Sat Jan 21 20:59:42 2006 From: matsakis at mit.edu (Nicholas Matsakis) Date: Sat, 21 Jan 2006 14:59:42 -0500 (EST) Subject: [Pythonmac-SIG] Spotlight Importing without .py In-Reply-To: <5CB4DD63-7354-4244-9665-939C8E5F9C09@toxicsoftware.com> References: <5CB4DD63-7354-4244-9665-939C8E5F9C09@toxicsoftware.com> Message-ID: On Sat, 21 Jan 2006, Jonathan Wight wrote: > I'm the author of Python Metadata Importer. There should already be a HFS > type code for Python source. I can add the type code to Python Metadata > Importer to wide its search. Getting the importer to work with Spotmeta is > AFAICT a non-starter - all Spotmeta seems to do is add extra metadata to a > file - it doesn't change the importer that a file is imported with. [I'm replying to a response that didn't go to pythonmac-sig, presumably because Jonathan's sending address isn't on the list] Actually, spotmeta allows you to have an importer extend existing importers. So, what you could do is extend the importers for text files and unix executables (which is a superset of python executables) and then check the file to see if it actually is (as near as you can tell) and if so, determine and dump the python metadata, otherwise do nothing. More details at: http://www.fluffy.co.uk/spotmeta/developer.html I mention this not because I think it's a good idea; spotmeta adds another layer of complication and the idea of inspecting _every_ text file on the system to see if it is python source seems iffy. Rather, I'm just curious what the "right" way of doing it should be. I would hope that 10.5 would bring with an extensible system of file inspection such that it would only be necessary to inspect text files that were clearly not of another type like RTF or HTML. And, of course, file inspection is really a last resort for applying types to text files since there are so many edge cases and ambiguities. Still, I just want my Mac to understand that when a file begins with #!/usr/bin/python it should try to apply the python metadata importer to it. Nick From hraban at fiee.net Sun Jan 22 01:28:48 2006 From: hraban at fiee.net (Henning Hraban Ramm) Date: Sun, 22 Jan 2006 01:28:48 +0100 Subject: [Pythonmac-SIG] Spotlight Importing without .py In-Reply-To: References: Message-ID: Am 2006-01-21 um 08:01 schrieb Nicholas Matsakis: > > * The saddest part of this story is that /usr/bin/file has been on > Mac OS > X since day one and understands perfectly well what a "a python script > text executable" is. Yet, when the Finder encounters a file > without an > extension or HFS code rather than, say, looking at the file to see > what > kind it is, it absolves all responsibility and forces you to find an > application that might open it. In this case, 'file' may be right. But I wouldn't trust it if you've to handle a lot of file types. For example, I wrote a script to watch an ISDN input folder to correct file names, unpacking archives etc. Mostly I could trust in extensions and/or Mac type/creator codes. But if someone sent some files without extension where the type/ creator codes also got lost, I tried 'file'. It's enough to reckognize text files, but it fails with most application data... Greetlings from Lake Constance! Hraban --- http://www.fiee.net http://www.cacert.org (I'm an assurer) From matsakis at mit.edu Sun Jan 22 06:13:07 2006 From: matsakis at mit.edu (Nicholas Matsakis) Date: Sun, 22 Jan 2006 00:13:07 -0500 (EST) Subject: [Pythonmac-SIG] Spotlight Importing without .py In-Reply-To: References: <5CB4DD63-7354-4244-9665-939C8E5F9C09@toxicsoftware.com> Message-ID: Henning Hraban Ramm wrote: > In this case, 'file' may be right. But I wouldn't trust it if you've to > handle a lot of file types. ... Mostly I could trust in extensions > and/or Mac type/creator codes. I certainly agree with this; applications that create files are in the best position to know how they should be typed (and thus handled by various other applications). However, if no extentions or type codes are around, then I'd rather the system make a best effort rather throw up its hands in disgust. This is especially true of the Finder, since it generally interacts directly with the user an can say something akin to "I'm not sure what kind of file this is, but it appears to be a JPEG, would you like to open it with your default app for JPEGs?" The spotlight metadata importer doesn't interact with the user and so I could see that a more conservative approach (insisting on type metadata) might be appropriate there. This has clearly gone off topic, so I'll bring it back again. I downloaded the MacPython distribution for Mac OS 9 in the hopes that I might gleen the type/creators codes associated with that distribution. There are no python sources that I can see there that don't have a .py extension, but all of them have a creator of "Pyth" and a type of "TEXT". This makes some sense, since you probably want double-clicking such a file to open it in a text editor. (.pyc files, incidentally, have a type of "PYC"). So, is it possible there is _no_ standard type code for python source? If not, any thoughts on registering one? Nick Matsakis From njriley at uiuc.edu Sun Jan 22 07:40:41 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Sun, 22 Jan 2006 00:40:41 -0600 Subject: [Pythonmac-SIG] Spotlight Importing without .py In-Reply-To: References: <5CB4DD63-7354-4244-9665-939C8E5F9C09@toxicsoftware.com> Message-ID: <20060122064041.GA85282@uiuc.edu> On Sun, Jan 22, 2006 at 12:13:07AM -0500, Nicholas Matsakis wrote: > So, is it possible there is _no_ standard type code for python source? If > not, any thoughts on registering one? Indeed, they're text files. I wouldn't want them to behave any other way. The basic problem is that a four-character HFS type code is insufficient to describe the role of a piece of (potentially executable) source code. UTIs map as of 10.4 to a file extension, MIME type, pasteboard flavor, or OSType (four-character code). What is lacking is the ability to assign a UTI directly to a file in place of the HFS type code, and/or to "sniff" a document to determine its UTI, for example by looking at the shebang line. The latter was possible in OS 9 with the Translation Manager, whereby the installed translation extensions could in turn examine a document to determine if they could open it. This facility was dropped in OS X for whatever reason and has never been restored, but it's a good bet that a future version of Spotlight will gain something similar though UTI-based. So, really, all we can do as of 10.4, short of patching frameworks, is to file bug reports and wait. Naming your executable Python scripts something ending in .py or .pyw works too. :-) -- Nicholas Riley | From kris.olson.au at gmail.com Sun Jan 22 07:35:19 2006 From: kris.olson.au at gmail.com (Kris Olson) Date: Sun, 22 Jan 2006 14:35:19 +0800 Subject: [Pythonmac-SIG] IDLE Message-ID: <3dce001b0601212235p575ddebbu19b3ffa7b6f6e49f@mail.gmail.com> Hi I have just been to a conference in Sydney called the National Computer Science School. I have come home to work on some of the python concepts we have covered and am having a problem with my mac. It won't open .cgi files with IDLE. I have tried to open it through "open with" and to change the "Open with" in the Info but IDLE is always greyed out and not accessible. Any suggestions? -- Kris Olson Geraldton Senior College Head of Business and Computing Area Curriculum Information Communication Technology Coordinator 08-9965-8443 (W) 041-792-4434 (M) 08-9965-0317 (H) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060122/fe77cc55/attachment.html From Chris.Barker at noaa.gov Mon Jan 23 18:23:38 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 23 Jan 2006 09:23:38 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> Message-ID: <43D5111A.7030700@noaa.gov> Ronald Oussoren wrote: > BTW2. This reminds me of the old PackageManager, Jack's plan about it > was to provide a list of easy-to-install packages that are known to work on > OSX. Much can, and has, been said about the actual implementation, but the idea > is a good one. Exactly. The problem with it was the same as with many other efforts to do this kind of thing for python: the effort was put into building the infrastructure, rather than building the packages. We need to make it as easy as possible to build the packages themselves, and and easy way for them to contribute them to somewhere people can find them. Really, downloading a mpkg from pythonmac.org and double clicking on it really is easy enough. All we need is an easy way to populate it. In addition, Jack had defined the idea of a "scapegoat": for a PackageManager repository, someone was taking responsibility for those being good packages and not viruses or malware or anything. I don't think that's necessary. If we we want the collection to be complete, it needs to be easy to add stuff to it. Let's wait until there is a problem before solving that problem. That's not to say that we should let just anybody upload packages to pythonmac, but if there are a handful of people that can, and they accept contributions from everyone else, we could have a pretty complete selection fairly easily. I do support the idea of using eggs. For me, the most compelling reason is the ability to install different versions. If Bob gets a chance to add egg support to bdist_mpkg, I think all we need to do is use that and put the resulting mpkgs on pythonmac. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Mon Jan 23 19:52:00 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 23 Jan 2006 10:52:00 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D5111A.7030700@noaa.gov> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> Message-ID: <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> On Jan 23, 2006, at 9:23 AM, Christopher Barker wrote: > Ronald Oussoren wrote: >> BTW2. This reminds me of the old PackageManager, Jack's plan about it >> was to provide a list of easy-to-install packages that are known >> to work on >> OSX. Much can, and has, been said about the actual implementation, >> but the idea >> is a good one. > > Exactly. The problem with it was the same as with many other > efforts to > do this kind of thing for python: the effort was put into building the > infrastructure, rather than building the packages. We need to make > it as > easy as possible to build the packages themselves, and and easy way > for > them to contribute them to somewhere people can find them. > > Really, downloading a mpkg from pythonmac.org and double clicking > on it > really is easy enough. All we need is an easy way to populate it. Eggs and Cheese Shop already have that problem way solved. python setup.py register sdist bdist_egg upload -s That will register your package on Cheese Shop, build the egg and source distro, and upload it to Cheese Shop with GPG signatures. -bob From kquirk at solidworks.com Mon Jan 23 20:30:44 2006 From: kquirk at solidworks.com (Kent Quirk) Date: Mon, 23 Jan 2006 14:30:44 -0500 Subject: [Pythonmac-SIG] Mac Intel Python status? Message-ID: What's the current status of any semi-official build of Python on Intel? We actually need to build it without readline support, haven't been able to figure out how (configure --without-readline doesn't seem to do it). It builds if we download Gnu readline and install it, but without that the build fails. Actually, what I'm really after is a Universal binary version. Has anybody built one? If so, is it available? Kent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060123/d608dbea/attachment.htm From Chris.Barker at noaa.gov Mon Jan 23 23:21:59 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 23 Jan 2006 14:21:59 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> Message-ID: <43D55707.4030504@noaa.gov> Bob Ippolito wrote: > Eggs and Cheese Shop already have that problem way solved. > > python setup.py register sdist bdist_egg upload -s > > That will register your package on Cheese Shop, build the egg and > source distro, and upload it to Cheese Shop with GPG signatures. Does the egg itself get put on cheeseshop? I just searched cheeseshop for a few packages I often use (NumPy, PIL, matplotlib). They all had links to a download page, but nothing there, and those download pages had the usual assortment of tarball, windows installers, etc (including some eggs). Frankly, that doesn't do any more for me than Google, at least for packages I already know the name of. What that tells me is that there is a need for an OS-X package (or egg) repository on pythonmac. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Mon Jan 23 23:56:52 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 23 Jan 2006 14:56:52 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D55707.4030504@noaa.gov> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> Message-ID: <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> On Jan 23, 2006, at 2:21 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> Eggs and Cheese Shop already have that problem way solved. >> >> python setup.py register sdist bdist_egg upload -s >> >> That will register your package on Cheese Shop, build the egg and >> source distro, and upload it to Cheese Shop with GPG signatures. > > Does the egg itself get put on cheeseshop? I just searched cheeseshop > for a few packages I often use (NumPy, PIL, matplotlib). They all had > links to a download page, but nothing there, and those download pages > had the usual assortment of tarball, windows installers, etc > (including > some eggs). Yes, the egg itself gets hosted on Cheese Shop, as well as the source download (hence the "upload"). The packages you often use are not yet using setuptools, so it's no surprise that they don't take advantage of these new features that aren't in distutils. Someone needs to convince the maintainers of the packages that you use that they should be using setuptools, at least for distribution (but not necessarily as a requirement for installation). > Frankly, that doesn't do any more for me than Google, at least for > packages I already know the name of. That's orthogonal. The maintainer side of the problem is 100% completely and totally solved already, that's all I was saying. Cheese Shop does have a search feature, and plenty of metadata such as trove categorizations, so you could do better than google if you paid enough attention to what features Cheese Shop has. The UI definitely does need work, though, like a search box right on the front page rather than stowed away behind a link. > What that tells me is that there is a need for an OS-X package (or > egg) > repository on pythonmac. I'm not at all convinced on that point. I definitely don't want a Mac-specific Cheese Shop, because that's more hassle for package maintainers. If pythonmac.org has any Cheese Shop-like features, they will be derived at least in part from Cheese Shop's database. -bob From rowen at cesmail.net Tue Jan 24 00:24:25 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Mon, 23 Jan 2006 15:24:25 -0800 Subject: [Pythonmac-SIG] py2app help requested: data files (and where are the examples?) Message-ID: I'm trying to convert from bundlebuilder to py2app to build my application. I installed py2app 0.2 using the installer at . I have both a working bundlebuilder script and a working py2exe script to start from. The main question: how do get my data files into the bundle? E.g. I want all (non-code) files in /foo/bar/ copied into /Contents/Resources/foo/bar/ for directories. For my py2exe script I specify a data_files argument to setup, supplying a list of (source dir, dest dir) pairs. I tried that on Mac (with the paths suitably modified) and I get an error: DistutilsFileError: can't copy 'C': doesn't exist or not a regular file Here are the elements of data_files: ('/Users/rowen/TUIRoot/TUI/Help', 'Contents/Resources/TUI/Help') ('/Users/rowen/TUIRoot/TUI/Scripts', 'Contents/Resources/TUI/Scripts') ('/Users/rowen/TUIRoot/TUI/Sounds', 'Contents/Resources/TUI/Sounds') ('/Users/rowen/TUIRoot/RO/Bitmaps', 'Contents/Resources/RO/Bitmaps') ('/Library/Tcl/snack2.2', 'Contents/Frameworks/Tcl.Framework/Resources/snack2.2') I also tried truncating data_files to just the first element of this list, with no difference. I realize I could copy the files by calls to the operating system, but I hope it doesn't come to that. Also, as an aside, where are the examples installed? I've searched for them in vain. (I also tried inspecting the py2app installer package, but wasn't sure what to do with the .pax file.) -- Russell From bob at redivi.com Tue Jan 24 00:59:22 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 23 Jan 2006 15:59:22 -0800 Subject: [Pythonmac-SIG] py2app help requested: data files (and where are the examples?) In-Reply-To: References: Message-ID: On Jan 23, 2006, at 3:24 PM, Russell E. Owen wrote: > I'm trying to convert from bundlebuilder to py2app to build my > application. > > I installed py2app 0.2 using the installer at > . I have both a working bundlebuilder > script and a working py2exe script to start from. > > The main question: how do get my data files into the bundle? E.g. I > want > all (non-code) files in /foo/bar/ copied into bundle>/Contents/Resources/foo/bar/ for directories. > > For my py2exe script I specify a data_files argument to setup, > supplying > a list of (source dir, dest dir) pairs. I tried that on Mac (with the > paths suitably modified) That's not supposed to work. If you read the docs for py2exe, it's supposed to be (dest_dir, [sources...]). py2app emulates most of py2exe's documented features, but it's apparently not bug-for-bug compatible ;) > and I get an error: > DistutilsFileError: can't copy 'C': doesn't exist or not a regular > file That's because you passed a string where a list of strings is supposed to go. Unfortunately, strings in Python act like list of single-character strings. > Here are the elements of data_files: > ('/Users/rowen/TUIRoot/TUI/Help', 'Contents/Resources/TUI/Help') > ('/Users/rowen/TUIRoot/TUI/Scripts', 'Contents/Resources/TUI/Scripts') > ('/Users/rowen/TUIRoot/TUI/Sounds', 'Contents/Resources/TUI/Sounds') > ('/Users/rowen/TUIRoot/RO/Bitmaps', 'Contents/Resources/RO/Bitmaps') > ('/Library/Tcl/snack2.2', > 'Contents/Frameworks/Tcl.Framework/Resources/snack2.2') > > I also tried truncating data_files to just the first element of this > list, with no difference. data_files is incorrect. I'm not sure why what you have works elsewhere, but it's not documented to work. data_files needs to look like this: data_files=[ (destination_dir, [srcfile, ...]), ] What you have is not only the wrong kinds of data, but in the wrong order... I'm quite surprised that worked in py2exe, but maybe bundlebuilder used a different syntax for data_files? > Also, as an aside, where are the examples installed? I've searched for > them in vain. (I also tried inspecting the py2app installer > package, but > wasn't sure what to do with the .pax file.) This is actually documented: http://undefined.org/python/py2app.html As far as introspecting an installer pkg, you'd want to use lsbom on the bom (bill of materials) file. -bob From Chris.Barker at noaa.gov Tue Jan 24 01:35:21 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Mon, 23 Jan 2006 16:35:21 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> Message-ID: <43D57649.60409@noaa.gov> Bob Ippolito wrote: > Yes, the egg itself gets hosted on Cheese Shop, as well as the source > download (hence the "upload"). > > The packages you often use are not yet using setuptools, Do you know of a package I can find on cheeseshop that is using setuptools? I'd like to get a sense of what features that offers. > so it's no > surprise that they don't take advantage of these new features that > aren't in distutils. Well, matplotlib has an egg on the sourceforge download site, and NumPy is putting its include files in a odd place specifically to accommodate ssetuptools, and neither of those have eggs on cheeseshop. I guess setuptools really hasn't caught on yet. but it does seem to be gaining a lot of momentum, so I'm hopeful. > Someone needs to convince the maintainers of the > packages that you use that they should be using setuptools, at least > for distribution (but not necessarily as a requirement for installation). > >> Frankly, that doesn't do any more for me than Google, at least for >> packages I already know the name of. > > That's orthogonal. That was based on the fact that I just got pointed back to the project's primary download site anyway, that's usually not hard to find (for a project I know about anyway). If the eggs were available directly on Cheeseshop, then it would be better. >> What that tells me is that there is a need for an OS-X package (or egg) >> repository on pythonmac. > > I'm not at all convinced on that point. The reason we've ever needed it hasn't changed: most package maintainers don't build packages for OS-X. The Mac community has always had to do that itself for most packages. The only exception for the packages I use is wxPython. (and Robin is looking into eggs) If we can't get package maintainers to build OS-X compatible eggs, what good does cheese shop do? It's also really nice to have one-stop shopping for OS-X Python packages. Another issue I wonder about is all the possible combinations of OS-X and Python versions that we're dealing with. Do they all need a separate egg? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Tue Jan 24 02:13:23 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 23 Jan 2006 17:13:23 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D57649.60409@noaa.gov> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> Message-ID: <52CB7E24-EDA9-40E0-A592-6D18C9E27A1F@redivi.com> On Jan 23, 2006, at 4:35 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> Yes, the egg itself gets hosted on Cheese Shop, as well as the source >> download (hence the "upload"). >> >> The packages you often use are not yet using setuptools, > > Do you know of a package I can find on cheeseshop that is using > setuptools? I'd like to get a sense of what features that offers. Paste/PasteScript/PasteDeploy use just about all of the features that setuptools has, but you're unlikely to make any sense out of it. From a developer's perspective, setuptools gives you: - Fixes to distutils to make it suck less (e.g. Cheese Shop register/ upload even in Python 2.3, find_packages(), etc.) - Subversion integration (no more MANIFEST.in junk, allows tagging releases with versions) - Entry points (allows other eggs to provide plugins for your egg, or for your egg to provide plugins to others) - develop and test commands (develop is *awesome*) - Allows you to declare dependencies and optional dependencies (as extras) - Allows you to require a specific version of a package.. which even works if there are multiple versions of that package installed (though only one can be loaded by a given Python interpreter process, of course). This is particularly relevant for things like wxPython, where fragile hacks are used to try and make this happen. - Provides for in-package data files and in-egg metadata, in all situations (even if the egg is zipped, if you use the pkg_resources APIs your code will still work) From a user's perspective, setuptools gives you: - Easy installation, including the download of dependencies - Easy upgrades And there are network effects.. because tools like py2app and py2exe will take advantage of eggs to more reliably produce packages with no hacking. Libraries like PIL could be extended with additional image plugins without doing something dumb like scanning sys.path for Python files named "*ImagePlugin.py". You really ought to read the docs: http://peak.telecommunity.com/DevCenter/setuptools http://peak.telecommunity.com/DevCenter/EasyInstall >> so it's no >> surprise that they don't take advantage of these new features that >> aren't in distutils. > > Well, matplotlib has an egg on the sourceforge download site, and > NumPy > is putting its include files in a odd place specifically to > accommodate > ssetuptools, and neither of those have eggs on cheeseshop. I guess > setuptools really hasn't caught on yet. but it does seem to be > gaining a > lot of momentum, so I'm hopeful. Well if they can build an egg, they can upload it to Cheese Shop with one command. They probably just haven't invested the five minutes to read over the setuptools documentation to see that it has an upload feature. >> Someone needs to convince the maintainers of the >> packages that you use that they should be using setuptools, at least >> for distribution (but not necessarily as a requirement for >> installation). >> >>> Frankly, that doesn't do any more for me than Google, at least for >>> packages I already know the name of. >> >> That's orthogonal. > > That was based on the fact that I just got pointed back to the > project's > primary download site anyway, that's usually not hard to find (for a > project I know about anyway). If the eggs were available directly on > Cheeseshop, then it would be better. They are, but only if the maintainer goes through the trouble to type "python setup.py bdist_egg upload" and press enter. For most projects, easy_install will automatically download the correct egg from the download page -- but only if the maintainer (or sourceforge) doesn't fuck up the HTML. It sounds like that happened when you tried it. >>> What that tells me is that there is a need for an OS-X package >>> (or egg) >>> repository on pythonmac. >> >> I'm not at all convinced on that point. > > The reason we've ever needed it hasn't changed: most package > maintainers > don't build packages for OS-X. The Mac community has always had to do > that itself for most packages. The only exception for the packages > I use > is wxPython. (and Robin is looking into eggs) > > If we can't get package maintainers to build OS-X compatible eggs, > what > good does cheese shop do? That can change. Cheese Shop allows package owners to easily add additional maintainers. They could delegate the authority to you to upload Mac OS X eggs, for example. It takes four clicks and a user name (click login, click somepackage, click role, type the user name, click add role). > It's also really nice to have one-stop shopping for OS-X Python > packages. That can easily be Cheese Shop. pythonmac.org could contain some metadata for packages that are definitely known to work on Mac OS X, but I don't think it should be independent from Cheese Shop. > Another issue I wonder about is all the possible combinations of OS-X > and Python versions that we're dealing with. Do they all need a > separate > egg? Yes. That's not really different than now, with the exception that easy_install/setuptools knows which egg to download. This is big, because it seems that many users have trouble deciding which pkg is appropriate to download from pythonmac.org/packages/ Eggs are probably also the solution to distributing universal applications. Using separate eggs for PPC and x86, py2app could collect all eggs for both architectures for and stick them in the bundle. Currently, it's basically infeasible for PPC users to reliably build x86 eggs (and impossible to test them), so this is big for anyone still on PPC. -bob From robert.kern at gmail.com Tue Jan 24 02:55:48 2006 From: robert.kern at gmail.com (Robert Kern) Date: Mon, 23 Jan 2006 19:55:48 -0600 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <52CB7E24-EDA9-40E0-A592-6D18C9E27A1F@redivi.com> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <52CB7E24-EDA9-40E0-A592-6D18C9E27A1F@redivi.com> Message-ID: <43D58924.3030909@gmail.com> Bob Ippolito wrote: > Well if they can build an egg, they can upload it to Cheese Shop with > one command. They probably just haven't invested the five minutes to > read over the setuptools documentation to see that it has an upload > feature. *Believe me,* I've spent more than five minutes reading the setuptools docs and getting these package buildable as eggs. What I haven't done is spend the time to convince the other maintainers to distribute via PyPI in addition to Sourceforge. One must have priorities. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From bob at redivi.com Tue Jan 24 03:14:25 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 23 Jan 2006 18:14:25 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D58924.3030909@gmail.com> References: <2EA4643A-F98F-40ED-AC55-E5150A3DFB5B@utoronto.ca> <52B43CA0-6ED4-443F-9705-088B6030E209@utoronto.ca> <6417728E-5493-436D-90F5-0B0E7F5EB69B@redivi.com> <43CFDE00.7030607@noaa.gov> <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <52CB7E24-EDA9-40E0-A592-6D18C9E27A1F@redivi.com> <43D58924.3030909@gmail.com> Message-ID: <3299168A-9C00-4957-823C-EE95A4338CD9@redivi.com> On Jan 23, 2006, at 5:55 PM, Robert Kern wrote: > Bob Ippolito wrote: > >> Well if they can build an egg, they can upload it to Cheese Shop with >> one command. They probably just haven't invested the five minutes to >> read over the setuptools documentation to see that it has an upload >> feature. > > *Believe me,* I've spent more than five minutes reading the > setuptools docs and > getting these package buildable as eggs. What I haven't done is > spend the time > to convince the other maintainers to distribute via PyPI in > addition to > Sourceforge. One must have priorities. Well, sourceforge sucks, especially for distribution. It's hard to put packages there, and it's a hassle to download them -- especially programmatically. If I were still using it for distribution, I'd be jumping at the chance to use something that sucks less. Cheese Shop has the same uptime and reliability as python.org (which is to say, VERY good), hosting source and binary distributions there is free and single step (two steps if you want to sign, because you need to provide your passphrase to GPG), and downloading source from there is quick and reliable. You don't even need to change your setup.py: http://tinyurl.com/9zxc4 Even if you don't have an egg-compatible package (which is unlikely, because zip_safe=False covers most of those cases), you could still put your sdist there. Worst case, you have your distributions available from two places.. -bob From cwmoad at gmail.com Tue Jan 24 03:50:23 2006 From: cwmoad at gmail.com (Charlie Moad) Date: Mon, 23 Jan 2006 21:50:23 -0500 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D57649.60409@noaa.gov> References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> Message-ID: <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> > > Yes, the egg itself gets hosted on Cheese Shop, as well as the source > > download (hence the "upload"). > > > > The packages you often use are not yet using setuptools, > > Do you know of a package I can find on cheeseshop that is using > setuptools? I'd like to get a sense of what features that offers. > > > so it's no > > surprise that they don't take advantage of these new features that > > aren't in distutils. > > Well, matplotlib has an egg on the sourceforge download site, and NumPy > is putting its include files in a odd place specifically to accommodate > ssetuptools, and neither of those have eggs on cheeseshop. I guess > setuptools really hasn't caught on yet. but it does seem to be gaining a > lot of momentum, so I'm hopeful. I just thought I would mention that you don't see the mpl eggs on cheeseshop for a reason. The download url is set to mpl's sf files page. Setuptools is smart enough to look at cheeseshop and see the download url and then find the correct egg from there, hence 'easy_install matplotlib' works. Sorry if I misinterpreted your post. - Charlie From bob at redivi.com Tue Jan 24 04:07:10 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 23 Jan 2006 19:07:10 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> Message-ID: <8C4B0878-7B08-438A-9EF7-B7D9FE4D1B54@redivi.com> On Jan 23, 2006, at 6:50 PM, Charlie Moad wrote: >>> Yes, the egg itself gets hosted on Cheese Shop, as well as the >>> source >>> download (hence the "upload"). >>> >>> The packages you often use are not yet using setuptools, >> >> Do you know of a package I can find on cheeseshop that is using >> setuptools? I'd like to get a sense of what features that offers. >> >>> so it's no >>> surprise that they don't take advantage of these new features that >>> aren't in distutils. >> >> Well, matplotlib has an egg on the sourceforge download site, and >> NumPy >> is putting its include files in a odd place specifically to >> accommodate >> ssetuptools, and neither of those have eggs on cheeseshop. I guess >> setuptools really hasn't caught on yet. but it does seem to be >> gaining a >> lot of momentum, so I'm hopeful. > > I just thought I would mention that you don't see the mpl eggs on > cheeseshop for a reason. The download url is set to mpl's sf files > page. Setuptools is smart enough to look at cheeseshop and see the > download url and then find the correct egg from there, hence > 'easy_install matplotlib' works. Sorry if I misinterpreted your post. The reason you don't see the egg on Cheese Shop is because a maintainer did not upload it to Cheese Shop, period. setuptools is smart enough to install things from SVN urls, source tarballs/zips, and eggs.. and it does a relatively good job at globbing those URLs out of anchor tags on the HTML pages that it finds via the Cheese Shop metadata -- but that's not *why* the eggs aren't on Cheese Shop. -bob From cwmoad at gmail.com Tue Jan 24 04:14:10 2006 From: cwmoad at gmail.com (Charlie Moad) Date: Mon, 23 Jan 2006 22:14:10 -0500 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <8C4B0878-7B08-438A-9EF7-B7D9FE4D1B54@redivi.com> References: <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <8C4B0878-7B08-438A-9EF7-B7D9FE4D1B54@redivi.com> Message-ID: <6382066a0601231914s21dce4bfqe483eebee1cec4f1@mail.gmail.com> On 1/23/06, Bob Ippolito wrote: > > On Jan 23, 2006, at 6:50 PM, Charlie Moad wrote: > > >>> Yes, the egg itself gets hosted on Cheese Shop, as well as the > >>> source > >>> download (hence the "upload"). > >>> > >>> The packages you often use are not yet using setuptools, > >> > >> Do you know of a package I can find on cheeseshop that is using > >> setuptools? I'd like to get a sense of what features that offers. > >> > >>> so it's no > >>> surprise that they don't take advantage of these new features that > >>> aren't in distutils. > >> > >> Well, matplotlib has an egg on the sourceforge download site, and > >> NumPy > >> is putting its include files in a odd place specifically to > >> accommodate > >> ssetuptools, and neither of those have eggs on cheeseshop. I guess > >> setuptools really hasn't caught on yet. but it does seem to be > >> gaining a > >> lot of momentum, so I'm hopeful. > > > > I just thought I would mention that you don't see the mpl eggs on > > cheeseshop for a reason. The download url is set to mpl's sf files > > page. Setuptools is smart enough to look at cheeseshop and see the > > download url and then find the correct egg from there, hence > > 'easy_install matplotlib' works. Sorry if I misinterpreted your post. > > The reason you don't see the egg on Cheese Shop is because a > maintainer did not upload it to Cheese Shop, period. > > setuptools is smart enough to install things from SVN urls, source > tarballs/zips, and eggs.. and it does a relatively good job at > globbing those URLs out of anchor tags on the HTML pages that it > finds via the Cheese Shop metadata -- but that's not *why* the eggs > aren't on Cheese Shop. My post was mpl specific, but in general of course that's the case. From Chris.Barker at noaa.gov Tue Jan 24 18:12:00 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 24 Jan 2006 09:12:00 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> Message-ID: <43D65FE0.2080207@noaa.gov> Charlie Moad wrote: > I just thought I would mention that you don't see the mpl eggs on > cheeseshop for a reason. The download url is set to mpl's sf files > page. Setuptools is smart enough to look at cheeseshop and see the > download url and then find the correct egg from there, hence > 'easy_install matplotlib' works. Sorry if I misinterpreted your post. No, you didn't misinterpret my post, but according to Bob, you could easily upload the eggs directly to cheeseshop -- why not do that? Another issue is that the Cheeseshop interface could use some work, as it wasn't the least bit clear that that magic could occur. And the third, is that on the sourceforge download page, I didn't see an OS-X egg. I was about to poke through the MPL list and see what you said about this, but I guess I'll just try: 'easy_install matplotlib' and see what happens. This is all a bit of a mess now, but it looks very promising, and I think Bob has convinced me: For any package I need, I'll try to build an egg, and try to get it uploaded to cheeseshop. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From robert.kern at gmail.com Tue Jan 24 18:13:39 2006 From: robert.kern at gmail.com (Robert Kern) Date: Tue, 24 Jan 2006 11:13:39 -0600 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D65FE0.2080207@noaa.gov> References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <43D65FE0.2080207@noaa.gov> Message-ID: <43D66043.5020500@gmail.com> Christopher Barker wrote: > No, you didn't misinterpret my post, but according to Bob, you could > easily upload the eggs directly to cheeseshop -- why not do that? Because he's not finished testing it, yet? These particular packages are somewhat complicated and only recently have been eggified. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From cwmoad at gmail.com Tue Jan 24 19:17:48 2006 From: cwmoad at gmail.com (Charlie Moad) Date: Tue, 24 Jan 2006 13:17:48 -0500 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D66043.5020500@gmail.com> References: <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <43D65FE0.2080207@noaa.gov> <43D66043.5020500@gmail.com> Message-ID: <6382066a0601241017s6486ea47l3d9cfe1901145399@mail.gmail.com> > > No, you didn't misinterpret my post, but according to Bob, you could > > easily upload the eggs directly to cheeseshop -- why not do that? > > Because he's not finished testing it, yet? These particular packages are > somewhat complicated and only recently have been eggified. Technically because there is also a 5MB limit on cheeseshop which the mpl binary eggs surpass by a few MB. The windows/linux mpl eggs seem to work fine, and I was even able to include static libs for freetype and png in the osx.4 egg. Robert is right as well though. I am waiting for these to become a little more mainstream before I post them (them == osx eggs, because win32/linux eggs are up on sf). From Chris.Barker at noaa.gov Tue Jan 24 19:27:41 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 24 Jan 2006 10:27:41 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D65FE0.2080207@noaa.gov> References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <43D65FE0.2080207@noaa.gov> Message-ID: <43D6719D.6050607@noaa.gov> Christopher Barker wrote: > I guess I'll just try: 'easy_install matplotlib' and > see what happens. Well, first I had to get setuptools installed. cheeseshop has an egg, but how do I install that? So I downloaded the zip file, and in there found that I needed to do: $ python ez_setup.py Which said that it worked, but I couldn't find the easy_install script anywhere. Afer much floundering, I finally figured out that it put it in: /Library/Frameworks/Python.framework/Versions/2.4/bin which is not on my $PATH. Should it be? or should there be links to those scripts in /usr/local/bin? once I got that figured out, I tried to use it to install MPL. It didn't work. I'll move that discussion over to the MPL list. I do think this all has promise, but there are some wrinkles to smooth out, and I'm thinking that maybe, once all is said and done, there will still be the need for "click to install" mpkgs for OS-X. If nothing else, there should be one for setuptools itself! -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From cwmoad at gmail.com Tue Jan 24 19:33:40 2006 From: cwmoad at gmail.com (Charlie Moad) Date: Tue, 24 Jan 2006 13:33:40 -0500 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D6719D.6050607@noaa.gov> References: <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <43D65FE0.2080207@noaa.gov> <43D6719D.6050607@noaa.gov> Message-ID: <6382066a0601241033x788ab61eidc00bb993a55c0c7@mail.gmail.com> > Which said that it worked, but I couldn't find the easy_install script > anywhere. Afer much floundering, I finally figured out that it put it in: > > /Library/Frameworks/Python.framework/Versions/2.4/bin > > which is not on my $PATH. Should it be? or should there be links to > those scripts in /usr/local/bin? setuptools respects a ~/.pydistutils.cfg file which you can specify where to install things. Here is what mine looks like: --------------------------------------------- [easy_install] script_dir = /usr/local/bin --------------------------------------------- From bob at redivi.com Tue Jan 24 19:40:50 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 24 Jan 2006 10:40:50 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D6719D.6050607@noaa.gov> References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <43D65FE0.2080207@noaa.gov> <43D6719D.6050607@noaa.gov> Message-ID: <5DF15570-4A6C-4ECD-9398-0E0F510C3FC9@redivi.com> On Jan 24, 2006, at 10:27 AM, Christopher Barker wrote: > Christopher Barker wrote: >> I guess I'll just try: 'easy_install matplotlib' and >> see what happens. > > Well, first I had to get setuptools installed. cheeseshop has an egg, > but how do I install that? So I downloaded the zip file, and in there > found that I needed to do: > > $ python ez_setup.py > > Which said that it worked, but I couldn't find the easy_install script > anywhere. Afer much floundering, I finally figured out that it put > it in: You REALLY should read the docs. http://peak.telecommunity.com/DevCenter/EasyInstall -bob From Chris.Barker at noaa.gov Tue Jan 24 20:08:25 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 24 Jan 2006 11:08:25 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <5DF15570-4A6C-4ECD-9398-0E0F510C3FC9@redivi.com> References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <43D65FE0.2080207@noaa.gov> <43D6719D.6050607@noaa.gov> <5DF15570-4A6C-4ECD-9398-0E0F510C3FC9@redivi.com> Message-ID: <43D67B29.8080705@noaa.gov> Bob Ippolito wrote: > You REALLY should read the docs. Of course I should, and I did. I also did my floundering until I identified the problem before asking for help here. My comment here was bringing up the question of how, on OS-X, we want to recommend people deal with having installed scripts on their $PATH. However, this whole discussion started because I thought we wanted to have an easy way for newbies to find and install packages on OS-X. This has not be easy for me so far, and I am neither an OS-X nor a *nix newbie. If it was just me, I'd just run the setup.py scripts that come with the packages and be done with it, but I want to help out the community, as well as having a standard approach to point my colleagues to. > http://peak.telecommunity.com/DevCenter/EasyInstall The only thing it says there about installing the easy_install script is: "An easy_install script will be installed in the normal location for Python scripts on your platform." You've seen me on this list for years, and I have NEVER noticed /Library/Frameworks/Python.framework/Versions/2.4/bin before. I have had scripts installed in /usr/local/bin. (probably from mpkgs put together by Bob) So, the question is: What should "standard Practice" be for handling scripts installed by easy-install (and distutils, I suppose). I see a couple options so far: * Advise people to put: /Library/Frameworks/Python.framework/Versions/2.4/bin on their PATH. * Have people put symlinks to scripts in there in their PATH. * Follow Charlie's suggestion: Create a ~/.pydistutils.cfg file with: --------------------------------------------- [easy_install] script_dir = /usr/local/bin --------------------------------------------- in it. By the way, I didn't see any mention of the script_dir value in the Easy_Install doc. None of those options are particularly newbie-friendly. * Change the default script_dir in the "official unofficial" Framework builds to /usr/local/bin That's more newbie-friendly, but I'm sure has lots of other problems. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov From bob at redivi.com Tue Jan 24 20:20:31 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 24 Jan 2006 11:20:31 -0800 Subject: [Pythonmac-SIG] Mac Python and eggs... In-Reply-To: <43D67B29.8080705@noaa.gov> References: <43D036A3.7000107@noaa.gov> <35E85CDE-84D3-4AE6-87C1-A2DD4130D024@redivi.com> <43D5111A.7030700@noaa.gov> <46D4F539-1D35-417A-A652-B2D468CBEDF0@redivi.com> <43D55707.4030504@noaa.gov> <0E1C3DEF-88B9-49E6-8FA4-D8B551ACF638@redivi.com> <43D57649.60409@noaa.gov> <6382066a0601231850u227b3f39n9a2a941f53826149@mail.gmail.com> <43D65FE0.2080207@noaa.gov> <43D6719D.6050607@noaa.gov> <5DF15570-4A6C-4ECD-9398-0E0F510C3FC9@redivi.com> <43D67B29.8080705@noaa.gov> Message-ID: <67D16263-8D42-499B-9B29-63A01F61B2B1@redivi.com> On Jan 24, 2006, at 11:08 AM, Christopher Barker wrote: > Bob Ippolito wrote: > >> You REALLY should read the docs. > > Of course I should, and I did. I also did my floundering until I > identified the problem before asking for help here. My comment here > was > bringing up the question of how, on OS-X, we want to recommend people > deal with having installed scripts on their $PATH. > > However, this whole discussion started because I thought we wanted to > have an easy way for newbies to find and install packages on OS-X. > This > has not be easy for me so far, and I am neither an OS-X nor a *nix > newbie. If it was just me, I'd just run the setup.py scripts that come > with the packages and be done with it, but I want to help out the > community, as well as having a standard approach to point my > colleagues to. If you ran the setup.py script that came with the packages, the scripts would get installed to the same place. >> http://peak.telecommunity.com/DevCenter/EasyInstall > > The only thing it says there about installing the easy_install > script is: > > "An easy_install script will be installed in the normal location for > Python scripts on your platform." And it did. > You've seen me on this list for years, and I have NEVER noticed > > /Library/Frameworks/Python.framework/Versions/2.4/bin > > before. I have had scripts installed in /usr/local/bin. (probably from > mpkgs put together by Bob) That's why. > So, the question is: > > What should "standard Practice" be for handling scripts installed by > easy-install (and distutils, I suppose). I see a couple options so > far: > > * Advise people to put: > > /Library/Frameworks/Python.framework/Versions/2.4/bin > > on their PATH. > > * Have people put symlinks to scripts in there in their PATH. > > * Follow Charlie's suggestion: > > Create a ~/.pydistutils.cfg file with: > > --------------------------------------------- > [easy_install] > script_dir = /usr/local/bin > --------------------------------------------- There's a fourth suggestion which installs to your homedir instead of globally. That's documented in the EasyInstall documentation. Very close to Charlie's suggestion: http://peak.telecommunity.com/DevCenter/EasyInstall#mac-os-x-user- installation [install] install_lib = ~/Library/Python$py_version_short/site-packages install_scripts = ~/bin > By the way, I didn't see any mention of the script_dir value in the > Easy_Install doc. It's mentioned at least three times in the custom installations section. > None of those options are particularly newbie-friendly. > > * Change the default script_dir in the "official unofficial" Framework > builds to /usr/local/bin > > That's more newbie-friendly, but I'm sure has lots of other problems. Yeah. Either way, this is the fault of the framework Python, not setuptools. It's just inheriting this behavior from distutils. -bob From rowen at cesmail.net Tue Jan 24 22:08:16 2006 From: rowen at cesmail.net (Russell E. Owen) Date: Tue, 24 Jan 2006 13:08:16 -0800 Subject: [Pythonmac-SIG] py2app help requested: data files (and where are the examples?) References: Message-ID: In article , Bob Ippolito wrote: > On Jan 23, 2006, at 3:24 PM, Russell E. Owen wrote: > > > I'm trying to convert from bundlebuilder to py2app to build my > > application. (...and having trouble getting my data files imported...) > >... > > Here are the elements of data_files: > > ('/Users/rowen/TUIRoot/TUI/Help', 'Contents/Resources/TUI/Help') > > ('/Users/rowen/TUIRoot/TUI/Scripts', 'Contents/Resources/TUI/Scripts') > > ('/Users/rowen/TUIRoot/TUI/Sounds', 'Contents/Resources/TUI/Sounds') > > ('/Users/rowen/TUIRoot/RO/Bitmaps', 'Contents/Resources/RO/Bitmaps') > > ('/Library/Tcl/snack2.2', > > 'Contents/Frameworks/Tcl.Framework/Resources/snack2.2') > >... > > data_files is incorrect. I'm not sure why what you have works > elsewhere, but it's not documented to work. data_files needs to look > like this: > > data_files=[ > (destination_dir, [srcfile, ...]), > ] Oops. Good catch. I was mixing up my bundlebuilder script and my py2exe script. > > Also, as an aside, where are the examples installed? I've searched for > > them in vain. (I also tried inspecting the py2app installer > > package, but > > wasn't sure what to do with the .pax file.) > > This is actually documented: > http://undefined.org/python/py2app.html Thanks! (It wasn't in the local manual, which I thought was the same as the on-line version, but there have obviously been some useful additions!) Everything is now working great. Thank you very much for the help! A few tips for others: - data_files get copied before frameworks. If you have data that has to go somewhere into frameworks (in my case the tcl snack library), you may have to move it there later, because if it's copied too soon it may create a directory that should have been a link, making the framework import fail. In my case, I have data_files import snack somewhere innocuous (Contents/Resources) and then move it later with os.rename. - Tkinter users can save 11Mb if you clear out the documentation. For ActiveState Tcl, English version, this is in: Contents/Frameworks/Tcl.Framework/Resources/English.lproj/ActiveTcl-8.4 - Speaking of Tkinter, if you're not using 8.4.11 you should definitely upgrade. It has some very important bug fixes for Aqua Tk. -- Russell From trentm at ActiveState.com Tue Jan 24 23:35:12 2006 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 24 Jan 2006 14:35:12 -0800 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.2.10 is now available Message-ID: <20060124223512.GC24854@activestate.com> I'm happy to announce that ActivePython 2.4.2.10 is now available from: http://www.ActiveState.com/Products/ActivePython/ This release is a maintenance/update release for existing platforms and adds support for three new platforms: Mac OS X/x86, Windows/x64 and Linux/x86_64. See the announcement on python-announce for full details. Most importantly to Mac users this ActivePython release includes: - an early build of for Mac OS X/Intel (macosx-x86), and - fixed a problem on Mac OS X/PowerPC that unintentionally created a dependency on Fink (fink.sourceforge.net) for the "bz2" and "curses" extensions. (Thanks, Bob!) Mac OS X for Intel ------------------ This is the first release of ActivePython for Mac OS X/Intel. It should be considered an early release. This build is not a universal build and there are a number of known issues: http://aspn.activestate.com/ASPN/docs/ActivePython/2.4/relnotes.html#KI_macosx I suspect that ultimately a universal Python build is the right answer, but details and issues around that should be discussed here. I'd like to help where I can, but I know that there are folks on this list more knowledgeable than I am about the issues involved. Any feedback would be appreciated. Cheers, Trent, Python Tech Lead -- Trent Mick TrentM at ActiveState.com From bear42 at code-bear.com Wed Jan 25 00:59:35 2006 From: bear42 at code-bear.com (bear) Date: Tue, 24 Jan 2006 18:59:35 -0500 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.2.10 is now available In-Reply-To: <20060124223512.GC24854@activestate.com> References: <20060124223512.GC24854@activestate.com> Message-ID: <43D6BF67.5080503@code-bear.com> Trent Mick wrote: > I suspect that ultimately a universal Python build is the right answer, but > details and issues around that should be discussed here. I'd like to help > where I can, but I know that there are folks on this list more knowledgeable > than I am about the issues involved. Any feedback would be appreciated. > I'm also just starting down the path of creating a Universal Binary build of Python 2.4.2 and would love to help ferret out all of the issues involved. I'm not anywhere near the level of guru-ness that others are for OS X builds but I have the time and an Intel iMac that I can use to do builds on. So far I've been reading the preliminary work that Bob has done and I've been starting to wade thru the Apple dev docs but have yet to construct a configure line that works :) Let me know what I can do to help. Pointers to how you guys are doing the builds would help :) --- Bear Build and Release Engineer Open Source Applications Foundation (OSAF) bear at osafoundation.org From kquirk at solidworks.com Wed Jan 25 01:35:46 2006 From: kquirk at solidworks.com (Kent Quirk) Date: Tue, 24 Jan 2006 19:35:46 -0500 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.2.10 is now available Message-ID: In the hopes of avoiding some redundant work...I happen to be sitting in a workshop at the Apple campus as I speak, and one of the Apple engineers here has just modified the Apple 2.3.5 build system to work with 2.4.2, and to build a Universal version of Python 2.4.2. I haven't run a full suite of tests, but it does appear to work. He has promised that he's going to post those changes to the pythonmac.org wiki Real Soon Now, hopefully today. There is a problem with it, which is that it builds into /System/Library/Frameworks. I've sent him email asking for that to change, but I don't know where that will end up. Nonetheless, many of the problems have already been solved, and hopefully the (intermediate) result will be posted very soon. Kent -----Original Message----- From: pythonmac-sig-bounces at python.org [mailto:pythonmac-sig-bounces at python.org] On Behalf Of bear Sent: Tuesday, January 24, 2006 7:00 PM To: Trent Mick Cc: pythonmac-sig at python.org Subject: Re: [Pythonmac-SIG] ANN: ActivePython 2.4.2.10 is now available Trent Mick wrote: > I suspect that ultimately a universal Python build is the right answer, but > details and issues around that should be discussed here. I'd like to help > where I can, but I know that there are folks on this list more knowledgeable > than I am about the issues involved. Any feedback would be appreciated. > I'm also just starting down the path of creating a Universal Binary build of Python 2.4.2 and would love to help ferret out all of the issues involved. I'm not anywhere near the level of guru-ness that others are for OS X builds but I have the time and an Intel iMac that I can use to do builds on. So far I've been reading the preliminary work that Bob has done and I've been starting to wade thru the Apple dev docs but have yet to construct a configure line that works :) Let me know what I can do to help. Pointers to how you guys are doing the builds would help :) --- Bear Build and Release Engineer Open Source Applications Foundation (OSAF) bear at osafoundation.org _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG at python.org http://mail.python.org/mailman/listinfo/pythonmac-sig From trentm at ActiveState.com Wed Jan 25 01:45:51 2006 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 24 Jan 2006 16:45:51 -0800 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.2.10 is now available In-Reply-To: <43D6BF67.5080503@code-bear.com> References: <20060124223512.GC24854@activestate.com> <43D6BF67.5080503@code-bear.com> Message-ID: <20060125004551.GE10062@activestate.com> [bear wrote] > So far I've been reading the preliminary work that Bob has done and I've > been starting to wade thru the Apple dev docs but have yet to construct > a configure line that works :) > > Let me know what I can do to help. Pointers to how you guys are doing > the builds would help :) Currently (for the core python part at least) I'm mostly just doing: ./configure --enable-framework make make frameworkinstall I have a number of patches that I apply: http://downloads.activestate.com/ActivePython/etc/ActivePython-2.4.2.10-patches.zip Only some of those are relevant to the core Python build on OS X. For example, macosx_arch.patch. It is on my todo list to get my stuff building with the Python SVN head and start getting some of these patches in the core. Trent -- Trent Mick TrentM at ActiveState.com From trentm at ActiveState.com Wed Jan 25 01:49:22 2006 From: trentm at ActiveState.com (Trent Mick) Date: Tue, 24 Jan 2006 16:49:22 -0800 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.2.10 is now available In-Reply-To: References: Message-ID: <20060125004922.GF10062@activestate.com> [Kent Quirk wrote] > In the hopes of avoiding some redundant work...I happen to be sitting in > a workshop at the Apple campus as I speak, and one of the Apple > engineers here has just modified the Apple 2.3.5 build system to work > with 2.4.2, and to build a Universal version of Python 2.4.2. I haven't > run a full suite of tests, but it does appear to work. > > He has promised that he's going to post those changes to the > pythonmac.org wiki Real Soon Now, hopefully today. Good to hear. > There is a problem with it, which is that it builds into > /System/Library/Frameworks. I've sent him email asking for that to > change, but I don't know where that will end up. Probably a patch to python/Mac/OSX/Makefile changing the value of "prefix". Or, actually (slowly remembering), I believe you can set that with the "./configure --prefix" option. Trent -- Trent Mick TrentM at ActiveState.com From bear42 at code-bear.com Wed Jan 25 06:55:51 2006 From: bear42 at code-bear.com (bear) Date: Wed, 25 Jan 2006 00:55:51 -0500 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.2.10 is now available In-Reply-To: <20060125004922.GF10062@activestate.com> References: <20060125004922.GF10062@activestate.com> Message-ID: <43D712E7.4080601@code-bear.com> Trent Mick wrote: > [Kent Quirk wrote] > >> In the hopes of avoiding some redundant work...I happen to be sitting in >> a workshop at the Apple campus as I speak, and one of the Apple >> engineers here has just modified the Apple 2.3.5 build system to work >> with 2.4.2, and to build a Universal version of Python 2.4.2. I haven't >> run a full suite of tests, but it does appear to work. >> >> He has promised that he's going to post those changes to the >> pythonmac.org wiki Real Soon Now, hopefully today. >> > > Good to hear. > > *very* cool - please post a url as soon as you can ! >> There is a problem with it, which is that it builds int >> /System/Library/Frameworks. I've sent him email asking for that to >> change, but I don't know where that will end up. >> > > Probably a patch to python/Mac/OSX/Makefile changing the value of > "prefix". > > Or, actually (slowly remembering), I believe you can set that with the > "./configure --prefix" option. > > The --prefix option will tell configure where to place the files so you don't overwrite your current python. I am looking forward to seeing what the UB related options are - when I have tried the ones mentioned in the Tech Notes (CFLAGS= -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 and LDFLAGS= -isysroot /Developer/SDKs/MacOSX10.4u.sdk -syslibroot,/Developer/SDKs/MacOSX10.4u.sdk) I end up with odd ld errors. From kevino at theolliviers.com Wed Jan 25 18:13:45 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 25 Jan 2006 09:13:45 -0800 Subject: [Pythonmac-SIG] ANN: ActivePython 2.4.2.10 is now available In-Reply-To: <43D712E7.4080601@code-bear.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> Message-ID: <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> Hi Bear, On Jan 24, 2006, at 9:55 PM, bear wrote: [snip] > The --prefix option will tell configure where to place the files so > you > don't overwrite your current python. > > I am looking forward to seeing what the UB related options are - > when I > have tried the ones mentioned in the Tech Notes (CFLAGS= -isysroot > /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386 and LDFLAGS= > -isysroot /Developer/SDKs/MacOSX10.4u.sdk > -syslibroot,/Developer/SDKs/MacOSX10.4u.sdk) I end up with odd ld > errors. Take out the -syslibroot part (which is only needed for libtool, IIUC) and make sure the "-arch ppc -arch i386" bit is in LDFLAGS as well. That's how I got wxWidgets building Universal binaries. :-) Thanks, Kevin From bear42 at code-bear.com Wed Jan 25 20:02:37 2006 From: bear42 at code-bear.com (bear) Date: Wed, 25 Jan 2006 14:02:37 -0500 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> Message-ID: <43D7CB4D.1010903@code-bear.com> Kevin Ollivier wrote: > Take out the -syslibroot part (which is only needed for libtool, IIUC) > and make sure the "-arch ppc -arch i386" bit is in LDFLAGS as well. > That's how I got wxWidgets building Universal binaries. :-) > I had *just* read your wx-dev post and was going to ask about the particulars. When I try this: CFLAGS=' -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386' LDFLAGS=' -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386' I get this: checking for C compiler default output filename... configure: error: C compiler cannot create executables and if remove the -sysroot part from LDFLAGS, configure runs but then I get quite a few errors during the final parts of make: /usr/bin/ld: warning Parser/acceler.o cputype (7, architecture i386) does not match cputype (18) for specified -arch flag: ppc (file not loaded) I appreciate any schooling you can offer me :) - bear From kevino at theolliviers.com Wed Jan 25 22:23:15 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 25 Jan 2006 13:23:15 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <43D7CB4D.1010903@code-bear.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> Message-ID: <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> Hi, On Jan 25, 2006, at 11:02 AM, bear wrote: > > > Kevin Ollivier wrote: >> Take out the -syslibroot part (which is only needed for libtool, >> IIUC) >> and make sure the "-arch ppc -arch i386" bit is in LDFLAGS as well. >> That's how I got wxWidgets building Universal binaries. :-) >> > I had *just* read your wx-dev post and was going to ask about the > particulars. > > When I try this: > > CFLAGS=' -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch > i386' > LDFLAGS=' -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch > i386' > > I get this: > checking for C compiler default output filename... configure: > error: > C compiler cannot create executables How exactly are you doing this? Are you passing these flags into configure, or editing the configure script? I'm seeing that it does matter where in the configure script the options are added. From my tests so far, the test 'failures' in the configure script are incorrect - it seems these options just trip up the tests somehow. (I think, for example, the multi-architecture flags don't work with flags for a "dry run" compile from what I've read) I've found that for wx, adding the options after these tests worked correctly. > and if remove the -sysroot part from LDFLAGS, configure runs but > then I > get quite a few errors during the final parts of make: > /usr/bin/ld: warning Parser/acceler.o cputype (7, architecture > i386) > does not match cputype (18) for specified -arch flag: ppc (file not > loaded) I've found that without the -isysroot, it creates/links "single architecture" objects even when multiple -arch flags are specified. ;-/ So you'll need to be able to specify those flags but after the basic tests are run. At least, that's how I was able to succeed with wx. Hope this helps! Kevin > I appreciate any schooling you can offer me :) > > - bear > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bear42 at code-bear.com Wed Jan 25 23:59:33 2006 From: bear42 at code-bear.com (bear) Date: Wed, 25 Jan 2006 17:59:33 -0500 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> Message-ID: <43D802D5.10709@code-bear.com> Kevin Ollivier wrote: > How exactly are you doing this? Are you passing these flags into > configure, or editing the configure script? I'm seeing that it does > matter where in the configure script the options are added. From my > tests so far, the test 'failures' in the configure script are > incorrect - it seems these options just trip up the tests somehow. (I > think, for example, the multi-architecture flags don't work with flags > for a "dry run" compile from what I've read) I've found that for wx, > adding the options after these tests worked correctly. That's the difference then - I'm setting the env vars and letting configure do it's thing. I don't control the configure script and was trying to see if I could build with minimal patching. > I've found that without the -isysroot, it creates/links "single > architecture" objects even when multiple -arch flags are specified. > ;-/ So you'll need to be able to specify those flags but after the > basic tests are run. At least, that's how I was able to succeed with wx. That does help a lot - let me first hack the script and then pass upstream any changes I've had to make. From kevino at theolliviers.com Thu Jan 26 00:10:12 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Wed, 25 Jan 2006 15:10:12 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <43D802D5.10709@code-bear.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> Message-ID: <3ED16B68-D95B-48BF-A34A-1CD312A2BB25@theolliviers.com> Hi, On Jan 25, 2006, at 2:59 PM, bear wrote: > Kevin Ollivier wrote: >> How exactly are you doing this? Are you passing these flags into >> configure, or editing the configure script? I'm seeing that it >> does matter where in the configure script the options are added. >> From my tests so far, the test 'failures' in the configure script >> are incorrect - it seems these options just trip up the tests >> somehow. (I think, for example, the multi-architecture flags don't >> work with flags for a "dry run" compile from what I've read) I've >> found that for wx, adding the options after these tests worked >> correctly. > That's the difference then - I'm setting the env vars and letting > configure do it's thing. I don't control the configure script and > was trying to see if I could build with minimal patching. Oh, BTW, I forgot to mention this but Apple's changes to build Python 2.3 Universal are available from here: http://www.opensource.apple.com/darwinsource/tarballs/other/ python-16.tar.gz The fixes dir has all the changes they made to the source files. Thanks, Kevin >> I've found that without the -isysroot, it creates/links "single >> architecture" objects even when multiple -arch flags are >> specified. ;-/ So you'll need to be able to specify those flags >> but after the basic tests are run. At least, that's how I was able >> to succeed with wx. > > That does help a lot - let me first hack the script and then pass > upstream any changes I've had to make. > From bob at redivi.com Thu Jan 26 00:23:01 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 25 Jan 2006 15:23:01 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <43D802D5.10709@code-bear.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> Message-ID: On Jan 25, 2006, at 2:59 PM, bear wrote: > Kevin Ollivier wrote: >> How exactly are you doing this? Are you passing these flags into >> configure, or editing the configure script? I'm seeing that it does >> matter where in the configure script the options are added. From my >> tests so far, the test 'failures' in the configure script are >> incorrect - it seems these options just trip up the tests somehow. (I >> think, for example, the multi-architecture flags don't work with >> flags >> for a "dry run" compile from what I've read) I've found that for wx, >> adding the options after these tests worked correctly. > That's the difference then - I'm setting the env vars and letting > configure do it's thing. I don't control the configure script and was > trying to see if I could build with minimal patching. > >> I've found that without the -isysroot, it creates/links "single >> architecture" objects even when multiple -arch flags are specified. >> ;-/ So you'll need to be able to specify those flags but after the >> basic tests are run. At least, that's how I was able to succeed >> with wx. > > That does help a lot - let me first hack the script and then pass > upstream any changes I've had to make. One thing to note is that you can probably build with minimal patching (via the universal SDK), but the result will only run on Mac OS X 10.4 and later. It requires major patching in order to create a Python binary that is Mac OS X 10.3 or 10.2 compatible. Additionally, you'll end up with a Python that has these SDK-build flags baked into its Makefile, so it's not ideally distributable -- because building extensions would require having the SDK(s) installed... but perhaps that's not a terrible idea, to have a separate distribution of Python designed for building redistributable applications. It would certainly be easier than trying to make distutils and autoconf smart. -bob From bear42 at code-bear.com Thu Jan 26 00:23:21 2006 From: bear42 at code-bear.com (bear) Date: Wed, 25 Jan 2006 18:23:21 -0500 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <3ED16B68-D95B-48BF-A34A-1CD312A2BB25@theolliviers.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <3ED16B68-D95B-48BF-A34A-1CD312A2BB25@theolliviers.com> Message-ID: <43D80869.9040701@code-bear.com> Kevin Ollivier wrote: > Oh, BTW, I forgot to mention this but Apple's changes to build Python > 2.3 Universal are available from here: > > http://www.opensource.apple.com/darwinsource/tarballs/other/python-16.tar.gz > > > The fixes dir has all the changes they made to the source files. sweet! -- bear From bear42 at code-bear.com Thu Jan 26 00:47:05 2006 From: bear42 at code-bear.com (bear) Date: Wed, 25 Jan 2006 18:47:05 -0500 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> Message-ID: <43D80DF9.7000707@code-bear.com> Bob Ippolito wrote: > One thing to note is that you can probably build with minimal patching > (via the universal SDK), but the result will only run on Mac OS X 10.4 > and later. It requires major patching in order to create a Python > binary that is Mac OS X 10.3 or 10.2 compatible. My goal is first to get Python building on 10.4 (i386 arch) and then to worry about multi-arch binaries. Once that happens I can start to do the steps to build multi-arch, but that is a secondary goal because I think we could live with different downloads for ppc and i386 for the short term. > Additionally, you'll end up with a Python that has these SDK-build > flags baked into its Makefile, so it's not ideally distributable -- > because building extensions would require having the SDK(s) > installed... but perhaps that's not a terrible idea, to have a > separate distribution of Python designed for building redistributable > applications. It would certainly be easier than trying to make > distutils and autoconf smart. If the binaries I build are useful I can make them available if that helps. -- bear From skip at pobox.com Thu Jan 26 04:13:45 2006 From: skip at pobox.com (skip at pobox.com) Date: Wed, 25 Jan 2006 21:13:45 -0600 Subject: [Pythonmac-SIG] Mac Intel Python status? In-Reply-To: References: Message-ID: <17368.15977.919794.784108@montanaro.dyndns.org> Kent> What's the current status of any semi-official build of Python on Kent> Intel? We actually need to build it without readline support, Kent> haven't been able to figure out how (configure --without-readline Kent> doesn't seem to do it). It builds if we download Gnu readline and Kent> install it, but without that the build fails. Apparently the readline library in MacOSX isn't really readline. It's a renamed libedit. Not having encountered this deception before, Python's build procedure doesn't know to test the capability of readline. I suggest you just comment out the readline checks in setup.py. Skip From ronaldoussoren at mac.com Thu Jan 26 09:48:48 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 26 Jan 2006 09:48:48 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <43D80DF9.7000707@code-bear.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> Message-ID: On 26-jan-2006, at 0:47, bear wrote: > Bob Ippolito wrote: >> One thing to note is that you can probably build with minimal >> patching >> (via the universal SDK), but the result will only run on Mac OS X >> 10.4 >> and later. It requires major patching in order to create a Python >> binary that is Mac OS X 10.3 or 10.2 compatible. > > My goal is first to get Python building on 10.4 (i386 arch) and > then to > worry about multi-arch binaries. That part is easy enough. If you want a framework build you'll have to patch Makefile.pre.in because it contains a hardcoded '-arch ppc' in the section that builds that actual framework. Otherwise it should just build (assuming you have an intel mac of course, cross-building from PPC to Intel will be hard because the build process assumes you'll do a native build). > > Once that happens I can start to do the steps to build multi-arch, but > that is a secondary goal because I think we could live with different > downloads for ppc and i386 for the short term. > >> Additionally, you'll end up with a Python that has these SDK-build >> flags baked into its Makefile, so it's not ideally distributable -- >> because building extensions would require having the SDK(s) >> installed... but perhaps that's not a terrible idea, to have a >> separate distribution of Python designed for building redistributable >> applications. It would certainly be easier than trying to make >> distutils and autoconf smart. I'm (very slowly) playing around with adding '-arch ppc -arch i386' to the build flags and building on an intel host. That way you won't have to use SDKs, which makes it less likely that configure picks up other information than the actual compile (not that there should be any differences if you use the 10.4u SDK). With some effort it should be possible to build a version of python that will run on 10.3 as well. As far as python is concerned the differences between 10.3 and 10.4 seem to be fairly small. The reason I'd like to do this instead of merging a build-on-10.3 PPC version and a build-on-10.4 intel version is that the latter would contain small incompatibilities between the intel and ppc version (some scripts would work on intel but not on ppc). Ronald From piet at cs.uu.nl Thu Jan 26 13:36:07 2006 From: piet at cs.uu.nl (Piet van Oostrum) Date: Thu, 26 Jan 2006 13:36:07 +0100 Subject: [Pythonmac-SIG] Mac Intel Python status? In-Reply-To: <17368.15977.919794.784108@montanaro.dyndns.org> (skip@pobox.com's message of "Wed, 25 Jan 2006 21:13:45 -0600") References: <17368.15977.919794.784108@montanaro.dyndns.org> Message-ID: >>>>> skip at pobox.com (s) wrote: >s> Apparently the readline library in MacOSX isn't really readline. It's a >s> renamed libedit. Not having encountered this deception before, Python's >s> build procedure doesn't know to test the capability of readline. I suggest >s> you just comment out the readline checks in setup.py. libedit (editline) is a different library with a similar function as readline, but not compatible with it. It has a BSD license. It is often used instead of readline for non-GPL software. -- Piet van Oostrum URL: http://www.cs.uu.nl/~piet [PGP 8DAE142BE17999C4] Private email: piet at vanoostrum.org From mjb at uma.pt Thu Jan 26 17:54:02 2006 From: mjb at uma.pt (Michael Barber) Date: Thu, 26 Jan 2006 16:54:02 +0000 Subject: [Pythonmac-SIG] Experiences with 64 bit on PowerMac G5s? Message-ID: <34950AC4-C90A-4ED8-A2F6-53B8C29DFA5A@uma.pt> I have been using Python for scientific computing on a variety of systems, Mac and otherwise, with a recent focus on properties of interaction networks. Until now, I have not needed to use more than roughly 1 GB of RAM at a time. Thanks to some fairly straightforward scaling properties, it is clear that the next version of the interaction networks we're exploring will require more than 2GB of RAM without some serious reworking of the programs. The simplest and most cost-effective solution appears to be just to buy a 64 bit computer and load it up with 8 GB or so of RAM, and so far a PowerMac G5 looks like a good solution. However, while I have a lot of experience with Python on Macs, I've never used Python on one of the G5s (or any other 64 bit machine), so would like to hear about others' experiences with such a setup. The impression I have is that it should be completely straightforward; is that so? Are there any issues with compiling and running a 64-bit Python on a G5 that I should be aware of? How about with Numeric or (better) numarray? -- Michael From cookedm at physics.mcmaster.ca Thu Jan 26 22:56:36 2006 From: cookedm at physics.mcmaster.ca (David M. Cooke) Date: Thu, 26 Jan 2006 16:56:36 -0500 Subject: [Pythonmac-SIG] Experiences with 64 bit on PowerMac G5s? In-Reply-To: <34950AC4-C90A-4ED8-A2F6-53B8C29DFA5A@uma.pt> (Michael Barber's message of "Thu, 26 Jan 2006 16:54:02 +0000") References: <34950AC4-C90A-4ED8-A2F6-53B8C29DFA5A@uma.pt> Message-ID: Michael Barber writes: > I have been using Python for scientific computing on a variety of > systems, Mac and otherwise, with a recent focus on properties of > interaction networks. Until now, I have not needed to use more than > roughly 1 GB of RAM at a time. Thanks to some fairly straightforward > scaling properties, it is clear that the next version of the > interaction networks we're exploring will require more than 2GB of > RAM without some serious reworking of the programs. > > The simplest and most cost-effective solution appears to be just to > buy a 64 bit computer and load it up with 8 GB or so of RAM, and so > far a PowerMac G5 looks like a good solution. However, while I have a > lot of experience with Python on Macs, I've never used Python on one > of the G5s (or any other 64 bit machine), so would like to hear about > others' experiences with such a setup. The impression I have is that > it should be completely straightforward; is that so? Are there any > issues with compiling and running a 64-bit Python on a G5 that I > should be aware of? How about with Numeric or (better) numarray? I don't know specifically about the G5, but Numeric, numarray, and numpy are routinely compiled and run on 64-bit Athlon machines, so a lot of the bugs and such have already been shaken out. If possible, you should move from Numeric to numpy; one of the goals for numpy was better 64-bit handling. But numarray may still be better for extremely large arrays; haven't checked recently. -- |>|\/|< /--------------------------------------------------------------------------\ |David M. Cooke http://arbutus.physics.mcmaster.ca/dmc/ |cookedm at physics.mcmaster.ca From robert.kern at gmail.com Fri Jan 27 00:24:32 2006 From: robert.kern at gmail.com (Robert Kern) Date: Thu, 26 Jan 2006 17:24:32 -0600 Subject: [Pythonmac-SIG] Experiences with 64 bit on PowerMac G5s? In-Reply-To: References: <34950AC4-C90A-4ED8-A2F6-53B8C29DFA5A@uma.pt> Message-ID: <43D95A30.8060403@gmail.com> David M. Cooke wrote: > I don't know specifically about the G5, but Numeric, numarray, and > numpy are routinely compiled and run on 64-bit Athlon machines, so a > lot of the bugs and such have already been shaken out. > > If possible, you should move from Numeric to numpy; one of the goals > for numpy was better 64-bit handling. But numarray may still be better > for extremely large arrays; haven't checked recently. Well, numarray won't be updating much any more, and almost certainly won't be addressing the fundamental problems with >32-bit arrays like numpy has. So go for numpy. http://numeric.scipy.org/ That said, I don't think many people have actually been using >32-bit arrays with numpy, yet, so there are probably still some issues to be worked out. Disclaimer: I am a numpy developer. -- Robert Kern robert.kern at gmail.com "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter From delza at livingcode.org Fri Jan 27 01:22:20 2006 From: delza at livingcode.org (Dethe Elza) Date: Thu, 26 Jan 2006 16:22:20 -0800 Subject: [Pythonmac-SIG] Crashing screensaver engine Message-ID: Hi folks, I'm trying to write an example screensaver in PyObjC which is a bit more complex than the existing example. One of the things I've added is a sheet to configure the screensaver. I'm doing something wrong there (was doing more things wrong, but I found some of them) and the screensaver engine is crashing. There don't appear to be any harmful side effects from this--my configuration changes are persisted, and the screensaver runs fine, but I want to fix this before I post the code. The code itself is all in one file (including setup script) here: http://livingcode.org/temp/pastels.txt (rename to pastels.py and run python pastels.py py2app to build) and the latest crash log is here: http://livingcode.org/temp/screensaver_crash.log Any hints as to what I'm doing wrong would be very appreciated. Thanks! --Dethe PowerPoint can make almost anything appear good and look professional. Quite frankly, I find that a little bit frightening. --David Byrne From kevino at theolliviers.com Fri Jan 27 03:28:01 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Thu, 26 Jan 2006 18:28:01 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> Message-ID: Hi Ronald, On Jan 26, 2006, at 12:48 AM, Ronald Oussoren wrote: [snip] > I'm (very slowly) playing around with adding '-arch ppc -arch i386' > to the build flags and building on an intel host. That way you won't > have to use SDKs, which makes it less likely that configure picks up > other information than the actual compile (not that there should be > any differences if you use the 10.4u SDK). > > With some effort it should be possible to build a version of python > that will run on 10.3 as well. As far as python is concerned the > differences between 10.3 and 10.4 seem to be fairly small. The reason > I'd like to do this instead of merging a build-on-10.3 PPC version > and a build-on-10.4 intel version is that the latter would contain > small incompatibilities between the intel and ppc version (some > scripts would work on intel but not on ppc). IMHO, what would be cool is to allow the user to pass the SDK in as some sort of configure flag or maybe a shell variable, something like: ./configure MACOSX_SDK=/my/path/to/SDK This, along with the addition of the -arch i386 -arch ppc flags would be enough to enable someone to write a script to create a Panther- compatible Universal build. Which I'm pretty sure someone will do sooner or later. :-) Thanks, Kevin From bob at redivi.com Fri Jan 27 04:02:53 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 Jan 2006 19:02:53 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> Message-ID: On Jan 26, 2006, at 6:28 PM, Kevin Ollivier wrote: > On Jan 26, 2006, at 12:48 AM, Ronald Oussoren wrote: > > [snip] > >> I'm (very slowly) playing around with adding '-arch ppc -arch i386' >> to the build flags and building on an intel host. That way you won't >> have to use SDKs, which makes it less likely that configure picks up >> other information than the actual compile (not that there should be >> any differences if you use the 10.4u SDK). >> >> With some effort it should be possible to build a version of python >> that will run on 10.3 as well. As far as python is concerned the >> differences between 10.3 and 10.4 seem to be fairly small. The reason >> I'd like to do this instead of merging a build-on-10.3 PPC version >> and a build-on-10.4 intel version is that the latter would contain >> small incompatibilities between the intel and ppc version (some >> scripts would work on intel but not on ppc). > > IMHO, what would be cool is to allow the user to pass the SDK in as > some sort of configure flag or maybe a shell variable, something like: > > ./configure MACOSX_SDK=/my/path/to/SDK > > This, along with the addition of the -arch i386 -arch ppc flags would > be enough to enable someone to write a script to create a Panther- > compatible Universal build. Which I'm pretty sure someone will do > sooner or later. :-) No, it wouldn't actually. The 10.3 SDK is ppc only, and a Panther- compatible build (well, something compatible with 10.3.8 and below) must use GCC 3.3, but an x86 compatible build must use GCC 4. In other words, something Panther compatible needs to use different compilers with totally different options for x86 and PPC. It's not going to be easy, distutils doesn't come anywhere near close to supporting anything like that and neither does autoconf. I think the only approach that doesn't require hacking a significant amount of Python's build process and distutils is to have two Python installations, one x86 only and one PPC only. For distribution, you would cook up some way to lipo it all together. -bob From bear42 at code-bear.com Fri Jan 27 04:22:57 2006 From: bear42 at code-bear.com (bear) Date: Thu, 26 Jan 2006 22:22:57 -0500 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> Message-ID: <43D99211.30504@code-bear.com> Ronald Oussoren wrote: > That part is easy enough. If you want a framework build you'll have to > patch Makefile.pre.in because it contains a hardcoded '-arch ppc' in > the section that builds that actual framework. Otherwise it should > just build (assuming you have an intel mac of course, cross-building > from PPC to Intel will be hard because the build process assumes > you'll do a native build). ok, I found the relevant part in configure (and cofigure.in) that was putting -arch_only ppc into the Makefile and I've re-run configure and it seems happy - heck, even the compiling ran error free. But when it got to the link part - I get the following error: ...... ranlib libpython2.4.a /usr/bin/install -c -d -m 755 Python.framework/Versions/2.4 libtool -o Python.framework/Versions/2.4/Python -dynamic libpython2.4.a \ -lSystem -lSystemStubs -install_name /Users/bear/projects/osaf/chandler/trunk/external/release/Library/Frameworks/Python.framework/Versions/2.4/Python -compatibility_version 2.4 -current_version 2.4 ld64 failed: in libpython2.4.a(__.SYMDEF), not a valid ppc64 mach-o file libtool: internal link edit command failed make: *** [Python.framework/Versions/2.4/Python] Error 1 I must be missing something very basic. The following is a small script I've been using to test with: export SDK=/Developer/SDKs/MacOSX10.4u.sdk export TARGET_ARCH="" #" -arch i386 -arch ppc" export LDFLAGS="-L${PREFIX}/lib -isysroot ${SDK} ${TARGET_ARCH}" export PREFIX=/Users/bear/projects/release cd /Users/bear/projects/Python-2.4.2/build_release MACOSX_DEPLOYMENT_TARGET=10.4 \ LDFLAGS=${LDFLAGS} \ CPPFLAGS="-I${PREFIX}/include ${CPPFLAGS}" \ ../configure --prefix=${PREFIX} \ --enable-framework=${PREFIX}/Library/Frameworks \ --with-readline=${PREFIX}/lib \ --disable-ipv6 \ --disable-dependency-tracking MACOSX_DEPLOYMENT_TARGET=10.4 make frameworkinstallframework any clues or thoughts appreciated -- bear From kevino at theolliviers.com Fri Jan 27 07:22:34 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Thu, 26 Jan 2006 22:22:34 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <43D99211.30504@code-bear.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> Message-ID: Hi, On Jan 26, 2006, at 7:22 PM, bear wrote: > Ronald Oussoren wrote: >> That part is easy enough. If you want a framework build you'll >> have to >> patch Makefile.pre.in because it contains a hardcoded '-arch ppc' in >> the section that builds that actual framework. Otherwise it should >> just build (assuming you have an intel mac of course, cross-building >> from PPC to Intel will be hard because the build process assumes >> you'll do a native build). > ok, I found the relevant part in configure (and cofigure.in) that was > putting -arch_only ppc into the Makefile and I've re-run configure and > it seems happy - heck, even the compiling ran error free. > > But when it got to the link part - I get the following error: > > ...... > ranlib libpython2.4.a > /usr/bin/install -c -d -m 755 Python.framework/Versions/2.4 > libtool -o Python.framework/Versions/2.4/Python -dynamic > libpython2.4.a \ > -lSystem -lSystemStubs -install_name > /Users/bear/projects/osaf/chandler/trunk/external/release/Library/ > Frameworks/Python.framework/Versions/2.4/Python > -compatibility_version 2.4 -current_version 2.4 > ld64 failed: in libpython2.4.a(__.SYMDEF), not a valid ppc64 mach-o > file > libtool: internal link edit command failed > make: *** [Python.framework/Versions/2.4/Python] Error 1 > > I must be missing something very basic. The following is a small > script > I've been using to test with: > > export SDK=/Developer/SDKs/MacOSX10.4u.sdk > export TARGET_ARCH="" #" -arch i386 -arch ppc" > export LDFLAGS="-L${PREFIX}/lib -isysroot ${SDK} ${TARGET_ARCH}" > export PREFIX=/Users/bear/projects/release I'm not certain if this is the main issue here or not, but if you are on an Intel Mac, don't change LDFLAGS at all - those changes are only needed for building Universal. Basically, as Ronald said, after removing the "-arch_only ppc" line you should be able to build as usual. Kevin From kevino at theolliviers.com Fri Jan 27 07:39:32 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Thu, 26 Jan 2006 22:39:32 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> Message-ID: <09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com> Hi Bob, On Jan 26, 2006, at 7:02 PM, Bob Ippolito wrote: [snip] >> IMHO, what would be cool is to allow the user to pass the SDK in as >> some sort of configure flag or maybe a shell variable, something >> like: >> >> ./configure MACOSX_SDK=/my/path/to/SDK >> >> This, along with the addition of the -arch i386 -arch ppc flags would >> be enough to enable someone to write a script to create a Panther- >> compatible Universal build. Which I'm pretty sure someone will do >> sooner or later. :-) > > No, it wouldn't actually. The 10.3 SDK is ppc only, and a Panther- > compatible build (well, something compatible with 10.3.8 and below) > must use GCC 3.3, but an x86 compatible build must use GCC 4. > > In other words, something Panther compatible needs to use different > compilers with totally different options for x86 and PPC. It's not > going to be easy, distutils doesn't come anywhere near close to > supporting anything like that and neither does autoconf. Sorry, I wasn't really thinking about extensions. By Panther I did mean building against the 10.3.9 SDK, which would give the desired results for the Python binary itself, but as you said extending that to correctly build extensions that did the same thing would be a royal PITA. > I think the only approach that doesn't require hacking a > significant amount of Python's build process and distutils is to > have two Python installations, one x86 only and one PPC only. For > distribution, you would cook up some way to lipo it all together. I can see how the issues with the strategy I outlined would be significant, but I don't see how Universal support on Tiger would be similarly difficult. Apple's Python 2.3.5 already is Universal, and I'm unaware of any issues with it (except that it doesn't build Universal extensions ;). The changes they made to the build process seemed to be fairly minimal. As far as distutils/working with extensions, I admit I'm not very familiar with that. I did notice when compiling wxPython though that there weren't any distutils flags passed to gcc that would conflict with the building of Universal binaries. The main question in my mind would be whether or not the built Universal extension libraries could be loaded by Python's dynamic library loader. If they can be loaded, and we could add the flags to distutils' default compiler/linker flags, what other major issues would need to be overcome? Thanks, Kevin > -bob > From bob at redivi.com Fri Jan 27 07:44:34 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 Jan 2006 22:44:34 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> Message-ID: <0C32C3CA-AB49-4550-ADC3-CF7A798384A3@redivi.com> On Jan 26, 2006, at 7:02 PM, Bob Ippolito wrote: > > On Jan 26, 2006, at 6:28 PM, Kevin Ollivier wrote: > >> On Jan 26, 2006, at 12:48 AM, Ronald Oussoren wrote: >> >> [snip] >> >>> I'm (very slowly) playing around with adding '-arch ppc -arch i386' >>> to the build flags and building on an intel host. That way you won't >>> have to use SDKs, which makes it less likely that configure picks up >>> other information than the actual compile (not that there should be >>> any differences if you use the 10.4u SDK). >>> >>> With some effort it should be possible to build a version of python >>> that will run on 10.3 as well. As far as python is concerned the >>> differences between 10.3 and 10.4 seem to be fairly small. The >>> reason >>> I'd like to do this instead of merging a build-on-10.3 PPC version >>> and a build-on-10.4 intel version is that the latter would contain >>> small incompatibilities between the intel and ppc version (some >>> scripts would work on intel but not on ppc). >> >> IMHO, what would be cool is to allow the user to pass the SDK in as >> some sort of configure flag or maybe a shell variable, something >> like: >> >> ./configure MACOSX_SDK=/my/path/to/SDK >> >> This, along with the addition of the -arch i386 -arch ppc flags would >> be enough to enable someone to write a script to create a Panther- >> compatible Universal build. Which I'm pretty sure someone will do >> sooner or later. :-) > > No, it wouldn't actually. The 10.3 SDK is ppc only, and a Panther- > compatible build (well, something compatible with 10.3.8 and below) > must use GCC 3.3, but an x86 compatible build must use GCC 4. > > In other words, something Panther compatible needs to use different > compilers with totally different options for x86 and PPC. It's not > going to be easy, distutils doesn't come anywhere near close to > supporting anything like that and neither does autoconf. > > I think the only approach that doesn't require hacking a significant > amount of Python's build process and distutils is to have two Python > installations, one x86 only and one PPC only. For distribution, you > would cook up some way to lipo it all together. Another approach would be to write a little front-end for GCC that knows how to mangle the arguments properly so that it ends up running GCC 3.3 against the 10.3 SDK then GCC 4 against the universal SDK and lipo the object files or output library or bundle together. -bob From bob at redivi.com Fri Jan 27 07:55:44 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 26 Jan 2006 22:55:44 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com> Message-ID: <5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com> On Jan 26, 2006, at 10:39 PM, Kevin Ollivier wrote: > On Jan 26, 2006, at 7:02 PM, Bob Ippolito wrote: > > [snip] > >>> IMHO, what would be cool is to allow the user to pass the SDK in as >>> some sort of configure flag or maybe a shell variable, something >>> like: >>> >>> ./configure MACOSX_SDK=/my/path/to/SDK >>> >>> This, along with the addition of the -arch i386 -arch ppc flags >>> would >>> be enough to enable someone to write a script to create a Panther- >>> compatible Universal build. Which I'm pretty sure someone will do >>> sooner or later. :-) >> >> No, it wouldn't actually. The 10.3 SDK is ppc only, and a Panther- >> compatible build (well, something compatible with 10.3.8 and >> below) must use GCC 3.3, but an x86 compatible build must use GCC 4. >> >> In other words, something Panther compatible needs to use >> different compilers with totally different options for x86 and >> PPC. It's not going to be easy, distutils doesn't come anywhere >> near close to supporting anything like that and neither does >> autoconf. > > Sorry, I wasn't really thinking about extensions. By Panther I did > mean building against the 10.3.9 SDK, which would give the desired > results for the Python binary itself, but as you said extending > that to correctly build extensions that did the same thing would be > a royal PITA. You still need to build against two different SDKs, which can't be done with just compiler flags. You have to do two separate compiles, and then lipo it together. At that point you might as well use different compilers and target older versions of OS X. The other thing is that Python's build probably detects a few things at runtime, and at runtime it's seeing 10.4, so it might not actually work on the target version of OS X. Ideally all that stuff would be pushed to runtime checks, so that it could choose a different code path based upon which APIs are available... but first you have to isolate the instances where that happens. >> I think the only approach that doesn't require hacking a >> significant amount of Python's build process and distutils is to >> have two Python installations, one x86 only and one PPC only. For >> distribution, you would cook up some way to lipo it all together. > > I can see how the issues with the strategy I outlined would be > significant, but I don't see how Universal support on Tiger would > be similarly difficult. Apple's Python 2.3.5 already is Universal, > and I'm unaware of any issues with it (except that it doesn't build > Universal extensions ;). The changes they made to the build process > seemed to be fairly minimal. Yeah, a 10.4+ universal build wouldn't be too big of a deal because you can do that with one invocation of GCC and one set of flags. > As far as distutils/working with extensions, I admit I'm not very > familiar with that. I did notice when compiling wxPython though > that there weren't any distutils flags passed to gcc that would > conflict with the building of Universal binaries. The main question > in my mind would be whether or not the built Universal extension > libraries could be loaded by Python's dynamic library loader. If > they can be loaded, and we could add the flags to distutils' > default compiler/linker flags, what other major issues would need > to be overcome? Some extensions aren't going to build cleanly universal, and most users probably aren't going to have all the SDKs installed so if it shipped with universal flags then it wouldn't be able to build extensions. -bob From kevino at theolliviers.com Fri Jan 27 08:46:07 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Thu, 26 Jan 2006 23:46:07 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com> <5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com> Message-ID: Hi Bob, On Jan 26, 2006, at 10:55 PM, Bob Ippolito wrote: [snip] >> Sorry, I wasn't really thinking about extensions. By Panther I did >> mean building against the 10.3.9 SDK, which would give the desired >> results for the Python binary itself, but as you said extending >> that to correctly build extensions that did the same thing would >> be a royal PITA. > > You still need to build against two different SDKs, which can't be > done with just compiler flags. You have to do two separate > compiles, and then lipo it together. At that point you might as > well use different compilers and target older versions of OS X. Yes, this was what I meant in my previous email about letting the SDK get specified at configure time. I was thinking to have bash script that automates the various steps. I guess you could put it into the configure script, but that does sound to me to be pretty painful. > The other thing is that Python's build probably detects a few > things at runtime, and at runtime it's seeing 10.4, so it might not > actually work on the target version of OS X. Yeah, if this is the case it'd be a real mess. ;-/ > Ideally all that stuff would be pushed to runtime checks, so that > it could choose a different code path based upon which APIs are > available... but first you have to isolate the instances where that > happens. > >>> I think the only approach that doesn't require hacking a >>> significant amount of Python's build process and distutils is to >>> have two Python installations, one x86 only and one PPC only. >>> For distribution, you would cook up some way to lipo it all >>> together. >> >> I can see how the issues with the strategy I outlined would be >> significant, but I don't see how Universal support on Tiger would >> be similarly difficult. Apple's Python 2.3.5 already is Universal, >> and I'm unaware of any issues with it (except that it doesn't >> build Universal extensions ;). The changes they made to the build >> process seemed to be fairly minimal. > > Yeah, a 10.4+ universal build wouldn't be too big of a deal because > you can do that with one invocation of GCC and one set of flags. > >> As far as distutils/working with extensions, I admit I'm not very >> familiar with that. I did notice when compiling wxPython though >> that there weren't any distutils flags passed to gcc that would >> conflict with the building of Universal binaries. The main >> question in my mind would be whether or not the built Universal >> extension libraries could be loaded by Python's dynamic library >> loader. If they can be loaded, and we could add the flags to >> distutils' default compiler/linker flags, what other major issues >> would need to be overcome? > > Some extensions aren't going to build cleanly universal, and most > users probably aren't going to have all the SDKs installed so if it > shipped with universal flags then it wouldn't be able to build > extensions. Unless we had distutils check for the existence of the Universal SDK before setting the flags, or probably more accurately, remove them if the SDK isn't available. Then perhaps add a distutils 'flag' to manually turn off Universal building for extensions that can't be fixed. This might be a bit of a hack, but I don't imagine it would be too painful. The question is how many extensions would have troubles... But I guess the only way we'll know is to test the waters. In any case, even if it wouldn't be reasonable to make a Universal build the "official" build, it would be very useful to people packaging apps, even if it were Tiger+ only. As far as the SDK dependency issue, IMHO, not everyone would need to build Universal - the key would be for distributors/packages to make Universal binaries, and I think it would be reasonable for us to tell them "have the 10.4u SDK and DevTools installed". (And maybe the Panther/Jaguar SDK assuming we could sort the issues you mentioned above out...) Again, assuming a Universal build does make a sensible default. Thanks, Kevin > -bob > From kevino at theolliviers.com Fri Jan 27 08:49:27 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Thu, 26 Jan 2006 23:49:27 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <0C32C3CA-AB49-4550-ADC3-CF7A798384A3@redivi.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <0C32C3CA-AB49-4550-ADC3-CF7A798384A3@redivi.com> Message-ID: <117493EB-A1C2-4A32-9D5C-7F7B2FF4EF8A@theolliviers.com> Hi Bob, On Jan 26, 2006, at 10:44 PM, Bob Ippolito wrote: [snip] > Another approach would be to write a little front-end for GCC that > knows how to mangle the arguments properly so that it ends up > running GCC 3.3 against the 10.3 SDK then GCC 4 against the > universal SDK and lipo the object files or output library or bundle > together. This would be a pretty slick solution, not to mention be useful outside of Python. :-) Thanks, Kevin > -bob > From ronaldoussoren at mac.com Fri Jan 27 09:06:19 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 27 Jan 2006 09:06:19 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> Message-ID: On 27-jan-2006, at 4:02, Bob Ippolito wrote: > > On Jan 26, 2006, at 6:28 PM, Kevin Ollivier wrote: > >> On Jan 26, 2006, at 12:48 AM, Ronald Oussoren wrote: >> >> [snip] >> >>> I'm (very slowly) playing around with adding '-arch ppc -arch i386' >>> to the build flags and building on an intel host. That way you won't >>> have to use SDKs, which makes it less likely that configure picks up >>> other information than the actual compile (not that there should be >>> any differences if you use the 10.4u SDK). >>> >>> With some effort it should be possible to build a version of python >>> that will run on 10.3 as well. As far as python is concerned the >>> differences between 10.3 and 10.4 seem to be fairly small. The >>> reason >>> I'd like to do this instead of merging a build-on-10.3 PPC version >>> and a build-on-10.4 intel version is that the latter would contain >>> small incompatibilities between the intel and ppc version (some >>> scripts would work on intel but not on ppc). >> >> IMHO, what would be cool is to allow the user to pass the SDK in as >> some sort of configure flag or maybe a shell variable, something >> like: >> >> ./configure MACOSX_SDK=/my/path/to/SDK >> >> This, along with the addition of the -arch i386 -arch ppc flags would >> be enough to enable someone to write a script to create a Panther- >> compatible Universal build. Which I'm pretty sure someone will do >> sooner or later. :-) > > No, it wouldn't actually. The 10.3 SDK is ppc only, and a Panther- > compatible build (well, something compatible with 10.3.8 and below) > must use GCC 3.3, but an x86 compatible build must use GCC 4. The compiler issue really is a problem, although we could probably hack around this using a script that runs the actual compilers and then using lipo to merge the result. As I said before, it should be possible to build a 10.3.0 compatible build using the 10.4 SDK. This does require patching several modules (posixmodule.c is one of them) because 10.4 has several functions that are not available on earlier editions of the OS. I seem to have removed that patch from my system, but recreating it shouldn't be very hard now that I know how to do it. Getting it accepted into the Python repository might be a different story. The advantage of building on 10.4 is that the Intel and PPC versions will have the same features when run on a Tiger system. Ronald > > In other words, something Panther compatible needs to use different > compilers with totally different options for x86 and PPC. It's not > going to be easy, distutils doesn't come anywhere near close to > supporting anything like that and neither does autoconf. > > I think the only approach that doesn't require hacking a > significant amount of Python's build process and distutils is to > have two Python installations, one x86 only and one PPC only. For > distribution, you would cook up some way to lipo it all together. > > -bob -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060127/de00b3eb/attachment-0001.bin From ronaldoussoren at mac.com Fri Jan 27 09:08:59 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 27 Jan 2006 09:08:59 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <43D99211.30504@code-bear.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> Message-ID: <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> On 27-jan-2006, at 4:22, bear wrote: > Ronald Oussoren wrote: >> That part is easy enough. If you want a framework build you'll >> have to patch Makefile.pre.in because it contains a hardcoded '- >> arch ppc' in the section that builds that actual framework. >> Otherwise it should just build (assuming you have an intel mac of >> course, cross-building from PPC to Intel will be hard because the >> build process assumes you'll do a native build). > ok, I found the relevant part in configure (and cofigure.in) that > was putting -arch_only ppc into the Makefile and I've re-run > configure and it seems happy - heck, even the compiling ran error > free. > > But when it got to the link part - I get the following error: You must replace the -arch ppc part by -arch i386. If you want to build a universal binary you'll have to replace the call to libtool by something more complex. I'll see if I can produce a patch later today. Ronald > > ...... > ranlib libpython2.4.a > /usr/bin/install -c -d -m 755 Python.framework/Versions/2.4 > libtool -o Python.framework/Versions/2.4/Python -dynamic > libpython2.4.a \ > -lSystem -lSystemStubs -install_name > /Users/bear/projects/osaf/chandler/trunk/external/release/Library/ > Frameworks/Python.framework/Versions/2.4/Python > -compatibility_version 2.4 -current_version 2.4 > ld64 failed: in libpython2.4.a(__.SYMDEF), not a valid ppc64 mach-o > file > libtool: internal link edit command failed > make: *** [Python.framework/Versions/2.4/Python] Error 1 > > I must be missing something very basic. The following is a small > script I've been using to test with: > > export SDK=/Developer/SDKs/MacOSX10.4u.sdk > export TARGET_ARCH="" #" -arch i386 -arch ppc" > export LDFLAGS="-L${PREFIX}/lib -isysroot ${SDK} ${TARGET_ARCH}" > export PREFIX=/Users/bear/projects/release > > cd /Users/bear/projects/Python-2.4.2/build_release > > MACOSX_DEPLOYMENT_TARGET=10.4 \ > LDFLAGS=${LDFLAGS} \ > CPPFLAGS="-I${PREFIX}/include ${CPPFLAGS}" \ > ../configure --prefix=${PREFIX} \ > --enable-framework=${PREFIX}/Library/Frameworks \ > --with-readline=${PREFIX}/lib \ > --disable-ipv6 \ > --disable-dependency-tracking > > MACOSX_DEPLOYMENT_TARGET=10.4 make frameworkinstallframework > > > any clues or thoughts appreciated > > -- bear > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060127/7c725e16/attachment.bin From ronaldoussoren at mac.com Fri Jan 27 09:19:37 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 27 Jan 2006 09:19:37 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <09A33074-9ED6-40D4-A803-9FE573E11D77@theolliviers.com> <5A0B196A-A66A-438D-919D-3C9949089AF1@redivi.com> Message-ID: <1A75DF71-B24C-4D8D-A2F9-1B80B67DAB92@mac.com> On 27-jan-2006, at 8:46, Kevin Ollivier wrote: > Hi Bob, > > On Jan 26, 2006, at 10:55 PM, Bob Ippolito wrote: > > [snip] > >>> Sorry, I wasn't really thinking about extensions. By Panther I >>> did mean building against the 10.3.9 SDK, which would give the >>> desired results for the Python binary itself, but as you said >>> extending that to correctly build extensions that did the same >>> thing would be a royal PITA. >> >> You still need to build against two different SDKs, which can't be >> done with just compiler flags. You have to do two separate >> compiles, and then lipo it together. At that point you might as >> well use different compilers and target older versions of OS X. > > Yes, this was what I meant in my previous email about letting the > SDK get specified at configure time. I was thinking to have bash > script that automates the various steps. I guess you could put it > into the configure script, but that does sound to me to be pretty > painful. A bash script? Heresy :-) Why not a python script. We can be pretty sure that python is available at build time. > >> The other thing is that Python's build probably detects a few >> things at runtime, and at runtime it's seeing 10.4, so it might >> not actually work on the target version of OS X. > > Yeah, if this is the case it'd be a real mess. ;-/ That's more problematic on Panther :-). Python's configure has hardcoded that OSX 10.2 and 10.4 must not have _POSIX_SOURCE and friends defined. Annoyingly this means that if you build Python on Panther you'll have to patch the build if you want to build extensions on Tiger. I'm sitting on yet another patch that adds OSX 10.3 to the list. > >> Ideally all that stuff would be pushed to runtime checks, so that >> it could choose a different code path based upon which APIs are >> available... but first you have to isolate the instances where >> that happens. >> >>>> I think the only approach that doesn't require hacking a >>>> significant amount of Python's build process and distutils is to >>>> have two Python installations, one x86 only and one PPC only. >>>> For distribution, you would cook up some way to lipo it all >>>> together. >>> >>> I can see how the issues with the strategy I outlined would be >>> significant, but I don't see how Universal support on Tiger would >>> be similarly difficult. Apple's Python 2.3.5 already is >>> Universal, and I'm unaware of any issues with it (except that it >>> doesn't build Universal extensions ;). The changes they made to >>> the build process seemed to be fairly minimal. >> >> Yeah, a 10.4+ universal build wouldn't be too big of a deal >> because you can do that with one invocation of GCC and one set of >> flags. >> >>> As far as distutils/working with extensions, I admit I'm not very >>> familiar with that. I did notice when compiling wxPython though >>> that there weren't any distutils flags passed to gcc that would >>> conflict with the building of Universal binaries. The main >>> question in my mind would be whether or not the built Universal >>> extension libraries could be loaded by Python's dynamic library >>> loader. If they can be loaded, and we could add the flags to >>> distutils' default compiler/linker flags, what other major issues >>> would need to be overcome? >> >> Some extensions aren't going to build cleanly universal, and most >> users probably aren't going to have all the SDKs installed so if >> it shipped with universal flags then it wouldn't be able to build >> extensions. > > Unless we had distutils check for the existence of the Universal > SDK before setting the flags, or probably more accurately, remove > them if the SDK isn't available. Then perhaps add a distutils > 'flag' to manually turn off Universal building for extensions that > can't be fixed. This might be a bit of a hack, but I don't imagine > it would be too painful. The question is how many extensions would > have troubles... But I guess the only way we'll know is to test the > waters. In any case, even if it wouldn't be reasonable to make a > Universal build the "official" build, it would be very useful to > people packaging apps, even if it were Tiger+ only. I know of one popular extension (cElementTree) that won't build with '-arch i386 -arch ppc' because it calcutes a #define based on the current byte-order. There might be others, I haven't done a thorough search yet. > > As far as the SDK dependency issue, IMHO, not everyone would need > to build Universal - the key would be for distributors/packages to > make Universal binaries, and I think it would be reasonable for us > to tell them "have the 10.4u SDK and DevTools installed". (And > maybe the Panther/Jaguar SDK assuming we could sort the issues you > mentioned above out...) Again, assuming a Universal build does make > a sensible default. Note that this means "install Tiger" which not everyone might want to. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060127/6dd235ab/attachment.bin From bob at redivi.com Fri Jan 27 09:45:54 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 27 Jan 2006 00:45:54 -0800 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> Message-ID: <68091D21-1148-477B-B3C5-5432DCB8BF53@redivi.com> On Jan 27, 2006, at 12:06 AM, Ronald Oussoren wrote: > > On 27-jan-2006, at 4:02, Bob Ippolito wrote: > >> >> On Jan 26, 2006, at 6:28 PM, Kevin Ollivier wrote: >> >>> On Jan 26, 2006, at 12:48 AM, Ronald Oussoren wrote: >>> >>> [snip] >>> >>>> I'm (very slowly) playing around with adding '-arch ppc -arch i386' >>>> to the build flags and building on an intel host. That way you >>>> won't >>>> have to use SDKs, which makes it less likely that configure >>>> picks up >>>> other information than the actual compile (not that there should be >>>> any differences if you use the 10.4u SDK). >>>> >>>> With some effort it should be possible to build a version of python >>>> that will run on 10.3 as well. As far as python is concerned the >>>> differences between 10.3 and 10.4 seem to be fairly small. The >>>> reason >>>> I'd like to do this instead of merging a build-on-10.3 PPC version >>>> and a build-on-10.4 intel version is that the latter would contain >>>> small incompatibilities between the intel and ppc version (some >>>> scripts would work on intel but not on ppc). >>> >>> IMHO, what would be cool is to allow the user to pass the SDK in as >>> some sort of configure flag or maybe a shell variable, something >>> like: >>> >>> ./configure MACOSX_SDK=/my/path/to/SDK >>> >>> This, along with the addition of the -arch i386 -arch ppc flags >>> would >>> be enough to enable someone to write a script to create a Panther- >>> compatible Universal build. Which I'm pretty sure someone will do >>> sooner or later. :-) >> >> No, it wouldn't actually. The 10.3 SDK is ppc only, and a Panther- >> compatible build (well, something compatible with 10.3.8 and >> below) must use GCC 3.3, but an x86 compatible build must use GCC 4. > > The compiler issue really is a problem, although we could probably > hack around this using a script that runs the actual compilers and > then using lipo to merge the result. As I said before, it should be > possible to build a 10.3.0 compatible build using the 10.4 SDK. > This does require patching several modules (posixmodule.c is one of > them) because 10.4 has several functions that are not available on > earlier editions of the OS. I seem to have removed that patch from > my system, but recreating it shouldn't be very hard now that I know > how to do it. Getting it accepted into the Python repository might > be a different story. > > The advantage of building on 10.4 is that the Intel and PPC > versions will have the same features when run on a Tiger system. Yeah, you probably could build something functional on Mac OS X 10.3.0 against the 10.4 SDK if you were very careful, and you were using gcc 3.3 to build the PPC arch of the project. I'll play around with it next week when I have access to an x86 box again... but the 10.3.0 stuff I can't do because I don't think I have any 10.3 machines to test on. -bob From bear42 at code-bear.com Fri Jan 27 16:38:00 2006 From: bear42 at code-bear.com (bear) Date: Fri, 27 Jan 2006 10:38:00 -0500 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> Message-ID: <43DA3E58.2020602@code-bear.com> Ronald Oussoren wrote: > > On 27-jan-2006, at 4:22, bear wrote: > >> Ronald Oussoren wrote: >>> That part is easy enough. If you want a framework build you'll have >>> to patch Makefile.pre.in because it contains a hardcoded '-arch ppc' >>> in the section that builds that actual framework. Otherwise it >>> should just build (assuming you have an intel mac of course, >>> cross-building from PPC to Intel will be hard because the build >>> process assumes you'll do a native build). >> ok, I found the relevant part in configure (and cofigure.in) that was >> putting -arch_only ppc into the Makefile and I've re-run configure >> and it seems happy - heck, even the compiling ran error free. >> >> But when it got to the link part - I get the following error: > > You must replace the -arch ppc part by -arch i386. If you want to > build a universal binary you'll have to replace the call to libtool by > something more complex. I'll see if I can produce a patch later today. Coolness - I was able to get a clean build of python for the i386 arch just now. I did have to apply a patch to Lib/plat-mac/applesingle.py so that it would run without errors. I got the required patch from http://www.opensource.apple.com/darwinsource/tarballs/other/python-16.tar.gz that Kevin mentioned in an earlier post to this thread. Now to build the rest of our app and see how it fairs ;) From ronaldoussoren at mac.com Fri Jan 27 17:31:28 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 27 Jan 2006 17:31:28 +0100 Subject: [Pythonmac-SIG] building universal binaries In-Reply-To: <43DA3E58.2020602@code-bear.com> References: <20060125004922.GF10062@activestate.com> <43D712E7.4080601@code-bear.com> <50006469-0FC6-4A80-9426-93A40B0F2569@theolliviers.com> <43D7CB4D.1010903@code-bear.com> <5881317D-3D15-44B4-9D3B-6CBB84454012@theolliviers.com> <43D802D5.10709@code-bear.com> <43D80DF9.7000707@code-bear.com> <43D99211.30504@code-bear.com> <7C74F9E0-B3A5-41AA-8587-9413DC2D57CA@mac.com> <43DA3E58.2020602@code-bear.com> Message-ID: <73A7E1DB-7E04-42EE-B80E-AB145BA80017@mac.com> On 27-jan-2006, at 16:38, bear wrote: > Ronald Oussoren wrote: >> >> On 27-jan-2006, at 4:22, bear wrote: >> >>> Ronald Oussoren wrote: >>>> That part is easy enough. If you want a framework build you'll >>>> have to patch Makefile.pre.in because it contains a hardcoded '- >>>> arch ppc' in the section that builds that actual framework. >>>> Otherwise it should just build (assuming you have an intel mac >>>> of course, cross-building from PPC to Intel will be hard because >>>> the build process assumes you'll do a native build). >>> ok, I found the relevant part in configure (and cofigure.in) that >>> was putting -arch_only ppc into the Makefile and I've re-run >>> configure and it seems happy - heck, even the compiling ran error >>> free. >>> >>> But when it got to the link part - I get the following error: >> >> You must replace the -arch ppc part by -arch i386. If you want to >> build a universal binary you'll have to replace the call to >> libtool by something more complex. I'll see if I can produce a >> patch later today. > Coolness - I was able to get a clean build of python for the i386 > arch just now. I did have to apply a patch to Lib/plat-mac/ > applesingle.py so that it would run without errors. I got the > required patch from http://www.opensource.apple.com/darwinsource/ > tarballs/other/python-16.tar.gz that Kevin mentioned in an earlier > post to this thread. > > Now to build the rest of our app and see how it fairs ;) > From my Makefile.pre.in: RESSRCDIR=$(srcdir)/Mac/OSXResources/framework $(PYTHONFRAMEWORKDIR)/Versions/$(VERSION)/$(PYTHONFRAMEWORK): \ $(LIBRARY) \ $(RESSRCDIR)/Info.plist \ $(RESSRCDIR)/version.plist \ $(RESSRCDIR)/English.lproj/InfoPlist.strings $(INSTALL) -d -m $(DIRMODE) $(PYTHONFRAMEWORKDIR)/Versions/$ (VERSION) case "${LDFLAGS}" in \ *"-arch i386"*"-arch ppc"*|*"-arch ppc"*"-arch i386"*) \ libtool -o $(LDLIBRARY).i386 -dynamic $ (OTHER_LIBTOOL_OPT) $(LIBRARY) -arch_only i386 \ @LIBTOOL_CRUFT@ ;\ libtool -o $(LDLIBRARY).ppc -dynamic $ (OTHER_LIBTOOL_OPT) $(LIBRARY) -arch_only ppc \ @LIBTOOL_CRUFT@ ;\ lipo -create -output $(LDLIBRARY) -arch i386 $ (LDLIBRARY).i386 -arch ppc $(LDLIBRARY).ppc ;\ rm $(LDLIBRARY).i386 $(LDLIBRARY).ppc ;\ ;; \ *"-arch i386"*) \ libtool -o $(LDLIBRARY).i386 -dynamic $ (OTHER_LIBTOOL_OPT) $(LIBRARY) -arch_only i386 \ @LIBTOOL_CRUFT@ ;\ ;; \ *"-arch ppc"*) \ libtool -o $(LDLIBRARY).i386 -dynamic $ (OTHER_LIBTOOL_OPT) $(LIBRARY) -arch_only ppc \ @LIBTOOL_CRUFT@ ;\ ;; \ *) \ libtool -o $(LDLIBRARY) -dynamic $ (OTHER_LIBTOOL_OPT) $(LIBRARY) -arch_only `machine` \ @LIBTOOL_CRUFT@ ;\ ;; \ esac This is very ugly. As you have noted you can't just drop -arch ppc because libtool than assumes that you want to do a 3-way universal build. Probably because libSystem contains a ppc64 binary. I hope to have a script for building a "batteries included" universal build of python by the end of this weekend. Ronald -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060127/bbdc481c/attachment.bin From skip at pobox.com Fri Jan 27 18:43:23 2006 From: skip at pobox.com (skip at pobox.com) Date: Fri, 27 Jan 2006 11:43:23 -0600 Subject: [Pythonmac-SIG] Mac Intel Python status? In-Reply-To: References: <17368.15977.919794.784108@montanaro.dyndns.org> Message-ID: <17370.23483.18931.448014@montanaro.dyndns.org> s> Apparently the readline library in MacOSX isn't really readline. s> It's a renamed libedit. Not having encountered this deception s> before, Python's build procedure doesn't know to test the capability s> of readline. I suggest you just comment out the readline checks in s> setup.py. Piet> libedit (editline) is a different library with a similar function Piet> as readline, but not compatible with it. It has a BSD license. It Piet> is often used instead of readline for non-GPL software. True. I believe it was written by Rich Salz several years ago. Python used to work with it, but eventually started using some readline functionality which libedit doesn't provide. I don't recall what that is. Skip From pythonmac at justinmitchell.net Mon Jan 30 00:41:06 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Sun, 29 Jan 2006 18:41:06 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? Message-ID: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> Is py2app 0.3 stable? I see that it's the latest version in the svn repository, but I see no download on his website. I also see 0.2.1 in the repository, but I'm not sure what revision number would be considered stable for that version. I did attempt to use 0.3 and got errors. I'll attempt to diagnose those after I figure out whether it's even meant to be used or not.... Justin From bob at redivi.com Mon Jan 30 01:56:04 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 29 Jan 2006 16:56:04 -0800 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> Message-ID: On Jan 29, 2006, at 3:41 PM, Justin Mitchell wrote: > Is py2app 0.3 stable? I see that it's the latest version in the svn > repository, but I see no download on his website. I also see 0.2.1 in > the repository, but I'm not sure what revision number would be > considered stable for that version. The release that's on the site is the "stable" version. > I did attempt to use 0.3 and got errors. I'll attempt to diagnose > those after I figure out whether it's even meant to be used or not.... Try it with the release version and see if it works. -bob From pythonmac at justinmitchell.net Mon Jan 30 03:23:37 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Sun, 29 Jan 2006 21:23:37 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> Message-ID: <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> On 1/29/06, Bob Ippolito wrote: > On Jan 29, 2006, at 3:41 PM, Justin Mitchell wrote: > > > I did attempt to use 0.3 and got errors. I'll attempt to diagnose > > those after I figure out whether it's even meant to be used or not.... > > Try it with the release version and see if it works. > There are a few things that I've had trouble with, such as including wxPython, and Intel Mac OS X support. In regards to wxPython... py2app 0.2 doesn't automatically include the wxPython 2.5.3 files, so I have to force it with "-p". This results in a rather large binary (19 megs worth of wxPython stuff). I'm using 10.4.4 and the default python/wxPython version. I tried to "-exclude" portions of wxPython, but -exclude doesn't seem to function (or I'm using it improperly). In regards to Intel support... well, my application won't run on the Intel macs under Rosetta. It won't be until tomorrow, when I finally get an Intel mac, that I'll know whether it is a problem with my script, py2app, or what. If Universal Binary support works with py2app 0.3, then it would be very valuable to me too. I'll go into more detail regarding this later, as soon as I can properly test it. - Justin From kevino at theolliviers.com Mon Jan 30 03:59:46 2006 From: kevino at theolliviers.com (Kevin Ollivier) Date: Sun, 29 Jan 2006 18:59:46 -0800 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> Message-ID: <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> Hi Justin, On Jan 29, 2006, at 6:23 PM, Justin Mitchell wrote: > On 1/29/06, Bob Ippolito wrote: >> On Jan 29, 2006, at 3:41 PM, Justin Mitchell wrote: >> >>> I did attempt to use 0.3 and got errors. I'll attempt to diagnose >>> those after I figure out whether it's even meant to be used or >>> not.... >> >> Try it with the release version and see if it works. >> > > There are a few things that I've had trouble with, such as including > wxPython, and Intel Mac OS X support. > > In regards to wxPython... py2app 0.2 doesn't automatically include the > wxPython 2.5.3 files, so I have to force it with "-p". This results in > a rather large binary (19 megs worth of wxPython stuff). I'm using > 10.4.4 and the default python/wxPython version. I tried to "-exclude" > portions of wxPython, but -exclude doesn't seem to function (or I'm > using it improperly). Have you considered using 2.6.2 instead? It will properly include the bits you need (2.5.3 is part of the "system" for Tiger, which is why I suspect it doesn't automatically get included) and you'll benefit from the numerous bugfixes since 2.5.3. > In regards to Intel support... well, my application won't run on the > Intel macs under Rosetta. It won't be until tomorrow, when I finally > get an Intel mac, that I'll know whether it is a problem with my > script, py2app, or what. If Universal Binary support works with py2app > 0.3, then it would be very valuable to me too. I'll go into more > detail regarding this later, as soon as I can properly test it. wxWidgets/wxPython 2.6.3 will have support for building the wxWidgets part as a Universal Binary, but AFAIK Python doesn't officially have Universal binary support yet (though it's a work in progress), so at this point the wxPython wrappers would still be either PPC or Intel native. Once Python does have such support, we'll release a wxPython Universal Binary to go along with it. :-) (Barring any significant unforeseen problems!) Still, I've tried several py2app bundles that include wxPython, along with several other C++ wrapper extensions, and they've all worked just fine so far under Rosetta on an Intel iMac. So there may be a way to resolve this issue without creating a Universal build. Kevin > - Justin > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From bob at redivi.com Mon Jan 30 04:46:38 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 29 Jan 2006 19:46:38 -0800 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> Message-ID: On Jan 29, 2006, at 6:59 PM, Kevin Ollivier wrote: > Hi Justin, > > On Jan 29, 2006, at 6:23 PM, Justin Mitchell wrote: > >> On 1/29/06, Bob Ippolito wrote: >>> On Jan 29, 2006, at 3:41 PM, Justin Mitchell wrote: >>> >>>> I did attempt to use 0.3 and got errors. I'll attempt to diagnose >>>> those after I figure out whether it's even meant to be used or >>>> not.... >>> >>> Try it with the release version and see if it works. >>> >> >> There are a few things that I've had trouble with, such as including >> wxPython, and Intel Mac OS X support. >> >> In regards to wxPython... py2app 0.2 doesn't automatically include >> the >> wxPython 2.5.3 files, so I have to force it with "-p". This >> results in >> a rather large binary (19 megs worth of wxPython stuff). I'm using >> 10.4.4 and the default python/wxPython version. I tried to "-exclude" >> portions of wxPython, but -exclude doesn't seem to function (or I'm >> using it improperly). > > Have you considered using 2.6.2 instead? It will properly include the > bits you need (2.5.3 is part of the "system" for Tiger, which is why > I suspect it doesn't automatically get included) and you'll benefit > from the numerous bugfixes since 2.5.3. If you want to use installed packages that aren't part of the standard library you have to use the option that makes it so: --site- packages >> In regards to Intel support... well, my application won't run on the >> Intel macs under Rosetta. It won't be until tomorrow, when I finally >> get an Intel mac, that I'll know whether it is a problem with my >> script, py2app, or what. If Universal Binary support works with >> py2app >> 0.3, then it would be very valuable to me too. I'll go into more >> detail regarding this later, as soon as I can properly test it. > > wxWidgets/wxPython 2.6.3 will have support for building the wxWidgets > part as a Universal Binary, but AFAIK Python doesn't officially have > Universal binary support yet (though it's a work in progress), so at > this point the wxPython wrappers would still be either PPC or Intel > native. Once Python does have such support, we'll release a wxPython > Universal Binary to go along with it. :-) (Barring any significant > unforeseen problems!) > > Still, I've tried several py2app bundles that include wxPython, along > with several other C++ wrapper extensions, and they've all worked > just fine so far under Rosetta on an Intel iMac. So there may be a > way to resolve this issue without creating a Universal build. At this point, universal binary support in py2app would hurt more than help. Right now you want the bootstrap to be PPC so that it's forced to run under Rosetta. As Kevin says, every py2app-built app that I've ever tried on Rosetta worked just fine. It must've been something you did differently. -bob From pythonmac at justinmitchell.net Mon Jan 30 04:49:00 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Sun, 29 Jan 2006 22:49:00 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> Message-ID: <220f68650601291949l4c2279f7ua54b4f96780a59d4@mail.gmail.com> On 1/29/06, Kevin Ollivier wrote: > Hi Justin, > > On Jan 29, 2006, at 6:23 PM, Justin Mitchell wrote: > > > On 1/29/06, Bob Ippolito wrote: > >> On Jan 29, 2006, at 3:41 PM, Justin Mitchell wrote: > >> > >>> I did attempt to use 0.3 and got errors. I'll attempt to diagnose > >>> those after I figure out whether it's even meant to be used or > >>> not.... > >> > >> Try it with the release version and see if it works. > >> > > > > There are a few things that I've had trouble with, such as including > > wxPython, and Intel Mac OS X support. > > > > In regards to wxPython... py2app 0.2 doesn't automatically include the > > wxPython 2.5.3 files, so I have to force it with "-p". This results in > > a rather large binary (19 megs worth of wxPython stuff). I'm using > > 10.4.4 and the default python/wxPython version. I tried to "-exclude" > > portions of wxPython, but -exclude doesn't seem to function (or I'm > > using it improperly). > > Have you considered using 2.6.2 instead? It will properly include the > bits you need (2.5.3 is part of the "system" for Tiger, which is why > I suspect it doesn't automatically get included) and you'll benefit > from the numerous bugfixes since 2.5.3. > I did try wxPython 2.6.2 and ran into the same problem. When I launch the application I get the typical dialog that says "ImportError: No module named wxversion". When I'm using 2.5.3 I don't use wxversion, and I get "ImportError: No module named wxPython.wx". I also tried to use the advice in the py2app docs that suggest pointing to the wx rsrc file in the frameworks variable in setup.py, but that didn't help either (there's no rsrc file included with 2.6.2, so I just tried this with 2.5.3). So, my next logical conclusion was to try a newer version of py2app, but if other people are having success with 0.2 (are they?), then it's probably something else. - Justin From pythonmac at justinmitchell.net Mon Jan 30 04:57:18 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Sun, 29 Jan 2006 22:57:18 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> Message-ID: <220f68650601291957p76a2ccdbt81588e3789867c62@mail.gmail.com> On 1/29/06, Bob Ippolito wrote: > > On Jan 29, 2006, at 6:59 PM, Kevin Ollivier wrote: > > > Hi Justin, > > > > On Jan 29, 2006, at 6:23 PM, Justin Mitchell wrote: > > > >> On 1/29/06, Bob Ippolito wrote: > >>> On Jan 29, 2006, at 3:41 PM, Justin Mitchell wrote: > >>> > >>>> I did attempt to use 0.3 and got errors. I'll attempt to diagnose > >>>> those after I figure out whether it's even meant to be used or > >>>> not.... > >>> > >>> Try it with the release version and see if it works. > >>> > >> > >> There are a few things that I've had trouble with, such as including > >> wxPython, and Intel Mac OS X support. > >> > >> In regards to wxPython... py2app 0.2 doesn't automatically include > >> the > >> wxPython 2.5.3 files, so I have to force it with "-p". This > >> results in > >> a rather large binary (19 megs worth of wxPython stuff). I'm using > >> 10.4.4 and the default python/wxPython version. I tried to "-exclude" > >> portions of wxPython, but -exclude doesn't seem to function (or I'm > >> using it improperly). > > > > Have you considered using 2.6.2 instead? It will properly include the > > bits you need (2.5.3 is part of the "system" for Tiger, which is why > > I suspect it doesn't automatically get included) and you'll benefit > > from the numerous bugfixes since 2.5.3. > > If you want to use installed packages that aren't part of the > standard library you have to use the option that makes it so: --site- > packages Great, that did the trick. I misunderstood that option, before. > >> In regards to Intel support... well, my application won't run on the > >> Intel macs under Rosetta. It won't be until tomorrow, when I finally > >> get an Intel mac, that I'll know whether it is a problem with my > >> script, py2app, or what. If Universal Binary support works with > >> py2app > >> 0.3, then it would be very valuable to me too. I'll go into more > >> detail regarding this later, as soon as I can properly test it. > > > > wxWidgets/wxPython 2.6.3 will have support for building the wxWidgets > > part as a Universal Binary, but AFAIK Python doesn't officially have > > Universal binary support yet (though it's a work in progress), so at > > this point the wxPython wrappers would still be either PPC or Intel > > native. Once Python does have such support, we'll release a wxPython > > Universal Binary to go along with it. :-) (Barring any significant > > unforeseen problems!) > > > > Still, I've tried several py2app bundles that include wxPython, along > > with several other C++ wrapper extensions, and they've all worked > > just fine so far under Rosetta on an Intel iMac. So there may be a > > way to resolve this issue without creating a Universal build. > > At this point, universal binary support in py2app would hurt more > than help. Right now you want the bootstrap to be PPC so that it's > forced to run under Rosetta. As Kevin says, every py2app-built app > that I've ever tried on Rosetta worked just fine. It must've been > something you did differently. > > -bob I'll do a proper test as soon as the iMac arrives. Hopefully the problem will have already been resolved by my previous fix. - Justin From pythonmac at justinmitchell.net Mon Jan 30 08:11:41 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Mon, 30 Jan 2006 02:11:41 -0500 Subject: [Pythonmac-SIG] protecting source code? Message-ID: <220f68650601292311v7dba933fqbf432e20a01d958b@mail.gmail.com> Is there any way to protect (hide) the source code of the script we are packaging with pyapp, like py2exe and cx_freeze? - Justin From bob at redivi.com Mon Jan 30 10:10:09 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 30 Jan 2006 01:10:09 -0800 Subject: [Pythonmac-SIG] protecting source code? In-Reply-To: <220f68650601292311v7dba933fqbf432e20a01d958b@mail.gmail.com> References: <220f68650601292311v7dba933fqbf432e20a01d958b@mail.gmail.com> Message-ID: On Jan 29, 2006, at 11:11 PM, Justin Mitchell wrote: > Is there any way to protect (hide) the source code of the script we > are packaging with pyapp, like py2exe and cx_freeze? The default "protection" is about as good as it's going to get. In py2app's case, everything but the main script is compiled bytecode. Don't put anything "important" in that. Even if you did encrypt the bytecode or other such nonsense it's easy enough to jack into the Python interpreter and disassemble it, so it's a lost cause to do any more. -bob From justinhomi at gmail.com Mon Jan 30 03:18:23 2006 From: justinhomi at gmail.com (Justin Mitchell) Date: Sun, 29 Jan 2006 21:18:23 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> Message-ID: <220f68650601291818v300832e9l40b1b15308ecf901@mail.gmail.com> On 1/29/06, Bob Ippolito wrote: > On Jan 29, 2006, at 3:41 PM, Justin Mitchell wrote: > > > I did attempt to use 0.3 and got errors. I'll attempt to diagnose > > those after I figure out whether it's even meant to be used or not.... > > Try it with the release version and see if it works. > There are a few things that I've had trouble with, such as including wxPython and Intel Mac OS X support. In regards to wxPython... py2app 0.2 doesn't automatically include the wxPython 2.5.3 files, so I have to force it with "-p". This results in a rather large binary (19 megs worth of wxPython stuff). I'm using 10.4.4 and the default python/wxPython version. I tried to "-exclude" portions of wxPython, but -exclude doesn't seem to function (or I'm using it improperly). In regards to Intel support... well, my application won't run on the Intel macs under Rosetta. It won't be until tomorrow, when I finally get an Intel mac, that I'll know whether it is a problem with my script, py2app, or what. If Universal Binary support works with py2app 0.3, then it would be very valuable to me too. I'll go into more detail regarding this later, as soon as I can properly test it. From justinhomi at gmail.com Mon Jan 30 04:55:36 2006 From: justinhomi at gmail.com (Justin Mitchell) Date: Sun, 29 Jan 2006 22:55:36 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> Message-ID: <220f68650601291955x4d497646wbf1026ac2c944764@mail.gmail.com> On 1/29/06, Bob Ippolito wrote: > > On Jan 29, 2006, at 6:59 PM, Kevin Ollivier wrote: > > > Hi Justin, > > > > On Jan 29, 2006, at 6:23 PM, Justin Mitchell wrote: > > > >> On 1/29/06, Bob Ippolito wrote: > >>> On Jan 29, 2006, at 3:41 PM, Justin Mitchell wrote: > >>> > >>>> I did attempt to use 0.3 and got errors. I'll attempt to diagnose > >>>> those after I figure out whether it's even meant to be used or > >>>> not.... > >>> > >>> Try it with the release version and see if it works. > >>> > >> > >> There are a few things that I've had trouble with, such as including > >> wxPython, and Intel Mac OS X support. > >> > >> In regards to wxPython... py2app 0.2 doesn't automatically include > >> the > >> wxPython 2.5.3 files, so I have to force it with "-p". This > >> results in > >> a rather large binary (19 megs worth of wxPython stuff). I'm using > >> 10.4.4 and the default python/wxPython version. I tried to "-exclude" > >> portions of wxPython, but -exclude doesn't seem to function (or I'm > >> using it improperly). > > > > Have you considered using 2.6.2 instead? It will properly include the > > bits you need (2.5.3 is part of the "system" for Tiger, which is why > > I suspect it doesn't automatically get included) and you'll benefit > > from the numerous bugfixes since 2.5.3. > > If you want to use installed packages that aren't part of the > standard library you have to use the option that makes it so: --site- > packages Great, that did the trick. I misunderstood that option before. > >> In regards to Intel support... well, my application won't run on the > >> Intel macs under Rosetta. It won't be until tomorrow, when I finally > >> get an Intel mac, that I'll know whether it is a problem with my > >> script, py2app, or what. If Universal Binary support works with > >> py2app > >> 0.3, then it would be very valuable to me too. I'll go into more > >> detail regarding this later, as soon as I can properly test it. > > > > wxWidgets/wxPython 2.6.3 will have support for building the wxWidgets > > part as a Universal Binary, but AFAIK Python doesn't officially have > > Universal binary support yet (though it's a work in progress), so at > > this point the wxPython wrappers would still be either PPC or Intel > > native. Once Python does have such support, we'll release a wxPython > > Universal Binary to go along with it. :-) (Barring any significant > > unforeseen problems!) > > > > Still, I've tried several py2app bundles that include wxPython, along > > with several other C++ wrapper extensions, and they've all worked > > just fine so far under Rosetta on an Intel iMac. So there may be a > > way to resolve this issue without creating a Universal build. > > At this point, universal binary support in py2app would hurt more > than help. Right now you want the bootstrap to be PPC so that it's > forced to run under Rosetta. As Kevin says, every py2app-built app > that I've ever tried on Rosetta worked just fine. It must've been > something you did differently. > > -bob I'll do a proper test as soon as the new iMac arrives. Maybe the problem will be resolved with my previous step, as the users were complaining about wxPython errors. - Justin From georgewr at bigpond.net.au Mon Jan 30 13:18:16 2006 From: georgewr at bigpond.net.au (George Wright) Date: Mon, 30 Jan 2006 23:18:16 +1100 Subject: [Pythonmac-SIG] UpArrow for previous command Message-ID: On my old imac when working interactively with python in 'Terminal' I could get previous commands by hitting up arrow (or down arrow). I can't remember how I set that up and I have been unable to get the same feature on my newer iMac g5. Have searched message archives without success. Hitting uparrow just prints ^[[A which makes a mess you have to delete. Would appreciate some help. George Wright http://users.bigpond.net.au/George.Wright/ http://www.labyrinth.net.au/~gwright From mjb at uma.pt Mon Jan 30 14:53:23 2006 From: mjb at uma.pt (Michael Barber) Date: Mon, 30 Jan 2006 13:53:23 +0000 Subject: [Pythonmac-SIG] UpArrow for previous command In-Reply-To: References: Message-ID: George, You need to install "readline". You can get it at . Hope that helps, Michael On Jan 30, 2006, at 12:18 PM, George Wright wrote: > On my old imac when working interactively with python in 'Terminal' I > could get previous commands by hitting up arrow (or down arrow). I > can't remember how I set that up and I have been unable to get the > same feature on my newer iMac g5. Have searched message archives > without success. Hitting uparrow just prints ^[[A which makes a mess > you have to delete. > Would appreciate some help. > > George Wright > http://users.bigpond.net.au/George.Wright/ > http://www.labyrinth.net.au/~gwright > > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From pythonmac at justinmitchell.net Mon Jan 30 17:16:04 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Mon, 30 Jan 2006 11:16:04 -0500 Subject: [Pythonmac-SIG] protecting source code? In-Reply-To: References: <220f68650601292311v7dba933fqbf432e20a01d958b@mail.gmail.com> Message-ID: <220f68650601300816x298be335xc6b812a4769027a7@mail.gmail.com> On 1/30/06, Bob Ippolito wrote: > On Jan 29, 2006, at 11:11 PM, Justin Mitchell wrote: > > > Is there any way to protect (hide) the source code of the script we > > are packaging with pyapp, like py2exe and cx_freeze? > > The default "protection" is about as good as it's going to get. In > py2app's case, everything but the main script is compiled bytecode. > Don't put anything "important" in that. Even if you did encrypt the > bytecode or other such nonsense it's easy enough to jack into the > Python interpreter and disassemble it, so it's a lost cause to do any > more. Ah, good to know. The main script was the only one I had looked at! I figured the rest was the same. Thanks! Justin From ryanwilcox at mac.com Mon Jan 30 20:39:38 2006 From: ryanwilcox at mac.com (Ryan Wilcox) Date: Mon, 30 Jan 2006 14:39:38 -0500 Subject: [Pythonmac-SIG] LaunchServices and (appscript and) Intel Mac? Message-ID: Hello all, I wanted to get appscript up and running on my Intel mac. I installed Tiger23Compat.pkg, and Python23Compat, which installed LaunchServices. Now I do a $ pythonw >>> from appscript import * >>> from appscript import * Traceback (most recent call last): File "", line 1, in ? File "/Library/Python/2.3/site-packages/appscript/__init__.py", line 15, in ? from findapp import ApplicationNotFoundError File "/Library/Python/2.3/site-packages/appscript/findapp.py", line 9, in ? from LaunchServices.Launch import LSFindApplicationForInfo File "/platlib/LaunchServices/Launch.py", line 1, in ? ImportError: dlopen(/Library/Python/2.3/_Launch.so, 2): no suitable image found. Did find: /Library/Python/2.3/_Launch.so: mach-o, but wrong architecture Is there somewhere I acquire the LaunchServices code and run python setup.py install myself, or is it harder than that? (Or am I totally on the wrong track for Intel?) Thanks so much, _Ryan Wilcox -- Wilcox Development Solutions: Toolsmiths for the Internet Age PGP: 0x2F4E9C31 From bob at redivi.com Mon Jan 30 21:04:44 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 30 Jan 2006 12:04:44 -0800 Subject: [Pythonmac-SIG] LaunchServices and (appscript and) Intel Mac? In-Reply-To: References: Message-ID: <1CDDC362-9694-49F2-AE9B-FF3C8278A28B@redivi.com> On Jan 30, 2006, at 11:39 AM, Ryan Wilcox wrote: > Hello all, > > I wanted to get appscript up and running on my Intel mac. I > installed Tiger23Compat.pkg, and Python23Compat, which installed > LaunchServices. > > Now I do a > $ pythonw >>>> from appscript import * > >>>> from appscript import * > Traceback (most recent call last): > File "", line 1, in ? > File "/Library/Python/2.3/site-packages/appscript/__init__.py", > line 15, in ? > from findapp import ApplicationNotFoundError > File "/Library/Python/2.3/site-packages/appscript/findapp.py", > line 9, in ? > from LaunchServices.Launch import LSFindApplicationForInfo > File "/platlib/LaunchServices/Launch.py", line 1, in ? > ImportError: dlopen(/Library/Python/2.3/_Launch.so, 2): no suitable > image found. Did find: > /Library/Python/2.3/_Launch.so: mach-o, but wrong architecture > > > Is there somewhere I acquire the LaunchServices code and run python > setup.py install myself, or is it harder than that? http://svn.red-bean.com/bob/Python23Compat/trunk/ -bob From pythonmac at justinmitchell.net Tue Jan 31 05:49:49 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Mon, 30 Jan 2006 23:49:49 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <220f68650601291957p76a2ccdbt81588e3789867c62@mail.gmail.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> <220f68650601291957p76a2ccdbt81588e3789867c62@mail.gmail.com> Message-ID: <220f68650601302049i5f05d609q35dabda11d3e18fe@mail.gmail.com> On 1/29/06, Justin Mitchell wrote: > On 1/29/06, Bob Ippolito wrote: > > > > On Jan 29, 2006, at 6:59 PM, Kevin Ollivier wrote: > > > > > Hi Justin, > > > > > > On Jan 29, 2006, at 6:23 PM, Justin Mitchell wrote: > > > > > >> On 1/29/06, Bob Ippolito wrote: > > >>> On Jan 29, 2006, at 3:41 PM, Justin Mitchell wrote: > > >>> > > >>>> I did attempt to use 0.3 and got errors. I'll attempt to diagnose > > >>>> those after I figure out whether it's even meant to be used or > > >>>> not.... > > >>> > > >>> Try it with the release version and see if it works. > > >>> > > >> > > >> There are a few things that I've had trouble with, such as including > > >> wxPython, and Intel Mac OS X support. > > >> > > >> In regards to wxPython... py2app 0.2 doesn't automatically include > > >> the > > >> wxPython 2.5.3 files, so I have to force it with "-p". This > > >> results in > > >> a rather large binary (19 megs worth of wxPython stuff). I'm using > > >> 10.4.4 and the default python/wxPython version. I tried to "-exclude" > > >> portions of wxPython, but -exclude doesn't seem to function (or I'm > > >> using it improperly). > > > > > > Have you considered using 2.6.2 instead? It will properly include the > > > bits you need (2.5.3 is part of the "system" for Tiger, which is why > > > I suspect it doesn't automatically get included) and you'll benefit > > > from the numerous bugfixes since 2.5.3. > > > > If you want to use installed packages that aren't part of the > > standard library you have to use the option that makes it so: --site- > > packages > > Great, that did the trick. I misunderstood that option, before. > > > >> In regards to Intel support... well, my application won't run on the > > >> Intel macs under Rosetta. It won't be until tomorrow, when I finally > > >> get an Intel mac, that I'll know whether it is a problem with my > > >> script, py2app, or what. If Universal Binary support works with > > >> py2app > > >> 0.3, then it would be very valuable to me too. I'll go into more > > >> detail regarding this later, as soon as I can properly test it. > > > > > > wxWidgets/wxPython 2.6.3 will have support for building the wxWidgets > > > part as a Universal Binary, but AFAIK Python doesn't officially have > > > Universal binary support yet (though it's a work in progress), so at > > > this point the wxPython wrappers would still be either PPC or Intel > > > native. Once Python does have such support, we'll release a wxPython > > > Universal Binary to go along with it. :-) (Barring any significant > > > unforeseen problems!) > > > > > > Still, I've tried several py2app bundles that include wxPython, along > > > with several other C++ wrapper extensions, and they've all worked > > > just fine so far under Rosetta on an Intel iMac. So there may be a > > > way to resolve this issue without creating a Universal build. > > > > At this point, universal binary support in py2app would hurt more > > than help. Right now you want the bootstrap to be PPC so that it's > > forced to run under Rosetta. As Kevin says, every py2app-built app > > that I've ever tried on Rosetta worked just fine. It must've been > > something you did differently. > > > > -bob > > I'll do a proper test as soon as the iMac arrives. Hopefully the > problem will have already been resolved by my previous fix. > > - Justin > Just got the intel iMac. It took me five minutes to convince my roommate that the whole computer is inside of the monitor. Anyways, I'm running into this error when trying to run the application (which was packaged with py2app 0.2). The script works if I don't package it. No changes were made from the ppc version. import pcapy ImportError: dlopen(/path/to/myapplication.app/Contents/Resources/Python/lib-dynload/pcapy.so, 2): no suitable image found. Did find: /path/to/myapplication.app/Contents/Resources/Python/lib-dynload/pcapy.so: mach-o, but wrong architecture Any suggestions on where to go next? Thanks a bunch, Justin From ronaldoussoren at mac.com Tue Jan 31 10:10:36 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 31 Jan 2006 10:10:36 +0100 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <220f68650601302049i5f05d609q35dabda11d3e18fe@mail.gmail.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> <220f68650601291957p76a2ccdbt81588e3789867c62@mail.gmail.com> <220f68650601302049i5f05d609q35dabda11d3e18fe@mail.gmail.com> Message-ID: <8AD319CC-E8E4-431F-B3FC-ED0CEE2221D0@mac.com> On 31-jan-2006, at 5:49, Justin Mitchell wrote: > > Anyways, I'm running into this error when trying to run the > application (which was packaged with py2app 0.2). The script works if > I don't package it. No changes were made from the ppc version. > > import pcapy > ImportError: dlopen(/path/to/myapplication.app/Contents/Resources/ > Python/lib-dynload/pcapy.so, > 2): no suitable image found. Did find: > /path/to/myapplication.app/Contents/Resources/Python/lib-dynload/ > pcapy.so: > mach-o, but wrong architecture What is the output of "file /path/to/myapplication.app/Contents/ Resources/Python/lib-dynload/pcapy.so"? And what is the output of "file /path/to/myapplication.app/Contents/MacOS/ myapplication"? Did you package the application on PPC or did you rebuild the application bundle on Intel? If the latter, did you rebuild the py2app application stub binary? Ronald > > Any suggestions on where to go next? > > Thanks a bunch, > > Justin > _______________________________________________ > 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: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060131/d8aab4a3/attachment.bin From pythonmac at justinmitchell.net Tue Jan 31 11:27:59 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Tue, 31 Jan 2006 05:27:59 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <8AD319CC-E8E4-431F-B3FC-ED0CEE2221D0@mac.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> <220f68650601291957p76a2ccdbt81588e3789867c62@mail.gmail.com> <220f68650601302049i5f05d609q35dabda11d3e18fe@mail.gmail.com> <8AD319CC-E8E4-431F-B3FC-ED0CEE2221D0@mac.com> Message-ID: <220f68650601310227h16e6dc02rd771a8f8696f21c9@mail.gmail.com> On 1/31/06, Ronald Oussoren wrote: > > On 31-jan-2006, at 5:49, Justin Mitchell wrote: > > > Anyways, I'm running into this error when trying to run the > > application (which was packaged with py2app 0.2). The script works if > > I don't package it. No changes were made from the ppc version. > > > > import pcapy > > ImportError: dlopen(/path/to/myapplication.app/Contents/Resources/ > > Python/lib-dynload/pcapy.so, > > 2): no suitable image found. Did find: > > /path/to/myapplication.app/Contents/Resources/Python/lib-dynload/ > > pcapy.so: > > mach-o, but wrong architecture > > What is the output of "file /path/to/myapplication.app/Contents/ > Resources/Python/lib-dynload/pcapy.so"? And > what is the output of "file /path/to/myapplication.app/Contents/MacOS/ > myapplication"? file pcapy.so: pcapy.so: Mach-O bundle i386 file myapplication.so: myapplication: setuid Mach-O executable ppc > Did you package the application on PPC or did you rebuild the > application bundle on Intel? If the latter, > did you rebuild the py2app application stub binary? I packaged the application on the Intel iMac. I installed py2app from scratch, using the 0.2 source. - Justin From ronaldoussoren at mac.com Tue Jan 31 11:35:30 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 31 Jan 2006 11:35:30 +0100 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <220f68650601310227h16e6dc02rd771a8f8696f21c9@mail.gmail.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> <220f68650601291957p76a2ccdbt81588e3789867c62@mail.gmail.com> <220f68650601302049i5f05d609q35dabda11d3e18fe@mail.gmail.com> <8AD319CC-E8E4-431F-B3FC-ED0CEE2221D0@mac.com> <220f68650601310227h16e6dc02rd771a8f8696f21c9@mail.gmail.com> Message-ID: On 31-jan-2006, at 11:27, Justin Mitchell wrote: > On 1/31/06, Ronald Oussoren wrote: >> >> On 31-jan-2006, at 5:49, Justin Mitchell wrote: >> >>> Anyways, I'm running into this error when trying to run the >>> application (which was packaged with py2app 0.2). The script >>> works if >>> I don't package it. No changes were made from the ppc version. >>> >>> import pcapy >>> ImportError: dlopen(/path/to/myapplication.app/Contents/Resources/ >>> Python/lib-dynload/pcapy.so, >>> 2): no suitable image found. Did find: >>> /path/to/myapplication.app/Contents/Resources/Python/lib- >>> dynload/ >>> pcapy.so: >>> mach-o, but wrong architecture >> >> What is the output of "file /path/to/myapplication.app/Contents/ >> Resources/Python/lib-dynload/pcapy.so"? And >> what is the output of "file /path/to/myapplication.app/Contents/ >> MacOS/ >> myapplication"? > > file pcapy.so: > pcapy.so: Mach-O bundle i386 > > file myapplication.so: > myapplication: setuid Mach-O executable ppc Note that the application is a ppc executable and the extensions is for i386. That won't work :-) > >> Did you package the application on PPC or did you rebuild the >> application bundle on Intel? If the latter, >> did you rebuild the py2app application stub binary? > > I packaged the application on the Intel iMac. I installed py2app from > scratch, using the 0.2 source. That's the problem. Go to py2app/src/py2app/apptemplate and remove prebuild/main. Then reinstall py2app from source. There's also a bundletemplate, remove the files in its prebuild directory as well if you want to build plugin bundles. Ronald > > - Justin > _______________________________________________ > 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: 2157 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060131/f5665a4e/attachment.bin From mark at mophilly.com Tue Jan 31 17:06:34 2006 From: mark at mophilly.com (Mark Phillips) Date: Tue, 31 Jan 2006 08:06:34 -0800 Subject: [Pythonmac-SIG] SQLobject example Message-ID: I am seeking a dead simple CRUD example of using the SQLobject, geared toward the python newbie with bad habits from other programming languages. I found this article, which is pretty good but a question or two still linger. http://www.devx.com/dbzone/Article/22093/ I clicked around Ian Bickling's site and learned a bit. I would be most grateful if someone can offer a link to another clear example. Or, if you feel there is something better, a link to alternatives. Mark Phillips -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060131/3580cf11/attachment.htm From bray at sent.com Tue Jan 31 17:40:02 2006 From: bray at sent.com (Brian Ray) Date: Tue, 31 Jan 2006 10:40:02 -0600 Subject: [Pythonmac-SIG] SQLobject example In-Reply-To: References: Message-ID: <14C3A59B-AD67-431B-B94B-F4E30142893B@sent.com> Did you see SQLObject has it's own mailing lists? http://sqlobject.org/community.html From pythonmac at justinmitchell.net Tue Jan 31 21:04:58 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Tue, 31 Jan 2006 15:04:58 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> <220f68650601291957p76a2ccdbt81588e3789867c62@mail.gmail.com> <220f68650601302049i5f05d609q35dabda11d3e18fe@mail.gmail.com> <8AD319CC-E8E4-431F-B3FC-ED0CEE2221D0@mac.com> <220f68650601310227h16e6dc02rd771a8f8696f21c9@mail.gmail.com> Message-ID: <220f68650601311204k58cd028bqfb21450c8f2806a1@mail.gmail.com> On 1/31/06, Ronald Oussoren wrote: > > On 31-jan-2006, at 11:27, Justin Mitchell wrote: > > > On 1/31/06, Ronald Oussoren wrote: > >> > >> On 31-jan-2006, at 5:49, Justin Mitchell wrote: > >> > >>> Anyways, I'm running into this error when trying to run the > >>> application (which was packaged with py2app 0.2). The script > >>> works if > >>> I don't package it. No changes were made from the ppc version. > >>> > >>> import pcapy > >>> ImportError: dlopen(/path/to/myapplication.app/Contents/Resources/ > >>> Python/lib-dynload/pcapy.so, > >>> 2): no suitable image found. Did find: > >>> /path/to/myapplication.app/Contents/Resources/Python/lib- > >>> dynload/ > >>> pcapy.so: > >>> mach-o, but wrong architecture > >> > >> What is the output of "file /path/to/myapplication.app/Contents/ > >> Resources/Python/lib-dynload/pcapy.so"? And > >> what is the output of "file /path/to/myapplication.app/Contents/ > >> MacOS/ > >> myapplication"? > > > > file pcapy.so: > > pcapy.so: Mach-O bundle i386 > > > > file myapplication.so: > > myapplication: setuid Mach-O executable ppc > > Note that the application is a ppc executable and the extensions is > for i386. That won't work :-) > > > >> Did you package the application on PPC or did you rebuild the > >> application bundle on Intel? If the latter, > >> did you rebuild the py2app application stub binary? > > > > I packaged the application on the Intel iMac. I installed py2app from > > scratch, using the 0.2 source. > > That's the problem. Go to py2app/src/py2app/apptemplate and remove > prebuild/main. Then reinstall > py2app from source. There's also a bundletemplate, remove the files > in its prebuild directory as > well if you want to build plugin bundles. > OK, that makes sense, I didn't realize it was prebuilt. I just tried this, but got the same error. I suspect that I am building it incorrectly. The instructions say to use "python setup.py bdist_mpkg --open", but that as always gotten lots of errors for me (doc folder missing, /usr/bin/mkbom failed). So, I tried "python setup.py build && python setup.py install". That installed, but I'm not sure if it's actually doing it's job.... Justin From pythonmac at justinmitchell.net Tue Jan 31 21:48:15 2006 From: pythonmac at justinmitchell.net (Justin Mitchell) Date: Tue, 31 Jan 2006 15:48:15 -0500 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <220f68650601311204k58cd028bqfb21450c8f2806a1@mail.gmail.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> <220f68650601291957p76a2ccdbt81588e3789867c62@mail.gmail.com> <220f68650601302049i5f05d609q35dabda11d3e18fe@mail.gmail.com> <8AD319CC-E8E4-431F-B3FC-ED0CEE2221D0@mac.com> <220f68650601310227h16e6dc02rd771a8f8696f21c9@mail.gmail.com> <220f68650601311204k58cd028bqfb21450c8f2806a1@mail.gmail.com> Message-ID: <220f68650601311248w614e655arae1025f6df4c6aca@mail.gmail.com> On 1/31/06, Justin Mitchell wrote: > On 1/31/06, Ronald Oussoren wrote: > > > > On 31-jan-2006, at 11:27, Justin Mitchell wrote: > > > > > On 1/31/06, Ronald Oussoren wrote: > > >> > > >> On 31-jan-2006, at 5:49, Justin Mitchell wrote: > > >> > > >>> Anyways, I'm running into this error when trying to run the > > >>> application (which was packaged with py2app 0.2). The script > > >>> works if > > >>> I don't package it. No changes were made from the ppc version. > > >>> > > >>> import pcapy > > >>> ImportError: dlopen(/path/to/myapplication.app/Contents/Resources/ > > >>> Python/lib-dynload/pcapy.so, > > >>> 2): no suitable image found. Did find: > > >>> /path/to/myapplication.app/Contents/Resources/Python/lib- > > >>> dynload/ > > >>> pcapy.so: > > >>> mach-o, but wrong architecture > > >> > > >> What is the output of "file /path/to/myapplication.app/Contents/ > > >> Resources/Python/lib-dynload/pcapy.so"? And > > >> what is the output of "file /path/to/myapplication.app/Contents/ > > >> MacOS/ > > >> myapplication"? > > > > > > file pcapy.so: > > > pcapy.so: Mach-O bundle i386 > > > > > > file myapplication.so: > > > myapplication: setuid Mach-O executable ppc > > > > Note that the application is a ppc executable and the extensions is > > for i386. That won't work :-) > > > > > >> Did you package the application on PPC or did you rebuild the > > >> application bundle on Intel? If the latter, > > >> did you rebuild the py2app application stub binary? > > > > > > I packaged the application on the Intel iMac. I installed py2app from > > > scratch, using the 0.2 source. > > > > That's the problem. Go to py2app/src/py2app/apptemplate and remove > > prebuild/main. Then reinstall > > py2app from source. There's also a bundletemplate, remove the files > > in its prebuild directory as > > well if you want to build plugin bundles. > > > > OK, that makes sense, I didn't realize it was prebuilt. I just tried > this, but got the same error. I suspect that I am building it > incorrectly. The instructions say to use "python setup.py bdist_mpkg > --open", but that as always gotten lots of errors for me (doc folder > missing, /usr/bin/mkbom failed). So, I tried "python setup.py build && > python setup.py install". That installed, but I'm not sure if it's > actually doing it's job.... > > Justin Well, I went ahead and checked out 0.2.1 (r502) from the SVN repository. The "proper" installation method works with that version, and it also solved the problem with executables being the wrong arch (I still removed the prebuilt files). Was I doing something wrong before, or is this just something with 0.2? Justin From bob at redivi.com Tue Jan 31 22:26:53 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 31 Jan 2006 13:26:53 -0800 Subject: [Pythonmac-SIG] py2app 0.3 stable? In-Reply-To: <220f68650601311248w614e655arae1025f6df4c6aca@mail.gmail.com> References: <220f68650601291541q7324d5f3x6139ab9892acf5c8@mail.gmail.com> <220f68650601291823x3a3a5b59n1d3e2dccb6f5f8c1@mail.gmail.com> <8BE9AC54-3F9B-4359-ABCC-4329DB5FECB9@theolliviers.com> <220f68650601291957p76a2ccdbt81588e3789867c62@mail.gmail.com> <220f68650601302049i5f05d609q35dabda11d3e18fe@mail.gmail.com> <8AD319CC-E8E4-431F-B3FC-ED0CEE2221D0@mac.com> <220f68650601310227h16e6dc02rd771a8f8696f21c9@mail.gmail.com> <220f68650601311204k58cd028bqfb21450c8f2806a1@mail.gmail.com> <220f68650601311248w614e655arae1025f6df4c6aca@mail.gmail.com> Message-ID: <38FCEC3A-F1AB-4C8C-92A0-D6615F02CDEC@redivi.com> On Jan 31, 2006, at 12:48 PM, Justin Mitchell wrote: > On 1/31/06, Justin Mitchell wrote: >> On 1/31/06, Ronald Oussoren wrote: >>> >>> On 31-jan-2006, at 11:27, Justin Mitchell wrote: >>> >>>> On 1/31/06, Ronald Oussoren wrote: >>>>> >>>>> On 31-jan-2006, at 5:49, Justin Mitchell wrote: >>>>> >>>>>> Anyways, I'm running into this error when trying to run the >>>>>> application (which was packaged with py2app 0.2). The script >>>>>> works if >>>>>> I don't package it. No changes were made from the ppc version. >>>>>> >>>>>> import pcapy >>>>>> ImportError: dlopen(/path/to/myapplication.app/Contents/ >>>>>> Resources/ >>>>>> Python/lib-dynload/pcapy.so, >>>>>> 2): no suitable image found. Did find: >>>>>> /path/to/myapplication.app/Contents/Resources/Python/lib- >>>>>> dynload/ >>>>>> pcapy.so: >>>>>> mach-o, but wrong architecture >>>>> >>>>> What is the output of "file /path/to/myapplication.app/Contents/ >>>>> Resources/Python/lib-dynload/pcapy.so"? And >>>>> what is the output of "file /path/to/myapplication.app/Contents/ >>>>> MacOS/ >>>>> myapplication"? >>>> >>>> file pcapy.so: >>>> pcapy.so: Mach-O bundle i386 >>>> >>>> file myapplication.so: >>>> myapplication: setuid Mach-O executable ppc >>> >>> Note that the application is a ppc executable and the extensions is >>> for i386. That won't work :-) >>>> >>>>> Did you package the application on PPC or did you rebuild the >>>>> application bundle on Intel? If the latter, >>>>> did you rebuild the py2app application stub binary? >>>> >>>> I packaged the application on the Intel iMac. I installed py2app >>>> from >>>> scratch, using the 0.2 source. >>> >>> That's the problem. Go to py2app/src/py2app/apptemplate and remove >>> prebuild/main. Then reinstall >>> py2app from source. There's also a bundletemplate, remove the files >>> in its prebuild directory as >>> well if you want to build plugin bundles. >>> >> >> OK, that makes sense, I didn't realize it was prebuilt. I just tried >> this, but got the same error. I suspect that I am building it >> incorrectly. The instructions say to use "python setup.py bdist_mpkg >> --open", but that as always gotten lots of errors for me (doc folder >> missing, /usr/bin/mkbom failed). So, I tried "python setup.py >> build && >> python setup.py install". That installed, but I'm not sure if it's >> actually doing it's job.... >> >> Justin > > Well, I went ahead and checked out 0.2.1 (r502) from the SVN > repository. The "proper" installation method works with that version, > and it also solved the problem with executables being the wrong arch > (I still removed the prebuilt files). > > Was I doing something wrong before, or is this just something with > 0.2? The zip source release was busted (the docs were missing)... the installer pkg and the 0.2 tag in the subversion repository are correct. I didn't update the MANIFEST.in file correctly, that's all. py2app 0.3 is going to be setuptools based, so I won't ever have to touch a MANIFEST.in file again :) -bob