From revolutionary.dan at gmail.com Tue Aug 1 00:01:22 2006 From: revolutionary.dan at gmail.com (Dan Shafer) Date: Mon, 31 Jul 2006 15:01:22 -0700 Subject: [Pythonmac-SIG] Getting Started Problem Message-ID: <70ed6b130607311501me7b368er6006e61e2fe0ef8b@mail.gmail.com> Been away from Python for a while, welcoming myself back home, but running into a config or misunderstanding problem. OS X 10.4.7, Python 2.3.5, downloaded MacPython 2.3 yesterday. Double-clicking on PythonIDE brings up a splasher which disappears and nothing appears to be running. IDLE runs fine. Launching PythonLauncher shows a setting that appears to point at /usr/bin/pythonw, which is a valid directory and which, when entered in a Terminal, launches Pythonw 2.3.5. So what am I not understanding? Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060731/017cc091/attachment.htm From bob at redivi.com Tue Aug 1 00:26:02 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 31 Jul 2006 15:26:02 -0700 Subject: [Pythonmac-SIG] Getting Started Problem In-Reply-To: <70ed6b130607311501me7b368er6006e61e2fe0ef8b@mail.gmail.com> References: <70ed6b130607311501me7b368er6006e61e2fe0ef8b@mail.gmail.com> Message-ID: <3348761F-516B-4022-A4F0-8686668E3C2D@redivi.com> On Jul 31, 2006, at 3:01 PM, Dan Shafer wrote: > Been away from Python for a while, welcoming myself back home, but > running into a config or misunderstanding problem. > > OS X 10.4.7, Python 2.3.5, downloaded MacPython 2.3 yesterday. > Double-clicking on PythonIDE brings up a splasher which disappears > and nothing appears to be running. > > IDLE runs fine. Launching PythonLauncher shows a setting that > appears to point at /usr/bin/pythonw, which is a valid directory > and which, when entered in a Terminal, launches Pythonw 2.3.5. > > So what am I not understanding? Sounds like you may be using an Intel machine. Python IDE doesn't work on Intel and it never will. It's officially dead. Download Universal Python 2.4 and use the IDLE it comes with. The Python 2.3.5 that ships with OS X 10.4 has a host of (mostly endian related) bugs on Intel and isn't suitable for any Mac-specific work. These bugs are not present in Universal Python 2.4, or Python 2.5 (which is currently in beta). -bob From altis at semi-retired.com Tue Aug 1 00:42:02 2006 From: altis at semi-retired.com (Kevin Altis) Date: Mon, 31 Jul 2006 15:42:02 -0700 Subject: [Pythonmac-SIG] PythonLauncher replacement for Python 2.4.x universal builds? Message-ID: I'm thinking about finally moving over to the universal Python 2.4.x build on my Intel duo iMac rather than using the Python 2.3.5 and wxPython that it shipped with. One concern I have though is a replacement for PythonLauncher which I still use regularly to launch .py and .pyw wxPython and PythonCard programs from the Finder. Creating standalones of these applications with py2app is not my goal, nor would it be an adequate workaround as the programs can change frequently and rebuilding a standalone would be an unacceptable overhead. Having to run the scripts from the Terminal all the time would be a pain. Currently, I can choose to edit the files or run them simply by choosing a different editor or PythonLauncher via the Open With menu item which works just as well for aliases to the files. If its possible to make something equivalent to PythonLauncher that would basically work the same way that would be acceptable. Thanks in advance for a pointer to an updated PythonLauncher or workaround! ka From bob at redivi.com Tue Aug 1 01:17:34 2006 From: bob at redivi.com (Bob Ippolito) Date: Mon, 31 Jul 2006 16:17:34 -0700 Subject: [Pythonmac-SIG] PythonLauncher replacement for Python 2.4.x universal builds? In-Reply-To: References: Message-ID: <45AABB89-1637-4F27-9A4D-8C4DBE937F2C@redivi.com> On Jul 31, 2006, at 3:42 PM, Kevin Altis wrote: > I'm thinking about finally moving over to the universal Python 2.4.x > build on my Intel duo iMac rather than using the Python 2.3.5 and > wxPython that it shipped with. One concern I have though is a > replacement for PythonLauncher which I still use regularly to > launch .py and .pyw wxPython and PythonCard programs from the Finder. > Creating standalones of these applications with py2app is not my > goal, nor would it be an adequate workaround as the programs can > change frequently and rebuilding a standalone would be an > unacceptable overhead. Having to run the scripts from the Terminal > all the time would be a pain. Alias bundles remove the pain of rebuilding for frequently changing scripts. Not that big of a deal to make one. py2applet -A someapp.py open someapp.app http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html > Currently, I can choose to edit the files or run them simply by > choosing a different editor or PythonLauncher via the Open With menu > item which works just as well for aliases to the files. If its > possible to make something equivalent to PythonLauncher that would > basically work the same way that would be acceptable. > > Thanks in advance for a pointer to an updated PythonLauncher or > workaround! A copy of PythonLauncher always ships with the installer. /Applications/MacPython 2.4/PythonLauncher.app -bob From Chris.Barker at noaa.gov Tue Aug 1 18:58:02 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 01 Aug 2006 09:58:02 -0700 Subject: [Pythonmac-SIG] PythonLauncher replacement for Python 2.4.x universal builds? In-Reply-To: <45AABB89-1637-4F27-9A4D-8C4DBE937F2C@redivi.com> References: <45AABB89-1637-4F27-9A4D-8C4DBE937F2C@redivi.com> Message-ID: <44CF881A.7030801@noaa.gov> Bob Ippolito wrote: > Alias bundles remove the pain of rebuilding for frequently changing > scripts. Not that big of a deal to make one. > > py2applet -A someapp.py > open someapp.app Of course, that's still one more step than just running the script from the command line: ./someapp.py Which is just as easy, or easier, than double clicking on something in the finder anyway, but we all have our favorite methods of working. A few hints, if you do want use the command line: 1) get "Open Terminal Here" (google it). It lets you put a button on the Finder that opens a Terminal, then changes to the current folder int eh finder -- very handy. 2) alt+tab will switch between windows, so when you have done some editing, you can just alt+tab, and you're in the terminal, then hit the up arrow, and you get your previous command back, then enter to run it. Nice to have you up and working with the latest Kevin -- the more testers the better. -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 Aug 1 20:12:49 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 1 Aug 2006 11:12:49 -0700 Subject: [Pythonmac-SIG] PythonLauncher replacement for Python 2.4.x universal builds? In-Reply-To: <44CF881A.7030801@noaa.gov> References: <45AABB89-1637-4F27-9A4D-8C4DBE937F2C@redivi.com> <44CF881A.7030801@noaa.gov> Message-ID: <4B6F6414-6950-4E68-83D8-43269E3F62F8@redivi.com> On Aug 1, 2006, at 9:58 AM, Christopher Barker wrote: > Bob Ippolito wrote: >> Alias bundles remove the pain of rebuilding for frequently changing >> scripts. Not that big of a deal to make one. >> >> py2applet -A someapp.py >> open someapp.app > > Of course, that's still one more step than just running the script > from > the command line: > > ./someapp.py > > Which is just as easy, or easier, than double clicking on something in > the finder anyway, but we all have our favorite methods of working. It's only one more step the first time. -bob From Chris.Barker at noaa.gov Tue Aug 1 23:28:32 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Tue, 01 Aug 2006 14:28:32 -0700 Subject: [Pythonmac-SIG] PythonLauncher replacement for Python 2.4.x universal builds? In-Reply-To: <4B6F6414-6950-4E68-83D8-43269E3F62F8@redivi.com> References: <45AABB89-1637-4F27-9A4D-8C4DBE937F2C@redivi.com> <44CF881A.7030801@noaa.gov> <4B6F6414-6950-4E68-83D8-43269E3F62F8@redivi.com> Message-ID: <44CFC780.9090909@noaa.gov> Bob Ippolito wrote: > On Aug 1, 2006, at 9:58 AM, Christopher Barker wrote: >>> py2applet -A someapp.py >>> open someapp.app > It's only one more step the first time. Ahh! very good point! In case other readers of this list are as dense as me (or haven't gone and read the docs) -- A Py2app applet links to the files used by your app, rather than copying them, so when you make changes to a file, those changes *will* be seen when you next run the applet (either on the command line, with "open", or by double clicking). This appears to solve the OP's issue well. Of course, this was quite clear in the docs, if I had read them carefully the first time: "You only need to run this command again when you add data files or change options. Changes to your source code won't require rebuilding!" -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 hengist.podd at virgin.net Thu Aug 3 19:08:26 2006 From: hengist.podd at virgin.net (has) Date: Thu, 3 Aug 2006 18:08:26 +0100 Subject: [Pythonmac-SIG] appscript questions Message-ID: <389ABDE1-631E-4DDE-BA20-3CFBBF319E7D@virgin.net> Hi folks, Getting appscript prepared for the next release (only a couple away from beta now), and wondering if anyone has preferences on the following: 1. If a local application quits while a script is using it, either unexpectedly or because the client script sent a 'quit' command, should appscript relaunch that application automatically the next time it sends a command to it, or should the application stay quit unless the client script deliberately restarts it (by sending a 'run'/'open'/'activate'/'launch' command)? (Automatic restarts, which is what AppleScript does, are more convenient. However, if an application quit unexpectedly you probably want it to stay quit and have the script halt with an error the next time it tries to interact. So I'm more inclined towards the latter, but would like to know what others think.) 2. I'm looking to downgrade, if not eliminate, the role of ASTS. It's no longer needed for remote scripting (good, as there were issues when running it on remote machines with multiple active users), and a 3x speedup in appscript's terminology retrieval and parsing times mean it provides less of a performance benefit when scripting local apps. Three options I see: - Retain ASTS support as it's still the most convenient way to provide external caching (users pretty much just need to launch it, either manually or as a login item, and can then forget about it). - Do away with ASTS completely and always retrieve and parse terminology on the fly (less efficient, especially when repeatedly running short scripts, but completely foolproof). - Move to some sort of file-based cache, either managed completely manually (users can selectively create terminology files for those applications they want to avoid a cold start on), or automatically (appscript could store all parsed terminologies in, say, /tmp). 3. Should appscript's built-in help() use textwrap to automatically wrap long lines to fit in a standard 80-column terminal window? Or is it better to leave the terminal window to wrap them naturally (i.e. users may prefer to resize terminal windows themselves to make text easier to read)? Thanks, has p.s. If anyone'd like to help me out a bit, I'd really like to get all the manuals into the standard Python documentation format now. So if you're familiar with the tools and would like to have a go then let me know - it'd be much appreciated. -- http://freespace.virgin.net/hamish.sanderson/ From njriley at uiuc.edu Thu Aug 3 19:27:50 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Thu, 3 Aug 2006 12:27:50 -0500 Subject: [Pythonmac-SIG] appscript questions In-Reply-To: <389ABDE1-631E-4DDE-BA20-3CFBBF319E7D@virgin.net> References: <389ABDE1-631E-4DDE-BA20-3CFBBF319E7D@virgin.net> Message-ID: <20060803172750.GA43324@uiuc.edu> On Thu, Aug 03, 2006 at 06:08:26PM +0100, has wrote: > So I'm more inclined towards the latter, but would like to know what > others think.) I agree - if the app quits, it should stay quit. Sometimes when I'm trying to abort a script I quit an app that's being controlled, and to see it relaunch over and over and over again... aaargh. > - Do away with ASTS completely and always retrieve and parse > terminology on the fly (less efficient, especially when repeatedly > running short scripts, but completely foolproof). > > - Move to some sort of file-based cache, either managed completely > manually (users can selectively create terminology files for those > applications they want to avoid a cold start on), or automatically > (appscript could store all parsed terminologies in, say, /tmp). I'd say to do the first one, and if you get complaints, move to the second one. I got very confused about the role of ASTS in remote scripting myself (you may remember an email I sent you that effect :-), and at least in my case I don't use appscript for small scripts, I use it primarily for faceless background apps, so it wouldn't matter. > 3. Should appscript's built-in help() use textwrap to automatically > wrap long lines to fit in a standard 80-column terminal window? Or is > it better to leave the terminal window to wrap them naturally (i.e. > users may prefer to resize terminal windows themselves to make text > easier to read)? How about wrapping to the terminal width, whatever it happens to be? That's what most other things do. (You could always have a 'wrap=False' option to help(), if necessary.) -- Nicholas Riley | From ronaldoussoren at mac.com Thu Aug 3 22:13:22 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 3 Aug 2006 22:13:22 +0200 Subject: [Pythonmac-SIG] appscript questions In-Reply-To: <389ABDE1-631E-4DDE-BA20-3CFBBF319E7D@virgin.net> References: <389ABDE1-631E-4DDE-BA20-3CFBBF319E7D@virgin.net> Message-ID: On Aug 3, 2006, at 7:08 PM, has wrote: > Hi folks, > > Getting appscript prepared for the next release (only a couple away > from beta now), and wondering if anyone has preferences on the > following: > > 1. If a local application quits while a script is using it, either > unexpectedly or because the client script sent a 'quit' command, > should appscript relaunch that application automatically the next > time it sends a command to it, or should the application stay quit > unless the client script deliberately restarts it (by sending a > 'run'/'open'/'activate'/'launch' command)? > > (Automatic restarts, which is what AppleScript does, are more > convenient. However, if an application quit unexpectedly you probably > want it to stay quit and have the script halt with an error the next > time it tries to interact. So I'm more inclined towards the latter, > but would like to know what others think.) If AppleScript automaticly restarts applications at least some users will think that not restarting is bug. OTOH if you automaticly restart an application its state might be different than the script expects, which could cause problems. I'm not a heavy appscript user, so I can't really say that I care one way or the other. > > > 2. I'm looking to downgrade, if not eliminate, the role of ASTS. It's > no longer needed for remote scripting (good, as there were issues > when running it on remote machines with multiple active users), and a > 3x speedup in appscript's terminology retrieval and parsing times > mean it provides less of a performance benefit when scripting local > apps. Three options I see: I'd drop ASTS if it isn't really needed. I use appscript without ASTS and the startup time has never really bothered me. If the new version starts up significantly faster I don't see a good reason for retaining ASTS. I also like the "complete foolproof" part of not having ASTS :-) > p.s. If anyone'd like to help me out a bit, I'd really like to get > all the manuals into the standard Python documentation format now. So > if you're familiar with the tools and would like to have a go then > let me know - it'd be much appreciated. Why do you want to do that? You have to use special tools to convert that to a useable format. 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/20060803/4ef204fb/attachment.bin From delza at livingcode.org Fri Aug 4 00:49:51 2006 From: delza at livingcode.org (Dethe Elza) Date: Thu, 03 Aug 2006 15:49:51 -0700 Subject: [Pythonmac-SIG] appscript questions In-Reply-To: References: <389ABDE1-631E-4DDE-BA20-3CFBBF319E7D@virgin.net> Message-ID: <44D27D8F.7050506@livingcode.org> Ronald Oussoren wrote: > On Aug 3, 2006, at 7:08 PM, has wrote: >> p.s. If anyone'd like to help me out a bit, I'd really like to get >> all the manuals into the standard Python documentation format now. So >> if you're familiar with the tools and would like to have a go then >> let me know - it'd be much appreciated. > > Why do you want to do that? You have to use special tools to convert > that to a useable format. And if you're trying to get docs into the standard library, those folks are perfectly willing to take plaintext documentation and dress it up in LaTeX themselves. --Dethe From bob at redivi.com Fri Aug 4 01:24:51 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 3 Aug 2006 16:24:51 -0700 Subject: [Pythonmac-SIG] appscript questions In-Reply-To: <44D27D8F.7050506@livingcode.org> References: <389ABDE1-631E-4DDE-BA20-3CFBBF319E7D@virgin.net> <44D27D8F.7050506@livingcode.org> Message-ID: <00AB96C8-7972-4D43-AA17-2CE50BCC2E19@redivi.com> On Aug 3, 2006, at 3:49 PM, Dethe Elza wrote: > Ronald Oussoren wrote: > >> On Aug 3, 2006, at 7:08 PM, has wrote: >>> p.s. If anyone'd like to help me out a bit, I'd really like to get >>> all the manuals into the standard Python documentation format >>> now. So >>> if you're familiar with the tools and would like to have a go then >>> let me know - it'd be much appreciated. >> >> Why do you want to do that? You have to use special tools to convert >> that to a useable format. > > And if you're trying to get docs into the standard library, those > folks > are perfectly willing to take plaintext documentation and dress it > up in > LaTeX themselves. I really don't think that should be any immediate concern in the appscript case, I'd definitely be -1 on that. I don't think it would be a good idea to put more platform-specific stuff in Python, or to subject appscript and its dependencies to the same release schedule as Python itself. I'd like to see most of plat-mac get extricated from Python in the future, and move the cross-platform chunks like plistlib and applesingle to the standard library (or just separate projects). A much better and more immediate plan would be to setuptools-ify appscript so that it's easy to build and install. That could be done and released in an hour (oh how I love "python setup.py register bdist_egg sdist upload -s"). -bob From rhudson at orcasinc.com Wed Aug 2 22:43:37 2006 From: rhudson at orcasinc.com (Rob Hudson) Date: Wed, 2 Aug 2006 13:43:37 -0700 Subject: [Pythonmac-SIG] py2app and Django Message-ID: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> Hello, I'm trying to bundle up a Django built website. Using SQLite and Django's built-in WSGI webserver, my thinking was that this would be 100% Python and would be straight forward to use py2app or py2exe on it. I'm not familiar enough with py2app to know whether the error I'm getting is related to py2app or related to Django. So I thought I'd post what I've done so far here for the list's guidance... I've followed the guide located here: http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html My directory is basically a straight download of Django-0.95 with the addition of 2 files. "run.py" which is my wrapper script to add Django to the Python path and kickstart the Django webserver. "py2app-setup.py" is named this way because Django already has a setup.py. This may change once I figure out the details but for now this is what I've done. ======= run.py: ======= #!/usr/bin/env python import sys, os sys.path.append(os.getcwd()) from Quotes.manage import * # We can also pass in host:port info to start server on. # Possibly add checks to see if port is open already and increment to next one # for the case of >1 app running simultaneously. execute_manager(settings, ['','runserver']) # NOTE: execute_manager takes over script control. If we want to fire up a # browser window we need to do that in another thread. # Now that server is running, open web browser? #import webbrowser #webbrowser.open_new('http://localhost:8000') ================ py2app-setup.py: ================ #!/usr/bin/env python from setuptools import setup setup( app=["run.py"], setup_requires=["py2app"], ) Also, "Quotes" is my dummy Django project and is a subdirectory under the Django-0.95 distribution. I run this command and include a few Django modules: python py2app-setup.py py2app -- includes=django.contrib.auth,django.contrib.sessions,django.contrib.site s When I run the resulting "run.app" from the command line, this is the error I get: # ./dist/run.app/Contents/MacOS/run Validating models... Unhandled exception in thread started by Traceback (most recent call last): File "django/core/management.pyc", line 1039, in inner_run File "django/core/management.pyc", line 1003, in validate File "django/core/management.pyc", line 815, in get_validation_errors File "django/db/__init__.pyc", line 18, in ? OSError: [Errno 20] Not a directory: '/Users/rhudson/Desktop/ Django-0.95/dist/run.app/Contents/Resources/lib/python2.3/site- packages.zip/django/db/backends' As an aside, you may be asking why do I want to make a website an application. I work for a company that builds health based education websites. Since some projects are funded by grant money, the phase one project needs to be reviewed to determine if the project is worthy of phase two money. The reviewers need to remain anonymous and we need to assume the reviewers do not have an internet connection. Therefore, we have to take our product (a website) and bundle it on a CD. This has led to many problems. We currently have a working solution for PHP based websites. Now, we are investigating Django as a new platform and I'm doing the initial testing on whether we can ship a Django website. Thanks, Rob -- Rob Hudson Senior Programmer Oregon Center for Applied Science http://www.orcasinc.com From bob at redivi.com Fri Aug 4 02:48:53 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 3 Aug 2006 17:48:53 -0700 Subject: [Pythonmac-SIG] py2app and Django In-Reply-To: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> References: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> Message-ID: <75DB3D62-2D23-4626-90DD-181A78E0D16E@redivi.com> On Aug 2, 2006, at 1:43 PM, Rob Hudson wrote: > I'm trying to bundle up a Django built website. Using SQLite and > Django's built-in WSGI webserver, my thinking was that this would be > 100% Python and would be straight forward to use py2app or py2exe > on it. > > I'm not familiar enough with py2app to know whether the error I'm > getting is related to py2app or related to Django. So I thought I'd > post what I've done so far here for the list's guidance... > > I've followed the guide located here: > http://svn.pythonmac.org/py2app/py2app/trunk/doc/index.html Django can not be packaged normally because it has in-package data files. It won't work with either py2exe or py2app without tweaking. It may Just Work (or come close to that) with the --packages option. It will definitely not work using any number of --includes options, because that's not the issue. --packages is not applicable to py2exe though. In that case, you'll need to place the django package next to your .exe and --exclude it so that it doesn't get picked up in the zip. -bob From treborhudson at gmail.com Fri Aug 4 05:47:37 2006 From: treborhudson at gmail.com (Rob Hudson) Date: Thu, 03 Aug 2006 20:47:37 -0700 Subject: [Pythonmac-SIG] py2app and Django Message-ID: <44D2C359.7050209@gmail.com> (My apologies if this starts a new thread -- I'm posting from a different mailing address and don't have the original email to reply to) > Django can not be packaged normally because it has in-package data > files. It won't work with either py2exe or py2app without tweaking. Can you point me to or help me understand what in-package data files are and why this affects it? > It may Just Work (or come close to that) with the --packages option. > It will definitely not work using any number of --includes options, > because that's not the issue. OK. I'll start experimenting with the --packages option. I feel like I've started to make significant progress. I've got a lot of the Django stack up and running but it looks like it is failing at getting some core parts of the database pieces loaded. I've been posting my progress on the Django mailing list here: http://groups.google.com/group/django-users/browse_thread/thread/609f539387ba8296 Thanks for the response. -Rob From ronaldoussoren at mac.com Fri Aug 4 07:08:13 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 4 Aug 2006 07:08:13 +0200 Subject: [Pythonmac-SIG] py2app and Django In-Reply-To: <44D2C359.7050209@gmail.com> References: <44D2C359.7050209@gmail.com> Message-ID: On Aug 4, 2006, at 5:47 AM, Rob Hudson wrote: > (My apologies if this starts a new thread -- I'm posting from a > different mailing address and don't have the original email to > reply to) > >> Django can not be packaged normally because it has in-package data >> files. It won't work with either py2exe or py2app without tweaking. > > Can you point me to or help me understand what in-package data > files are > and why this affects it? The exception you're getting: File "django/db/__init__.pyc", line 18, in ? OSError: [Errno 20] Not a directory: '/Users/rhudson/Desktop/ Django-0.95/dist/run.app/Contents/Resources/lib/python2.3/site- packages.zip/django/db/backends' This indicates that some part of django tries to do a directory listing of the directory containing django.db.backends. This can mean two things: one is that there are data files in that directory (configuration data, images, ...), the other is that some setup code tries to locate all modules in that package. With py2app and py2exe python code isn't stored directly in the filesystem but in zipfiles. Any code that tries to access the location where python code as if it were the filesystem will therefore fail. 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/20060804/03c5c523/attachment.bin From g.farina at pharaondev.com Fri Aug 4 09:08:04 2006 From: g.farina at pharaondev.com (Gabriele Farina) Date: Fri, 04 Aug 2006 09:08:04 +0200 Subject: [Pythonmac-SIG] Numeric on Intel In-Reply-To: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> References: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> Message-ID: <44D2F254.80204@pharaondev.com> Hi, I have some problems in running Numeric, numpy and numarray on my Intel iMac. This packages compile correclty, but they give me an import error when used. Where should be the problem ? Gabriele From ronaldoussoren at mac.com Fri Aug 4 09:36:19 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 04 Aug 2006 09:36:19 +0200 Subject: [Pythonmac-SIG] Numeric on Intel In-Reply-To: <44D2F254.80204@pharaondev.com> References: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> <44D2F254.80204@pharaondev.com> Message-ID: <13411696.1154676979436.JavaMail.ronaldoussoren@mac.com> On Friday, August 04, 2006, at 09:05AM, Gabriele Farina wrote: >Hi, > >I have some problems in running Numeric, numpy and numarray on my Intel >iMac. This packages compile correclty, but they give me an import error >when used. >Where should be the problem ? What is the traceback you get when you open a python shell and try to import numeric? What version of python are you using? Are you using Apple's python or have you installed some other version (the 2.4.3 universal installer at python.org/pythonmac.org, Python from Fink, Python from DarwinPorts, ...)? Ronald From g.farina at pharaondev.com Fri Aug 4 12:43:34 2006 From: g.farina at pharaondev.com (Gabriele Farina) Date: Fri, 04 Aug 2006 12:43:34 +0200 Subject: [Pythonmac-SIG] Numeric on Intel In-Reply-To: <13411696.1154676979436.JavaMail.ronaldoussoren@mac.com> References: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> <44D2F254.80204@pharaondev.com> <13411696.1154676979436.JavaMail.ronaldoussoren@mac.com> Message-ID: <44D324D6.1040409@pharaondev.com> Ronald Oussoren ha scritto: > > On Friday, August 04, 2006, at 11:55AM, Gabriele Farina wrote: > >> Ronald Oussoren ha scritto: >>> >>> On Friday, August 04, 2006, at 09:05AM, Gabriele Farina wrote: >>> >>>> Hi, >>>> >>>> I have some problems in running Numeric, numpy and numarray on my Intel >>>> iMac. This packages compile correclty, but they give me an import error >>>> when used. >>>> Where should be the problem ? >>> What is the traceback you get when you open a python shell and try to import numeric? >>> >>> What version of python are you using? Are you using Apple's python or have you installed some other version (the 2.4.3 universal installer at python.org/pythonmac.org, Python from Fink, Python from DarwinPorts, ...)? >>> >>> Ronald >>> >>> >> >> Hi, >> >> I'm using Python 2.4.1, installed using the universal DMG found (I >> think, I can't remeber it very well) on the python website. >> >> The exception raised when typing "import Numeric" is: >> >> ---- >> >> Traceback (most recent call last): >> File "", line 1, in ? >> File >> "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/Numeric/Numeric.py", >> line 91, in ? >> import multiarray >> ImportError: Inappropriate file type for dynamic loading >> ---- > > This seems to be an architecture mismatch. AFAIK the 2.4.1 installer you can find on the mac download page at python.org is not a universal binary installer, but PPC only. Could you please update to http://www.python.org/ftp/python/2.4.3/Universal-MacPython-2.4.3-2006-04-07.dmg to see if that solves your problem? At the very least python should get twice as fast :-) > > Ronald > > Ok, I'll istall this version and then I tell you if it works correctly From g.farina at pharaondev.com Fri Aug 4 12:52:20 2006 From: g.farina at pharaondev.com (Gabriele Farina) Date: Fri, 04 Aug 2006 12:52:20 +0200 Subject: [Pythonmac-SIG] Numeric on Intel In-Reply-To: <44D324D6.1040409@pharaondev.com> References: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> <44D2F254.80204@pharaondev.com> <13411696.1154676979436.JavaMail.ronaldoussoren@mac.com> <44D324D6.1040409@pharaondev.com> Message-ID: <44D326E4.7040603@pharaondev.com> I updated the python version, recompiled all the packages and it works correctly. thanks From ronaldoussoren at mac.com Fri Aug 4 13:30:24 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Fri, 04 Aug 2006 13:30:24 +0200 Subject: [Pythonmac-SIG] Numeric on Intel In-Reply-To: <44D326E4.7040603@pharaondev.com> References: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> <44D2F254.80204@pharaondev.com> <13411696.1154676979436.JavaMail.ronaldoussoren@mac.com> <44D324D6.1040409@pharaondev.com> <44D326E4.7040603@pharaondev.com> Message-ID: <13166482.1154691024727.JavaMail.ronaldoussoren@mac.com> On Friday, August 04, 2006, at 12:49PM, Gabriele Farina wrote: >I updated the python version, recompiled all the packages and it works >correctly. Great. I've also asked the python.org webmasters to change the download page, the 2.4.1 installer shouldn't be mentioned on the mac page. Ronald From Chris.Barker at noaa.gov Fri Aug 4 18:41:11 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 04 Aug 2006 09:41:11 -0700 Subject: [Pythonmac-SIG] Numeric on Intel In-Reply-To: <44D326E4.7040603@pharaondev.com> References: <2FA38133-266C-42F8-9D28-CBECD62B0E21@orcasinc.com> <44D2F254.80204@pharaondev.com> <13411696.1154676979436.JavaMail.ronaldoussoren@mac.com> <44D324D6.1040409@pharaondev.com> <44D326E4.7040603@pharaondev.com> Message-ID: <44D378A7.1080608@noaa.gov> Gabriele Farina wrote: > I updated the python version, recompiled all the packages and it works > correctly. FWIW, there are Universal packages for numpy, Numeric and numarray at: http://www.pythonmac.org/packages/py24-fat We've got to get that page more prominent! No newbies seem to find it. Ronald Oussoren wrote: > I've also asked the python.org webmasters to change the download page. That's a start. We also need to make sure the "Packages" page is easy to find when you go to the pythonmac.org main page. Bob, will you accept a patch to that page? -- it really needs updating. -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 Aug 4 20:08:01 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 4 Aug 2006 11:08:01 -0700 Subject: [Pythonmac-SIG] py2app and Django In-Reply-To: <44D2C359.7050209@gmail.com> References: <44D2C359.7050209@gmail.com> Message-ID: <4D5E2BF5-EC2E-4BD5-92BB-C7344DD77277@redivi.com> On Aug 3, 2006, at 8:47 PM, Rob Hudson wrote: > (My apologies if this starts a new thread -- I'm posting from a > different mailing address and don't have the original email to > reply to) > >> Django can not be packaged normally because it has in-package data >> files. It won't work with either py2exe or py2app without tweaking. > > Can you point me to or help me understand what in-package data > files are > and why this affects it? Python code is organized in packages. When on the filesystem normally, packages are a folder with an __init__.py file. In-package data files are files that live in one of those folders that isn't Python code. When applications are packaged the normal thing to do is to stuff all Python code into a single zip file. Programs that naively do things to package directories and files inside of them as if they were on the filesystem will not operate like that. There are ways to still work even in a zip file, but django clearly does not do that. >> It may Just Work (or come close to that) with the --packages option. >> It will definitely not work using any number of --includes options, >> because that's not the issue. > > OK. I'll start experimenting with the --packages option. There really isn't much experimenting you need to do, you probably just need to specify --packages=django and everything might start working (if django is laid out the way I think it is). You can also add that to your setup.py, as documented, so you don't have to remember to specify it as a command line option every time. A working setup script for py2app probably looks like this: from setuptools import setup setup( app=['run.py'], setup_requires=['py2app'], options=dict(py2app=dict( packages=['django'], )), ) -bob From gandreas at gandreas.com Fri Aug 4 20:32:08 2006 From: gandreas at gandreas.com (gandreas at gandreas.com) Date: Fri, 4 Aug 2006 13:32:08 -0500 Subject: [Pythonmac-SIG] ANN: ScrIDE 0.4 Message-ID: Version 0.4, the "PyOXIDE replacement" IDE is now available - it fixed several problems with 0.3, adds "context sensitive object info details" (to both the rich shells as well as debugger), and the ability to browse the variables in a rich shell (using a variable display like the debugger). ScrIDE is an extensible generic scripting IDE (currently focused on Python, though other scripting languages will eventually be further supported), including an editor with syntax coloring, popup function, included file popups, split panes, calltips, completion, etc... interactive shells (again, with completion, syntax coloring, object info), source level debugger, documentation browser, and other tools. Glenn Andreas gandreas at gandreas.com wicked fun! quadrium2 | build, mutate, evolve, animate | images, textures, fractals, art -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060804/ee1a057c/attachment.htm From bob at redivi.com Fri Aug 4 21:31:46 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 4 Aug 2006 12:31:46 -0700 Subject: [Pythonmac-SIG] py2app and Django In-Reply-To: <44D39B50.3090909@gmail.com> References: <44D2C359.7050209@gmail.com> <4D5E2BF5-EC2E-4BD5-92BB-C7344DD77277@redivi.com> <44D39B50.3090909@gmail.com> Message-ID: On Aug 4, 2006, at 12:09 PM, Rob Hudson wrote: > I appreciate the explanation and feedback. I tried what you > suggest and I can see that it does pull in the full django tree > which is much easier and better. > > This looks close but not quite there... > > Here's the latest py2app-setup.py: > > #!/usr/bin/env python > from setuptools import setup > setup( > app=["run.py"], > setup_requires=["py2app"], > options=dict(py2app=dict(packages=["django","Quotes"],)), > ) > > Now I simply run this from within the Django-0.95 directory: > python py2app-setup.py py2app > > And then launch Django: > # /dist/run.app/Contents/MacOS/run > Validating models... > Skipping validation because things aren't configured properly. > Django version 0.95, using settings 'Quotes.settings' > Development server is running at http://127.0.0.1:8000/ > Quit the server with CONTROL-C. > > Everytime the first page hit always produces the following error yet > concurrent page requests do not show this error. This seems very odd > to me and suggests something strange is happening in Django... At this point, using the packages option, you've got nearly the same filesystem layout as you would normally, so it's highly unlikely py2app has anything to do with the problems you've experiencing. Are you sure all of this stuff works outside of a packaged environment? It sounds like your problems don't really have anything to do with py2app at this point. The django list would be more appropriate; these errors won't make any sense to anyone that doesn't have intimate knowledge of django's source. -bob From treborhudson at gmail.com Fri Aug 4 21:38:41 2006 From: treborhudson at gmail.com (Rob Hudson) Date: Fri, 04 Aug 2006 12:38:41 -0700 Subject: [Pythonmac-SIG] py2app and Django In-Reply-To: References: <44D2C359.7050209@gmail.com> <4D5E2BF5-EC2E-4BD5-92BB-C7344DD77277@redivi.com> <44D39B50.3090909@gmail.com> Message-ID: <44D3A241.4050306@gmail.com> > At this point, using the packages option, you've got nearly the same > filesystem layout as you would normally, so it's highly unlikely py2app > has anything to do with the problems you've experiencing. That was my suspicion but I appreciate the feedback. > Are you sure all of this stuff works outside of a packaged environment? Yes. I just double checked and the /quote/ and /admin/ work just fine. > It sounds like your problems don't really have anything to do with > py2app at this point. The django list would be more appropriate; these > errors won't make any sense to anyone that doesn't have intimate > knowledge of django's source. Understood. I have already posted these errors on the django-users list. Since our goal is a cross platform solution, I may try the py2exe version on Windows and see if the same errors occur. Thanks again for the help, Rob From treborhudson at gmail.com Fri Aug 4 21:09:04 2006 From: treborhudson at gmail.com (Rob Hudson) Date: Fri, 04 Aug 2006 12:09:04 -0700 Subject: [Pythonmac-SIG] py2app and Django In-Reply-To: <4D5E2BF5-EC2E-4BD5-92BB-C7344DD77277@redivi.com> References: <44D2C359.7050209@gmail.com> <4D5E2BF5-EC2E-4BD5-92BB-C7344DD77277@redivi.com> Message-ID: <44D39B50.3090909@gmail.com> I appreciate the explanation and feedback. I tried what you suggest and I can see that it does pull in the full django tree which is much easier and better. This looks close but not quite there... Here's the latest py2app-setup.py: #!/usr/bin/env python from setuptools import setup setup( app=["run.py"], setup_requires=["py2app"], options=dict(py2app=dict(packages=["django","Quotes"],)), ) Now I simply run this from within the Django-0.95 directory: python py2app-setup.py py2app And then launch Django: # /dist/run.app/Contents/MacOS/run Validating models... Skipping validation because things aren't configured properly. Django version 0.95, using settings 'Quotes.settings' Development server is running at http://127.0.0.1:8000/ Quit the server with CONTROL-C. Everytime the first page hit always produces the following error yet concurrent page requests do not show this error. This seems very odd to me and suggests something strange is happening in Django... Traceback (most recent call last): File "django/core/servers/basehttp.pyc", line 272, in run File "django/core/servers/basehttp.pyc", line 615, in __call__ File "django/core/handlers/wsgi.pyc", line 143, in __call__ File "django/core/handlers/base.pyc", line 31, in load_middleware ImproperlyConfigured: Error importing middleware django.contrib.sessions.middleware: "cannot import name backend" [04/Aug/2006 13:49:45] "GET / HTTP/1.1" 500 409 Requesting "/" again gives me an approriate error since I don't have the urls.py configured to do anything for this, and so this appears to work as it should: [04/Aug/2006 13:49:50] "GET / HTTP/1.1" 404 1952 In the browser it shows this: Using the URLconf defined in Quotes.urls, Django tried these URL patterns, in this order: 1. ^quote/$ 2. ^admin/ The current URL, /, didn't match any of these. If I try to hit my "/quote/" page I get a 500 error at the terminal: [04/Aug/2006 13:52:50] "GET /quote/ HTTP/1.1" 500 25750 this error in the browser: ViewDoesNotExist at /quote/ Tried index in module Quotes.quotes.views. Error was: 'module' object has no attribute 'Model' Request Method: GET Request URL: http://localhost:8000/quote/ Exception Type: ViewDoesNotExist Exception Value: Tried index in module Quotes.quotes.views. Error was: 'module' object has no attribute 'Model' Exception Location: in ?, line ? I do have an index method in my quotes/views.py and this works outside of py2app. The error message is a bit confusing to me. Trying "/admin/" I get another 500 error and the following: ImportError at /admin/ No module named urls Request Method: GET Request URL: http://localhost:8000/admin/ Exception Type: ImportError Exception Value: No module named urls Exception Location: in ?, line ? Looking at the py2app output I can verify that django.contrib.admin.urls is being pulled in. I'm feeling like this is close. Django successfully reports a 404. But it is having trouble with my app and the admin so some parts seem to be missing. Thanks, Rob From bob at redivi.com Fri Aug 4 22:12:03 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 4 Aug 2006 13:12:03 -0700 Subject: [Pythonmac-SIG] ANN: ScrIDE 0.4 In-Reply-To: References: Message-ID: <57901265-FE7F-49B7-AE66-8D01EDAACD2C@redivi.com> On Aug 4, 2006, at 11:32 AM, gandreas at gandreas.com wrote: > Version 0.4, the "PyOXIDE replacement" IDE is now available - it > fixed several problems with 0.3, adds "context sensitive object > info details" (to both the rich shells as well as debugger), and > the ability to browse the variables in a rich shell (using a > variable display like the debugger). > > ScrIDE is an extensible generic scripting IDE (currently focused on > Python, though other scripting languages will eventually be further > supported), including an editor with syntax coloring, popup > function, included file popups, split panes, calltips, completion, > etc... interactive shells (again, with completion, syntax coloring, > object info), source level debugger, documentation browser, and > other tools. It might make more sense if ScrIDE's default Python interpreter was the newest one installed, rather than the system default. Typically if someone has Python 2.4 installed, they don't want anything to do with the Python 2.3 in /usr/bin. Also, you really shouldn't mix tabs and spaces in your source code. Ick. -bob From gandreas at gandreas.com Fri Aug 4 22:57:34 2006 From: gandreas at gandreas.com (gandreas at gandreas.com) Date: Fri, 4 Aug 2006 15:57:34 -0500 Subject: [Pythonmac-SIG] ANN: ScrIDE 0.4 In-Reply-To: <57901265-FE7F-49B7-AE66-8D01EDAACD2C@redivi.com> References: <57901265-FE7F-49B7-AE66-8D01EDAACD2C@redivi.com> Message-ID: On Aug 4, 2006, at 3:12 PM, Bob Ippolito wrote: > > On Aug 4, 2006, at 11:32 AM, gandreas at gandreas.com wrote: > >> Version 0.4, the "PyOXIDE replacement" IDE is now available - it >> fixed several problems with 0.3, adds "context sensitive object >> info details" (to both the rich shells as well as debugger), and >> the ability to browse the variables in a rich shell (using a >> variable display like the debugger). >> >> ScrIDE is an extensible generic scripting IDE (currently focused >> on Python, though other scripting languages will eventually be >> further supported), including an editor with syntax coloring, >> popup function, included file popups, split panes, calltips, >> completion, etc... interactive shells (again, with completion, >> syntax coloring, object info), source level debugger, >> documentation browser, and other tools. > > It might make more sense if ScrIDE's default Python interpreter was > the newest one installed, rather than the system default. Typically > if someone has Python 2.4 installed, they don't want anything to do > with the Python 2.3 in /usr/bin. > ScrIDE uses whatever you last explicitly set as your Python version for anything that doesn't have an explicit version set (so if you change it to "local 2.4", all future files and files that you haven't set your version will use "local 2.4"). So you'd typically only have to change that once (in general, everything follows the "if something is explicitly set and saved, it stays like that until changed - if nothing is explicitly set, it uses whatever was last explicitly set") Still, changing the order of the elements in ScrIDEVersionPrefixList (found in the Python plugin Info.plist) to alter the search order is trivial. Of course, this assume a fully logical search order exists - should a locally installed (but potentially unstable) 2.5 be preferred over a locally installed (but stable) 2.4? And what about a system provided 2.4 that might be found in some future release? And since I've needed at times to do Quartz scripting, saying "don't want anything to do with 2.3" isn't entirely accurate either... > Also, you really shouldn't mix tabs and spaces in your source code. > Ick. I'm going to blame that fuglyness on XCode (one of the many reasons I hate editing Python code in XCode) - it's impractical to use ScrIDE to edit its own code because to do the "edit, build, run" cycle you'd have to close and reopen all your files each cycle (and if something bad breaks, you won't be able to reopen the files at all), and trying to run with two different versions of the same app is a invitation to certain madness... Glenn Andreas gandreas at gandreas.com wicked fun! quadrium2 | build, mutate, evolve, animate | images, textures, fractals, art From Chris.Barker at noaa.gov Fri Aug 4 23:01:39 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Fri, 04 Aug 2006 14:01:39 -0700 Subject: [Pythonmac-SIG] ANN: ScrIDE 0.4 In-Reply-To: <57901265-FE7F-49B7-AE66-8D01EDAACD2C@redivi.com> References: <57901265-FE7F-49B7-AE66-8D01EDAACD2C@redivi.com> Message-ID: <44D3B5B3.2020300@noaa.gov> Bob Ippolito wrote: > Also, you really shouldn't mix tabs and spaces in your source code. Ick. I haven't looked at ScrIDE yet, but it shouldn't allow mixed tabs and spaces at all. In fact, it really should ONLY allow spaces. That is the Python standard now. -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 gandreas at gandreas.com Fri Aug 4 23:10:14 2006 From: gandreas at gandreas.com (gandreas at gandreas.com) Date: Fri, 4 Aug 2006 16:10:14 -0500 Subject: [Pythonmac-SIG] ANN: ScrIDE 0.4 In-Reply-To: <44D3B5B3.2020300@noaa.gov> References: <57901265-FE7F-49B7-AE66-8D01EDAACD2C@redivi.com> <44D3B5B3.2020300@noaa.gov> Message-ID: On Aug 4, 2006, at 4:01 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> Also, you really shouldn't mix tabs and spaces in your source >> code. Ick. > > I haven't looked at ScrIDE yet, but it shouldn't allow mixed tabs and > spaces at all. In fact, it really should ONLY allow spaces. That is > the > Python standard now. ScrIDE is designed for more than just Python, though, but language specific tab handling "rules" are definitely something worth adding (currently you can explicitly say if you want tabs or spaces when saving to a file as a global setting). Glenn Andreas gandreas at gandreas.com wicked fun! quadrium2 | build, mutate, evolve, animate | images, textures, fractals, art From bob at redivi.com Fri Aug 4 23:28:35 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 4 Aug 2006 14:28:35 -0700 Subject: [Pythonmac-SIG] ANN: ScrIDE 0.4 In-Reply-To: References: <57901265-FE7F-49B7-AE66-8D01EDAACD2C@redivi.com> Message-ID: <0D18FFBC-972B-44D2-A205-8C61BC382921@redivi.com> On Aug 4, 2006, at 1:57 PM, gandreas at gandreas.com wrote: > > On Aug 4, 2006, at 3:12 PM, Bob Ippolito wrote: > >> >> On Aug 4, 2006, at 11:32 AM, gandreas at gandreas.com wrote: >> >>> Version 0.4, the "PyOXIDE replacement" IDE is now available - it >>> fixed several problems with 0.3, adds "context sensitive object >>> info details" (to both the rich shells as well as debugger), and >>> the ability to browse the variables in a rich shell (using a >>> variable display like the debugger). >>> >>> ScrIDE is an extensible generic scripting IDE (currently focused >>> on Python, though other scripting languages will eventually be >>> further supported), including an editor with syntax coloring, >>> popup function, included file popups, split panes, calltips, >>> completion, etc... interactive shells (again, with completion, >>> syntax coloring, object info), source level debugger, >>> documentation browser, and other tools. >> >> It might make more sense if ScrIDE's default Python interpreter >> was the newest one installed, rather than the system default. >> Typically if someone has Python 2.4 installed, they don't want >> anything to do with the Python 2.3 in /usr/bin. >> > > ScrIDE uses whatever you last explicitly set as your Python version > for anything that doesn't have an explicit version set (so if you > change it to "local 2.4", all future files and files that you > haven't set your version will use "local 2.4"). So you'd typically > only have to change that once (in general, everything follows the > "if something is explicitly set and saved, it stays like that until > changed - if nothing is explicitly set, it uses whatever was last > explicitly set") > > Still, changing the order of the elements in > ScrIDEVersionPrefixList (found in the Python plugin Info.plist) to > alter the search order is trivial. Of course, this assume a fully > logical search order exists - should a locally installed (but > potentially unstable) 2.5 be preferred over a locally installed > (but stable) 2.4? And what about a system provided 2.4 that might > be found in some future release? The most logical default is to pick the one that is first on their $PATH according to their shell preferences. I guess something like this would work (when properly translated to Cocoa): $SHELL -c 'which python' That should *always* return a Python interpreter. Past that I'd look for the system interpreter, darwinports, fink, and /usr/local/bin. If you really wanted to you could start searching for framework installs, and checking PATH for various version numbers (python2.X). > And since I've needed at times to do Quartz scripting, saying > "don't want anything to do with 2.3" isn't entirely accurate either... I said typically... >> Also, you really shouldn't mix tabs and spaces in your source >> code. Ick. > > I'm going to blame that fuglyness on XCode (one of the many reasons > I hate editing Python code in XCode) - it's impractical to use > ScrIDE to edit its own code because to do the "edit, build, run" > cycle you'd have to close and reopen all your files each cycle (and > if something bad breaks, you won't be able to reopen the files at > all), and trying to run with two different versions of the same app > is a invitation to certain madness... Well, the first thing you should do when editing Python code anywhere is to make sure the editor is using the right settings. Xcode has a settings to use 4-space tabs. -bob From bob at redivi.com Fri Aug 4 23:29:50 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 4 Aug 2006 14:29:50 -0700 Subject: [Pythonmac-SIG] ANN: ScrIDE 0.4 In-Reply-To: <44D3B5B3.2020300@noaa.gov> References: <57901265-FE7F-49B7-AE66-8D01EDAACD2C@redivi.com> <44D3B5B3.2020300@noaa.gov> Message-ID: On Aug 4, 2006, at 2:01 PM, Christopher Barker wrote: > Bob Ippolito wrote: >> Also, you really shouldn't mix tabs and spaces in your source >> code. Ick. > > I haven't looked at ScrIDE yet, but it shouldn't allow mixed tabs and > spaces at all. In fact, it really should ONLY allow spaces. That is > the > Python standard now. I was talking about the source code *to* ScrIDE. I didn't try and use it to write any. -bob From jerry.levan at eku.edu Fri Aug 4 23:47:26 2006 From: jerry.levan at eku.edu (Jerry LeVan) Date: Fri, 4 Aug 2006 17:47:26 -0400 Subject: [Pythonmac-SIG] ScrIDE problem.... In-Reply-To: References: Message-ID: <1F5A76E5-1193-428C-A90C-4BDD57E14A65@eku.edu> > From: gandreas at gandreas.com > Date: August 4, 2006 2:32:08 PM EDT > To: PythonMac > Subject: [Pythonmac-SIG] ANN: ScrIDE 0.4 > > > Version 0.4, the "PyOXIDE replacement" IDE is now available - it > fixed several problems with 0.3, adds "context sensitive object > info details" (to both the rich shells as well as debugger), and > the ability to browse the variables in a rich shell (using a > variable display like the debugger). > > ScrIDE is an extensible generic scripting IDE (currently focused on > Python, though other scripting languages will eventually be further > supported), including an editor with syntax coloring, popup > function, included file popups, split panes, calltips, completion, > etc... interactive shells (again, with completion, syntax coloring, > object info), source level debugger, documentation browser, and > other tools. > > > > > > Glenn Andreas gandreas at gandreas.com > wicked fun! > quadrium2 | build, mutate, evolve, animate | images, textures, > fractals, art > > The following fails... (The file name is PyPgExplorer.py ) #!/usr/bin/env python from Tkinter import * import Resources.PyPgBrowse as PyPgBrowse <-- This line obj=PyPgBrowse.PgBrowser(True) obj.main() mainloop() The error is an import error "No Module Named Resources.PyPgBrowse Resources is a folder in the directory containing PyPgExplorer.py. ScrIDE is the only "thing" that can't launch the app. You can download the whole app from http://homepage.mac.com/levanj/ Python Jerry From hengist.podd at virgin.net Sat Aug 5 14:14:41 2006 From: hengist.podd at virgin.net (has) Date: Sat, 5 Aug 2006 13:14:41 +0100 Subject: [Pythonmac-SIG] appscript questions In-Reply-To: References: Message-ID: <07077307-183B-4858-9CD0-370016CD9D7A@virgin.net> Nicholas Riley wrote: > I agree - if the app quits, it should stay quit. Sometimes when I'm > trying to abort a script I quit an app that's being controlled, and to > see it relaunch over and over and over again... aaargh. OK. Plan is that: 1. run() and launch() will be allowed to relaunch an application that's been quit; any other event will result in an error. I've not decided if open() should also be given special rights; any preferences? 2. When appscript launches an app, a 'run' event is automatically sent (part of the normal LaunchApplication behaviour) except where the user calls launch() first, in which a 'launch' (no-op) event is sent instead. >> - Do away with ASTS completely > > I'd say to do the first one, and if you get complaints, move to the > second one. I got very confused about the role of ASTS in remote > scripting myself (you may remember an email I sent you that effect > :-), and at least in my case I don't use appscript for small scripts, > I use it primarily for faceless background apps, so it wouldn't > matter. OK, ASTS is gone. I've got a plan for implementing a file-based external cache should it be needed, but we'll see how the next release goes. If folk find cold starts are still noticably slow they can let me know. >> 3. Should appscript's built-in help() use textwrap to automatically >> wrap long lines to fit in a standard 80-column terminal window? > > How about wrapping to the terminal width, whatever it happens to be? I've left things as-is (i.e. Terminal, etc. can do their own line wrapping). ------- Ronald Oussoren wrote: >> p.s. If anyone'd like to help me out a bit, I'd really like to get >> all the manuals into the standard Python documentation format now. > > Why do you want to do that? You have to use special tools to > convert that to a useable format. If the Python format sucks to use I'll happily take suggestions for a better one. Any decent documentation authoring/generation system will do. Don't much mind what it is as long as it's easy to use and generates good looking HTML and (ideally) man pages with auto- generated navigation links in the HMTL version (indexing would also be nice, though not required). ------- Dethe Elza wrote: > And if you're trying to get docs into the standard library, those > folks are perfectly willing to take plaintext documentation and > dress it up in LaTeX themselves. Nope, no plans to put appscript into the standard library; like Bob, I'd rather see the Mac-specific stuff moved out. Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Sat Aug 5 15:01:52 2006 From: hengist.podd at virgin.net (has) Date: Sat, 5 Aug 2006 14:01:52 +0100 Subject: [Pythonmac-SIG] ANN: ScrIDE 0.4 In-Reply-To: References: Message-ID: Christopher Barker wrote: >> Also, you really shouldn't mix tabs and spaces in your source >> code. Ick. > > I haven't looked at ScrIDE yet, but it shouldn't allow mixed tabs > and spaces at all. In fact, it really should ONLY allow spaces. > That is the Python standard now. The smart thing would be tabs for editing and display, and spaces for saving, with automatic normalisation of both types of files upon opening. (The editor should also allow the user to type either one tab or four spaces to make one indent to keep everyone happy.) Space-based indentation sucks for on-screen display in modern GUI environments (e.g. space-based indents are totally unreadable when displayed in proportional fonts, and a waste of a good semantics- aware text view). At the same time you don't want to write tab- indented files as having two different file formats in circulation has compatibility issues. i.e. The user should never have to think about space-vs-tab issues: things should 'just work'. It's the taking care of annoying tedious housekeeping chores that separates the IDEs from the Notepads, after all. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From marcink at ieee.org Sun Aug 6 16:57:56 2006 From: marcink at ieee.org (Marcin Komorowski) Date: Sun, 6 Aug 2006 10:57:56 -0400 Subject: [Pythonmac-SIG] appscript with todos in iCal seams very slow Message-ID: Hey All, I am trying to generate a python internal structure (a dictionary of dictionaries) with a copy of all todo data from iCal. I got it to work using the following code: > #!/usr/bin/env /usr/bin/pythonw > > from appscript import * > from sys import stdout > > appCal = app( 'iCal' ) > todos = appCal.calendars.filter(its.title != '').todos > > # Iterate flattened list, builing a local dictionary of > dictionaries, by uid > local_tasks = {} > for task in [ todo for cal in todos() for todo in cal ]: > uid = task.uid.get() > local_tasks[uid] = { > "completion_date" : task.completion_date.get(), > "due_date" : task.due_date.get(), > "priority" : task.priority.get(), > "sequence" : task.sequence.get(), > "stamp_date" : task.stamp_date.get(), > "summary" : task.summary.get(), > "description" : task.description.get(), > "uid" : task.uid.get(), > "url" : task.url.get(), > } > stdout.write('.') > stdout.flush() > > stdout.write('\n') > > print repr( local_tasks ) > > stdout.write( "%d tasks\n" % len( local_tasks ) ) The problem is that this appears to execute painstakingly slowly. With 60 todo items in my iCal, the script takes just over 10 seconds to run. My machine i a 2GHz Intel Core Duo iMac. Any idea how this could be sped up? Thank You, Marcin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060806/1897b558/attachment.html From hraban at fiee.net Sun Aug 6 18:13:09 2006 From: hraban at fiee.net (Henning Hraban Ramm) Date: Sun, 6 Aug 2006 18:13:09 +0200 Subject: [Pythonmac-SIG] appscript with todos in iCal seams very slow In-Reply-To: References: Message-ID: Am 2006-08-06 um 16:57 schrieb Marcin Komorowski: > I am trying to generate a python internal structure (a dictionary > of dictionaries) with a copy of all todo data from iCal. I got it > to work using the following code: > > The problem is that this appears to execute painstakingly slowly. > With 60 todo items in my iCal, the script takes just over 10 > seconds to run. My machine i a 2GHz Intel Core Duo iMac. > > Any idea how this could be sped up? Just work with the calendar files directly, there are even Python libraries for that, e.g. itools: http://www.ikaaro.org/itools (Never worked with that, don't ask me.) Greetlings from Lake Constance! Hraban --- http://www.fiee.net http://www.cacert.org (I'm an assurer) From hengist.podd at virgin.net Mon Aug 7 01:05:21 2006 From: hengist.podd at virgin.net (has) Date: Mon, 7 Aug 2006 00:05:21 +0100 Subject: [Pythonmac-SIG] appscript with todos in iCal seams very slow Message-ID: Marcin Komorowski wrote: > I am trying to generate a python internal structure (a dictionary of > dictionaries) with a copy of all todo data from iCal. I got it to > work using the following code: > [...] > The problem is that this appears to execute painstakingly slowly. Apple event IPC is fairly expensive; asking applications to resolve lots of object model 'references' (i.e. queries) especially so. Sending a few complex queries is usually much, much quicker than sending lots of simple ones, e.g. the following will pull all property values from all todos in a single go: todos = appCal.calendars.filter(its.name != '').todos.properties() You can then rearrange this data in Python to suit your needs. There's more information in the appscript manual: chapters 2 and 3 discuss how Apple events and the Apple Event Object Model work; chapter 12 discusses various optimisation techniques for getting good performance out of the system. HTH has -- http://freespace.virgin.net/hamish.sanderson/ From marcink at ieee.org Tue Aug 8 02:49:08 2006 From: marcink at ieee.org (Marcin Komorowski) Date: Mon, 7 Aug 2006 20:49:08 -0400 Subject: [Pythonmac-SIG] appscript with todos in iCal seams very slow In-Reply-To: References: Message-ID: <258288DB-DF43-4C67-99C9-6F6E34C58DCE@ieee.org> Thanks Has, this definitely did the trick. I guess when I get to updating individual values in selected todos records, I will have to use a relatively slow request-per-update method. Is there a trick to update a field of a todo with a given uid in a single request? Thanks, Marcin On 6-Aug-06, at 7:05 PM, has wrote: > Marcin Komorowski wrote: > >> I am trying to generate a python internal structure (a dictionary of >> dictionaries) with a copy of all todo data from iCal. I got it to >> work using the following code: >> [...] >> The problem is that this appears to execute painstakingly slowly. > > Apple event IPC is fairly expensive; asking applications to resolve > lots of object model 'references' (i.e. queries) especially so. > Sending a few complex queries is usually much, much quicker than > sending lots of simple ones, e.g. the following will pull all > property values from all todos in a single go: > > todos = appCal.calendars.filter(its.name != > '').todos.properties() > > You can then rearrange this data in Python to suit your needs. > > There's more information in the appscript manual: chapters 2 and 3 > discuss how Apple events and the Apple Event Object Model work; > chapter 12 discusses various optimisation techniques for getting good > performance out of the system. > > HTH > > has > -- > http://freespace.virgin.net/hamish.sanderson/ > > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From glassfordm at hotmail.com Tue Aug 8 15:57:57 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Tue, 08 Aug 2006 09:57:57 -0400 Subject: [Pythonmac-SIG] [py2app] "An unexpected error has occurred during execution of the main script" Message-ID: I get this error running a py2app alias build (one built with option alias=True) of an application, with the additional information "AttributeError: 'NoneType' object has no attribute 'endswith'; See the Console for a detailed traceback." However, no additional information is written to the console. This alias build had been working for a long time. As far as I know, there have been no recent configuration changes that should cause this problem. If I make a non-alias build, it runs as it should. As far as I can tell, this error happens before site.py, __boot.py__ are executed: if I put print statements at the top of these files, nothing is printed. I suppose that's what "during execution of the main script" means? So my question is, how do I debug what's causing this problem? Mike From hengist.podd at virgin.net Tue Aug 8 17:50:33 2006 From: hengist.podd at virgin.net (has) Date: Tue, 8 Aug 2006 16:50:33 +0100 Subject: [Pythonmac-SIG] appscript with todos in iCal seams very slow In-Reply-To: <258288DB-DF43-4C67-99C9-6F6E34C58DCE@ieee.org> References: <258288DB-DF43-4C67-99C9-6F6E34C58DCE@ieee.org> Message-ID: On 8 Aug 2006, at 01:49, Marcin Komorowski wrote: > I guess when I get to updating individual values in selected todos > records, I will have to use a relatively slow request-per-update > method. Is there a trick to update a field of a todo with a given > uid in a single request? You can set multiple properties in a single command by assigning a record containing values for the properties you want to change to the 'properties' property, e.g.: myevent.properties.set({k.start_time: t1, k.end_time: t2}) If you have a multi-object reference, you can assign the same value to properties in all of those objects using a single 'set' command, e.g.: mycalendar.todos.priority.set(k.high_priority) That's about the limit of it though, e.g. if you've got a list of references or want to assign different values to each then you have to do them individually. BTW, the next version of appscript has a number of performance improvements that should speed things up a bit at the Python end. I'll have a copy up shortly. has -- http://freespace.virgin.net/hamish.sanderson/ From hengist.podd at virgin.net Tue Aug 8 22:03:19 2006 From: hengist.podd at virgin.net (has) Date: Tue, 8 Aug 2006 21:03:19 +0100 Subject: [Pythonmac-SIG] appscript 0.16.0 source release Message-ID: <5C3032ED-2BBE-4FBA-AB99-108C28CC8521@virgin.net> Hi folks, I've posted the source for appscript 0.16.0 at: http://freespace.virgin.net/hamish.sanderson/appscript_source.html There's some API breakage in this version while I tidy stuff up (I want to freeze the aem and appscript APIs shortly) and a whole heap of other changes including bug fixes and performance optimisations, so I'd appreciate it if folks here could give it a bit of a whirl before I do the proper binary release. Please see the readme file for more details. ... Also, one more query: anyone have any strong opinions on whether I should stick with the current built-in type names (k.Integer, k.Float, k.String, k.Unicode, etc.) or switch to AppleScript- equivalents (k.integer, k.real, k.string, k.Unicode_text, etc.)? - Switching would simplify standardisation, especially if appscript gets ported to other platforms, since everyone is on the same wavelength. It also makes sdefs a bit easier to parse, since you only need to escape existing type names instead of converting them from AS keywords to AE codes to custom type names. - OTOH, folk may prefer that type and class names are easier to tell apart by their capitalisation (e.g. k.Type and k.document_file are more obviously different than k.value_class and k.document_file). Thanks, has -- http://freespace.virgin.net/hamish.sanderson/ From bob at redivi.com Tue Aug 8 22:11:17 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 8 Aug 2006 13:11:17 -0700 Subject: [Pythonmac-SIG] [py2app] "An unexpected error has occurred during execution of the main script" In-Reply-To: References: Message-ID: On Aug 8, 2006, at 6:57 AM, Michael Glassford wrote: > I get this error running a py2app alias build (one built with option > alias=True) of an application, with the additional information > "AttributeError: 'NoneType' object has no attribute 'endswith'; See > the > Console for a detailed traceback." However, no additional > information is > written to the console. There will be a full traceback on the console. This means either the terminal it was started from, or console.log. > This alias build had been working for a long time. As far as I know, > there have been no recent configuration changes that should cause this > problem. If I make a non-alias build, it runs as it should. > > As far as I can tell, this error happens before site.py, > __boot.py__ are > executed: if I put print statements at the top of these files, nothing > is printed. I suppose that's what "during execution of the main > script" > means? No that's not what it means. Chances are, you just aren't looking for the print output in the right place. > So my question is, how do I debug what's causing this problem? Figure out where the stdout is going. I can't help you without a reproducible example or at least a traceback to look at. Also, versions are useful information too (OS, Python, py2app). -bob From glassfordm at gmail.com Tue Aug 8 22:42:59 2006 From: glassfordm at gmail.com (Michael Glassford) Date: Tue, 08 Aug 2006 16:42:59 -0400 Subject: [Pythonmac-SIG] [py2app] "An unexpected error has occurred during execution of the main script" In-Reply-To: References: Message-ID: <44D8F753.5080204@hotmail.com> Bob Ippolito wrote: > On Aug 8, 2006, at 6:57 AM, Michael Glassford wrote: > >> I get this error running a py2app alias build (one built with option >> alias=True) of an application, with the additional information >> "AttributeError: 'NoneType' object has no attribute 'endswith'; See >> the >> Console for a detailed traceback." However, no additional >> information is >> written to the console. > > There will be a full traceback on the console. This means either the > terminal it was started from, or console.log. I figured out my problem. I was opening the Console application, but somehow I had switched it to look at the wrong log file without realizing it (it almost always opens automatically to console.log, since that's the log file I'm almost always interested in). As I expected, once I was able to look at the traceback it was easy to fix the problem. Thanks for the reply, Mike From glassfordm at hotmail.com Tue Aug 8 22:42:59 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Tue, 08 Aug 2006 16:42:59 -0400 Subject: [Pythonmac-SIG] [py2app] "An unexpected error has occurred during execution of the main script" In-Reply-To: References: Message-ID: <44D8F753.5080204@hotmail.com> Bob Ippolito wrote: > On Aug 8, 2006, at 6:57 AM, Michael Glassford wrote: > >> I get this error running a py2app alias build (one built with option >> alias=True) of an application, with the additional information >> "AttributeError: 'NoneType' object has no attribute 'endswith'; See >> the >> Console for a detailed traceback." However, no additional >> information is >> written to the console. > > There will be a full traceback on the console. This means either the > terminal it was started from, or console.log. I figured out my problem. I was opening the Console application, but somehow I had switched it to look at the wrong log file without realizing it (it almost always opens automatically to console.log, since that's the log file I'm almost always interested in). As I expected, once I was able to look at the traceback it was easy to fix the problem. Thanks for the reply, Mike From glassfordm at hotmail.com Tue Aug 8 23:34:07 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Tue, 08 Aug 2006 17:34:07 -0400 Subject: [Pythonmac-SIG] [pyobjc] FYI: Build error; setuptools egg missing Message-ID: I just got the PyObjC trunk from svn. When I try to build it ("$PYTHON setup.py build"), I get the error at the end of this message. The specified url, "http://cheeseshop.python.org/packages/2.5/s/setuptools/setuptools-0.6c1-py2.5.egg", is in fact invalid: there's no setuptools directory. Mike --------------------------------------------------------------------------- This script requires setuptools version 0.6c1 to run (even to display help). I will attempt to download it for you (from http://cheeseshop.python.org/packages/2.5/s/setuptools/), but you may need to enable firewall access for this script first. I will start the download in 15 seconds. (Note: if this machine does not have network access, please obtain the file http://cheeseshop.python.org/packages/2.5/s/setuptools/setuptools-0.6c1-py2.5.egg and place it in this directory before rerunning this script.) --------------------------------------------------------------------------- Downloading http://cheeseshop.python.org/packages/2.5/s/setuptools/setuptools-0.6c1-py2.5.egg Traceback (most recent call last): File "setup.py", line 4, in ez_setup.use_setuptools() File "/Users/mjg/Desktop/develop/pyobjc/trunk/pyobjc/ez_setup/__init__.py", line 72, in use_setuptools egg = download_setuptools(version, download_base, to_dir, download_delay) File "/Users/mjg/Desktop/develop/pyobjc/trunk/pyobjc/ez_setup/__init__.py", line 126, in download_setuptools src = urllib2.urlopen(url) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 121, in urlopen return _opener.open(url, data) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 380, in open response = meth(req, response) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 491, in http_response 'http', request, response, code, msg, hdrs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 418, in error return self._call_chain(*args) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 353, in _call_chain result = func(*args) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/urllib2.py", line 499, in http_error_default raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) urllib2.HTTPError: HTTP Error 404: Not Found Michael-Glassfords-Computer:/users/mjg/desktop/develop/pyobjc/trunk/pyobjc mjg$ From bob at redivi.com Wed Aug 9 00:00:39 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 8 Aug 2006 15:00:39 -0700 Subject: [Pythonmac-SIG] [pyobjc] FYI: Build error; setuptools egg missing In-Reply-To: References: Message-ID: <4F366E2C-D5C0-4FD1-B454-2E80B317E360@redivi.com> On Aug 8, 2006, at 2:34 PM, Michael Glassford wrote: > I just got the PyObjC trunk from svn. When I try to build it ("$PYTHON > setup.py build"), I get the error at the end of this message. The > specified url, > "http://cheeseshop.python.org/packages/2.5/s/setuptools/ > setuptools-0.6c1-py2.5.egg", > is in fact invalid: there's no setuptools directory. You need to manually install setuptools 0.7 from the trunk when using Python 2.5. http://svn.python.org/projects/sandbox/trunk/setuptools -bob From brad at allendev.com Wed Aug 9 00:08:11 2006 From: brad at allendev.com (Brad Allen) Date: Tue, 8 Aug 2006 15:08:11 -0700 Subject: [Pythonmac-SIG] 06 WWDC and Python? In-Reply-To: <80B27A94-7FBC-4166-9CCF-1BCC60BDF4F2@mac.com> References: <80B27A94-7FBC-4166-9CCF-1BCC60BDF4F2@mac.com> Message-ID: At 3:01 PM -0700 7/8/06, Bill Bumgarner wrote: >On Jul 8, 2006, at 1:12 AM, Bob Ippolito wrote: > > On Jul 8, 2006, at 12:08 AM, DeanG wrote: > >> Is there any formal or informal Python related activities at WWDC > >> this year? > > > > I don't know of anything planned yet, and I don't think there's > > anything formal. We could definitely arrange for something informal > > though -- beer somewhere. Bill would probably be the best person to > > herd the cats... I can send the word out to a few others in the > > city once we have a plan. > >There is always Tommy's on Saturday and Wednesday. Usually there is >a BOF or something on one of the other nights. I haven't seen any BOF sessions or events on the WWDC schedule this year... There is a Python/Ruby related session on Friday morning at 9am. "Using Python and Ruby to Build Cocoa Applications". From marcink at ieee.org Wed Aug 9 15:05:07 2006 From: marcink at ieee.org (Marcin Komorowski) Date: Wed, 9 Aug 2006 09:05:07 -0400 Subject: [Pythonmac-SIG] appscript with todos in iCal seams very slow In-Reply-To: References: <258288DB-DF43-4C67-99C9-6F6E34C58DCE@ieee.org> Message-ID: Has, Thank you. Unfortunately, I have a list of UIDs for the todos I want to modify, so I think the best I can do is: for uid in uid_list: todo = [ t for t in app('iCal').calendars.todos.filter( its.uid == uid ).get() if t != k.MissingValue ][0] todo.stamp_date.set( datetime.datetime.today() ) Still, the list is never long so the script runs relatively fast. My largest bottleneck was getting the original list of all todos and their properties, and your previous suggestion made a huge difference in execution speed. Thank You, Marcin On 8-Aug-06, at 11:50 AM, has wrote: > On 8 Aug 2006, at 01:49, Marcin Komorowski wrote: > >> I guess when I get to updating individual values in selected todos >> records, I will have to use a relatively slow request-per-update >> method. Is there a trick to update a field of a todo with a given >> uid in a single request? > > You can set multiple properties in a single command by assigning a > record containing values for the properties you want to change to the > 'properties' property, e.g.: > > myevent.properties.set({k.start_time: t1, k.end_time: t2}) > > If you have a multi-object reference, you can assign the same value > to properties in all of those objects using a single 'set' command, > e.g.: > > mycalendar.todos.priority.set(k.high_priority) > > > That's about the limit of it though, e.g. if you've got a list of > references or want to assign different values to each then you have > to do them individually. > > BTW, the next version of appscript has a number of performance > improvements that should speed things up a bit at the Python end. > I'll have a copy up shortly. > > has > -- > http://freespace.virgin.net/hamish.sanderson/ > > > _______________________________________________ > 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/20060809/42f9d0a1/attachment.htm From glassfordm at gmail.com Wed Aug 9 19:07:38 2006 From: glassfordm at gmail.com (Michael Glassford) Date: Wed, 09 Aug 2006 13:07:38 -0400 Subject: [Pythonmac-SIG] [pyobjc] FYI: Build error; setuptools egg missing In-Reply-To: <4F366E2C-D5C0-4FD1-B454-2E80B317E360@redivi.com> References: <4F366E2C-D5C0-4FD1-B454-2E80B317E360@redivi.com> Message-ID: <44DA165A.2000401@hotmail.com> Bob Ippolito wrote: > On Aug 8, 2006, at 2:34 PM, Michael Glassford wrote: > >> I just got the PyObjC trunk from svn. When I try to build it ("$PYTHON >> setup.py build"), I get the error at the end of this message. The >> specified url, >> "http://cheeseshop.python.org/packages/2.5/s/setuptools/ >> setuptools-0.6c1-py2.5.egg", >> is in fact invalid: there's no setuptools directory. > > You need to manually install setuptools 0.7 from the trunk when using > Python 2.5. > > http://svn.python.org/projects/sandbox/trunk/setuptools I did this, and also downloaded and installed bdist_mpkg-0.4.2 as that seemed to be necessary. Now when I run "python setup.py install" for pyobjc I get: """ Traceback (most recent call last): File "setup.py", line 732, in dependency_links = [], File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py", line 112, in setup _setup_distribution = dist = klass(attrs) File "build/bdist.macosx-10.3-fat/egg/setuptools/dist.py", line 219, in __init__ File "build/bdist.macosx-10.3-fat/egg/setuptools/dist.py", line 243, in fetch_build_eggs File "build/bdist.macosx-10.3-fat/egg/pkg_resources.py", line 487, in resolve pkg_resources.VersionConflict: (bdist-mpkg 0.4.2.dev-r0 (/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/bdist_mpkg-0.4.2.dev_r0-py2.5.egg), Requirement.parse('bdist-mpkg>=0.4.2')) """ It appears to be saying I need bdist-mpkg 0.4.2 or greater, but since that's what I just installed I'm not sure what the problem is. Mike From glassfordm at hotmail.com Wed Aug 9 19:07:38 2006 From: glassfordm at hotmail.com (Michael Glassford) Date: Wed, 09 Aug 2006 13:07:38 -0400 Subject: [Pythonmac-SIG] [pyobjc] FYI: Build error; setuptools egg missing In-Reply-To: <4F366E2C-D5C0-4FD1-B454-2E80B317E360@redivi.com> References: <4F366E2C-D5C0-4FD1-B454-2E80B317E360@redivi.com> Message-ID: <44DA165A.2000401@hotmail.com> Bob Ippolito wrote: > On Aug 8, 2006, at 2:34 PM, Michael Glassford wrote: > >> I just got the PyObjC trunk from svn. When I try to build it ("$PYTHON >> setup.py build"), I get the error at the end of this message. The >> specified url, >> "http://cheeseshop.python.org/packages/2.5/s/setuptools/ >> setuptools-0.6c1-py2.5.egg", >> is in fact invalid: there's no setuptools directory. > > You need to manually install setuptools 0.7 from the trunk when using > Python 2.5. > > http://svn.python.org/projects/sandbox/trunk/setuptools I did this, and also downloaded and installed bdist_mpkg-0.4.2 as that seemed to be necessary. Now when I run "python setup.py install" for pyobjc I get: """ Traceback (most recent call last): File "setup.py", line 732, in dependency_links = [], File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/distutils/core.py", line 112, in setup _setup_distribution = dist = klass(attrs) File "build/bdist.macosx-10.3-fat/egg/setuptools/dist.py", line 219, in __init__ File "build/bdist.macosx-10.3-fat/egg/setuptools/dist.py", line 243, in fetch_build_eggs File "build/bdist.macosx-10.3-fat/egg/pkg_resources.py", line 487, in resolve pkg_resources.VersionConflict: (bdist-mpkg 0.4.2.dev-r0 (/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/bdist_mpkg-0.4.2.dev_r0-py2.5.egg), Requirement.parse('bdist-mpkg>=0.4.2')) """ It appears to be saying I need bdist-mpkg 0.4.2 or greater, but since that's what I just installed I'm not sure what the problem is. Mike From bob at redivi.com Wed Aug 9 19:23:50 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 9 Aug 2006 10:23:50 -0700 Subject: [Pythonmac-SIG] [pyobjc] FYI: Build error; setuptools egg missing In-Reply-To: <44DA165A.2000401@hotmail.com> References: <4F366E2C-D5C0-4FD1-B454-2E80B317E360@redivi.com> <44DA165A.2000401@hotmail.com> Message-ID: <43FE1674-E1BE-4C65-9860-0B52260DED98@redivi.com> On Aug 9, 2006, at 10:07 AM, Michael Glassford wrote: > Bob Ippolito wrote: >> On Aug 8, 2006, at 2:34 PM, Michael Glassford wrote: >>> I just got the PyObjC trunk from svn. When I try to build it >>> ("$PYTHON >>> setup.py build"), I get the error at the end of this message. The >>> specified url, >>> "http://cheeseshop.python.org/packages/2.5/s/setuptools/ >>> setuptools-0.6c1-py2.5.egg", >>> is in fact invalid: there's no setuptools directory. >> You need to manually install setuptools 0.7 from the trunk when >> using Python 2.5. >> http://svn.python.org/projects/sandbox/trunk/setuptools > > I did this, and also downloaded and installed bdist_mpkg-0.4.2 as > that seemed to be necessary. Now when I run "python setup.py > install" for pyobjc I get: > > """ > Traceback (most recent call last): > File "setup.py", line 732, in > dependency_links = [], > File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ > python2.5/distutils/core.py", line 112, in setup > _setup_distribution = dist = klass(attrs) > File "build/bdist.macosx-10.3-fat/egg/setuptools/dist.py", line > 219, in __init__ > File "build/bdist.macosx-10.3-fat/egg/setuptools/dist.py", line > 243, in fetch_build_eggs > File "build/bdist.macosx-10.3-fat/egg/pkg_resources.py", line > 487, in resolve > pkg_resources.VersionConflict: (bdist-mpkg 0.4.2.dev-r0 (/Library/ > Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- > packages/bdist_mpkg-0.4.2.dev_r0-py2.5.egg), Requirement.parse > ('bdist-mpkg>=0.4.2')) > """ > > It appears to be saying I need bdist-mpkg 0.4.2 or greater, but > since that's what I just installed I'm not sure what the problem is. If you look at version of the egg you installed, it's "0.4.2.dev_r0". That compares as less-than 0.4.2. Apparently there's a problem with the way the source release of bdist_mpkg was tagged. I'll upload another one later on in the week, or you can fix it yourself by removing the setup.cfg before installing bdist_mpkg (though it's entirely likely that other dependencies will also have the same issue). -bob From ronaldoussoren at mac.com Wed Aug 9 20:38:18 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Wed, 9 Aug 2006 11:38:18 -0700 Subject: [Pythonmac-SIG] [pyobjc] FYI: Build error; setuptools egg missing In-Reply-To: <43FE1674-E1BE-4C65-9860-0B52260DED98@redivi.com> References: <4F366E2C-D5C0-4FD1-B454-2E80B317E360@redivi.com> <44DA165A.2000401@hotmail.com> <43FE1674-E1BE-4C65-9860-0B52260DED98@redivi.com> Message-ID: <870AC841-7131-4A3A-A34C-131DFA554525@mac.com> On 9-aug-2006, at 10:23, Bob Ippolito wrote: > > On Aug 9, 2006, at 10:07 AM, Michael Glassford wrote: > >> Bob Ippolito wrote: >>> On Aug 8, 2006, at 2:34 PM, Michael Glassford wrote: >>>> I just got the PyObjC trunk from svn. When I try to build it >>>> ("$PYTHON >>>> setup.py build"), I get the error at the end of this message. The >>>> specified url, >>>> "http://cheeseshop.python.org/packages/2.5/s/setuptools/ >>>> setuptools-0.6c1-py2.5.egg", >>>> is in fact invalid: there's no setuptools directory. >>> You need to manually install setuptools 0.7 from the trunk when >>> using Python 2.5. >>> http://svn.python.org/projects/sandbox/trunk/setuptools >> >> I did this, and also downloaded and installed bdist_mpkg-0.4.2 as >> that seemed to be necessary. Now when I run "python setup.py >> install" for pyobjc I get: >> >> """ >> Traceback (most recent call last): >> File "setup.py", line 732, in >> dependency_links = [], >> File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ >> python2.5/distutils/core.py", line 112, in setup >> _setup_distribution = dist = klass(attrs) >> File "build/bdist.macosx-10.3-fat/egg/setuptools/dist.py", line >> 219, in __init__ >> File "build/bdist.macosx-10.3-fat/egg/setuptools/dist.py", line >> 243, in fetch_build_eggs >> File "build/bdist.macosx-10.3-fat/egg/pkg_resources.py", line >> 487, in resolve >> pkg_resources.VersionConflict: (bdist-mpkg 0.4.2.dev-r0 (/Library/ >> Frameworks/Python.framework/Versions/2.5/lib/python2.5/site- >> packages/bdist_mpkg-0.4.2.dev_r0-py2.5.egg), Requirement.parse >> ('bdist-mpkg>=0.4.2')) >> """ >> >> It appears to be saying I need bdist-mpkg 0.4.2 or greater, but >> since that's what I just installed I'm not sure what the problem is. > > If you look at version of the egg you installed, it's "0.4.2.dev_r0". > That compares as less-than 0.4.2. > > Apparently there's a problem with the way the source release of > bdist_mpkg was tagged. I'll upload another one later on in the week, > or you can fix it yourself by removing the setup.cfg before > installing bdist_mpkg (though it's entirely likely that other > dependencies will also have the same issue). Another option is to install the version in the repository, that seems to work just fine ;-). Ronald > > -bob > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From Chris.Barker at noaa.gov Wed Aug 9 22:29:47 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Wed, 09 Aug 2006 13:29:47 -0700 Subject: [Pythonmac-SIG] Permission of package installed by mpkgs... Message-ID: <44DA45BB.2010402@noaa.gov> Hi all, I just helped a friend install the PIL mpgk from: http://www.pythonmac.org/packages/py24-fat/ On an OS-X 1-0.4.* Intel Mac. After installing, "import Image" still didn't work, so we went poking into /Library.Frameworks,.....etc, and found that indeed, the PIL dir and PIL.pth has been installed in site-packages, but that neither had read permissions for anyone but the owner, and the owner was set to "localadm", rather than "root" or the name of the user that ran the installer. When we added read permissions for all, it now works fine, but what the heck is going on? By the way, we were not asked for the admin password when running the installer. On my machine (PPC 10.4.7), I notice that PIL is owned by me (the user that installed it), but also has no read perms for anyone but the owner. As I'm the owner, it works for me, but that doesn't seem right. One other difference between the two machines: I think my friend's is set up to authenticate off a Windows Domain controller, which might have something to do with why his got installed by "localadmin", rather than himself. As I look at my site-packages dir, things are a bit messy. Most stuff is owned by me, with a smattering owned by root, but all have a+r perms, except PIL. this stuff is a mixture of packages installed from mpkgs and regular old setup.py install. What's going on? How should this work? I have no idea how, but my thought is that mpkgs should ask for a password, then install as root. Of course with the appropriate read permissions. -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 david.warde.farley at utoronto.ca Wed Aug 9 22:41:30 2006 From: david.warde.farley at utoronto.ca (David Warde-Farley) Date: Wed, 9 Aug 2006 16:41:30 -0400 Subject: [Pythonmac-SIG] Permission of package installed by mpkgs... In-Reply-To: <44DA45BB.2010402@noaa.gov> References: <44DA45BB.2010402@noaa.gov> Message-ID: <2D608277-D58D-4046-A971-172EAD33F55B@utoronto.ca> On 9-Aug-06, at 4:29 PM, Christopher Barker wrote: > After installing, "import Image" still didn't work, so we went poking > into /Library.Frameworks,.....etc, and found that indeed, the PIL dir > and PIL.pth has been installed in site-packages, but that neither had > read permissions for anyone but the owner, and the owner was set to > "localadm", rather than "root" or the name of the user that ran the > installer. > > When we added read permissions for all, it now works fine, but what > the > heck is going on? I encountered this same thing on my G5 at work a few days ago; I meant to post to the list about it. For me it was owned by a user who hasn't been here for months, but might've been the first user added to the system when it was initially set up; I don't know. I installed a handful of other .mpkg's from that site the same day and only PIL gave me problems. David From Larry.A.Meyn at nasa.gov Wed Aug 9 23:28:28 2006 From: Larry.A.Meyn at nasa.gov (Larry Meyn) Date: Wed, 9 Aug 2006 14:28:28 -0700 Subject: [Pythonmac-SIG] Permission of package installed by mpkgs... In-Reply-To: <2D608277-D58D-4046-A971-172EAD33F55B@utoronto.ca> References: <44DA45BB.2010402@noaa.gov> <2D608277-D58D-4046-A971-172EAD33F55B@utoronto.ca> Message-ID: <5FC6BAB6-8C30-4556-BFEE-7BDBCB2BB98F@nasa.gov> I mentioned this problem a week ago or so. I'm not sure, but it only seems to be a problem on machines with multiple admin users. Actually, permissions are not set correctly on single user machines, but the issue doesn't immediately cause problems unless you add another user that wants to use the PIL library. Larry On Aug 9, 2006, at 1:41 PM, David Warde-Farley wrote: > On 9-Aug-06, at 4:29 PM, Christopher Barker wrote: > >> After installing, "import Image" still didn't work, so we went poking >> into /Library.Frameworks,.....etc, and found that indeed, the PIL dir >> and PIL.pth has been installed in site-packages, but that neither had >> read permissions for anyone but the owner, and the owner was set to >> "localadm", rather than "root" or the name of the user that ran the >> installer. >> >> When we added read permissions for all, it now works fine, but what >> the >> heck is going on? > > I encountered this same thing on my G5 at work a few days ago; I > meant to post to the list about it. > > For me it was owned by a user who hasn't been here for months, but > might've been the first user added to the system when it was > initially set up; I don't know. > > I installed a handful of other .mpkg's from that site the same day > and only PIL gave me problems. > > David > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig From woklist at kyngchaos.com Thu Aug 10 21:25:19 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu, 10 Aug 2006 14:25:19 -0500 Subject: [Pythonmac-SIG] py2app run errors Message-ID: <3E90F779-F30B-4F81-9E1C-FCE0DDAFEF70@kyngchaos.com> I have a python script that sets a couple environment vars and runs a shell script in a Terminal window. It works when run from a Terminal with 'python doshell.py'. But when packaged into an app with py2app I get errors. Here's a simplified version (doshell.py): #!/usr/bin/env python import sys import os base = os.path.dirname(sys.argv[0]) # options used by myshell.sh (can't use args) os.environ['STARTBASE'] = base os.environ['MYOPTION'] = 'shelloption' shellrun = base + '/myshell.sh' os.execlp('open', 'open', '-a', 'Terminal.app', shellrun) # continue doing python stuff... The error I get: Traceback (most recent call last): File "/Users/Shared/src/myshell/dist/doshell.app/Contents/ Resources/__boot__.py", line 137, in ? _run('doshell.py') File "/Users/Shared/src/myshell/dist/doshell.app/Contents/ Resources/__boot__.py", line 134, in _run execfile(path, globals(), globals()) File "/Users/Shared/src/myshell/dist/doshell.app/Contents/ Resources/doshell.py", line 18, in ? os.execlp('open', 'open', '-a', 'Terminal.app', shellrun) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/os.py", line 324, in execlp execvp(file, args) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/os.py", line 341, in execvp _execvpe(file, args) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/ python2.4/os.py", line 379, in _execvpe func(fullname, *argrest) OSError: [Errno 45] Operation not supported 2006-08-10 12:11:34.918 CommandDroplet[409] doshell Error 2006-08-10 12:11:34.919 CommandDroplet[409] doshell Error An unexpected error has occurred during execution of the main script I've built the app with the semi_standalone option, and the myshell.sh script is also installed in the app with the resources option in py2app. Built completely standalone, same error, except that the os.py lines have no path. I tried using spawnlp instead, but in the Terminal AND in the py2app application I get the error: RegisterProcess failed (error = -50) I'm just getting my feet wet with Python, so I wouldn't be surprised if I did something wrong here. Maybe there's a better way to run the shell script in a Terminal. Maybe something is wrong with argv[0] when run from the app so the path to run the shell script is wrong. The error isn't very helpful. ----- William Kyngesburye http://www.kyngchaos.com/ All generalizations are dangerous, even this one. From bob at redivi.com Thu Aug 10 22:07:45 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 10 Aug 2006 13:07:45 -0700 Subject: [Pythonmac-SIG] py2app run errors In-Reply-To: <3E90F779-F30B-4F81-9E1C-FCE0DDAFEF70@kyngchaos.com> References: <3E90F779-F30B-4F81-9E1C-FCE0DDAFEF70@kyngchaos.com> Message-ID: <5F4FDD8B-53C2-4CA2-B403-599F3DC09E73@redivi.com> On Aug 10, 2006, at 12:25 PM, William Kyngesburye wrote: > I have a python script that sets a couple environment vars and runs a > shell script in a Terminal window. It works when run from a Terminal > with 'python doshell.py'. But when packaged into an app with py2app > I get errors. > > Here's a simplified version (doshell.py): > > #!/usr/bin/env python > > import sys > import os > > base = os.path.dirname(sys.argv[0]) This should probably be os.path.dirname(__file__) > # options used by myshell.sh (can't use args) > os.environ['STARTBASE'] = base > os.environ['MYOPTION'] = 'shelloption' > > shellrun = base + '/myshell.sh' > > os.execlp('open', 'open', '-a', 'Terminal.app', shellrun) Probably should specify /usr/bin/open instead of just open. -bob From woklist at kyngchaos.com Thu Aug 10 22:42:44 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu, 10 Aug 2006 15:42:44 -0500 Subject: [Pythonmac-SIG] py2app run errors In-Reply-To: <5F4FDD8B-53C2-4CA2-B403-599F3DC09E73@redivi.com> References: <3E90F779-F30B-4F81-9E1C-FCE0DDAFEF70@kyngchaos.com> <5F4FDD8B-53C2-4CA2-B403-599F3DC09E73@redivi.com> Message-ID: <71FE981D-1DD5-4372-973C-08E4DDCAE367@kyngchaos.com> On Aug 10, 2006, at 3:07 PM, Bob Ippolito wrote: > > On Aug 10, 2006, at 12:25 PM, William Kyngesburye wrote: > >> I have a python script that sets a couple environment vars and runs a >> shell script in a Terminal window. It works when run from a Terminal >> with 'python doshell.py'. But when packaged into an app with py2app >> I get errors. >> >> Here's a simplified version (doshell.py): >> >> #!/usr/bin/env python >> >> import sys >> import os >> >> base = os.path.dirname(sys.argv[0]) > > This should probably be os.path.dirname(__file__) > hmm, none of the reference I have mention this one. I guess it means the same as argv[0] - the path/name of the script? >> # options used by myshell.sh (can't use args) >> os.environ['STARTBASE'] = base >> os.environ['MYOPTION'] = 'shelloption' >> >> shellrun = base + '/myshell.sh' >> >> os.execlp('open', 'open', '-a', 'Terminal.app', shellrun) > > Probably should specify /usr/bin/open instead of just open. > Same error (changed command to os.execl). ----- William Kyngesburye http://www.kyngchaos.com/ Earth: "Mostly harmless" - revised entry in the HitchHiker's Guide to the Galaxy From ronaldoussoren at mac.com Thu Aug 10 23:08:41 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Thu, 10 Aug 2006 14:08:41 -0700 Subject: [Pythonmac-SIG] py2app run errors In-Reply-To: <71FE981D-1DD5-4372-973C-08E4DDCAE367@kyngchaos.com> References: <3E90F779-F30B-4F81-9E1C-FCE0DDAFEF70@kyngchaos.com> <5F4FDD8B-53C2-4CA2-B403-599F3DC09E73@redivi.com> <71FE981D-1DD5-4372-973C-08E4DDCAE367@kyngchaos.com> Message-ID: <4DB9578E-241B-4053-ADCF-4C02065DA771@mac.com> On 10-aug-2006, at 13:42, William Kyngesburye wrote: >>> >>> base = os.path.dirname(sys.argv[0]) >> >> This should probably be os.path.dirname(__file__) >> > hmm, none of the reference I have mention this one. I guess it means > the same as argv[0] - the path/name of the script? __file__ is the path where the module was loaded from, which is more reliable than sys.argv[0]. Ronald From bob at redivi.com Fri Aug 11 00:26:53 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 10 Aug 2006 15:26:53 -0700 Subject: [Pythonmac-SIG] py2app run errors In-Reply-To: <71FE981D-1DD5-4372-973C-08E4DDCAE367@kyngchaos.com> References: <3E90F779-F30B-4F81-9E1C-FCE0DDAFEF70@kyngchaos.com> <5F4FDD8B-53C2-4CA2-B403-599F3DC09E73@redivi.com> <71FE981D-1DD5-4372-973C-08E4DDCAE367@kyngchaos.com> Message-ID: <6a36e7290608101526m307691a3rdcf97c127803e916@mail.gmail.com> On 8/10/06, William Kyngesburye wrote: > On Aug 10, 2006, at 3:07 PM, Bob Ippolito wrote: > > > > > On Aug 10, 2006, at 12:25 PM, William Kyngesburye wrote: > > > >> I have a python script that sets a couple environment vars and runs a > >> shell script in a Terminal window. It works when run from a Terminal > >> with 'python doshell.py'. But when packaged into an app with py2app > >> I get errors. > >> > >> Here's a simplified version (doshell.py): > >> > >> #!/usr/bin/env python > >> > >> import sys > >> import os > >> > >> base = os.path.dirname(sys.argv[0]) > > > > This should probably be os.path.dirname(__file__) > > > hmm, none of the reference I have mention this one. I guess it means > the same as argv[0] - the path/name of the script? argv[0] and the name of the script aren't necessarily the same thing. __file__ is the file of the script (all modules have a __file__ attribute). > >> # options used by myshell.sh (can't use args) > >> os.environ['STARTBASE'] = base > >> os.environ['MYOPTION'] = 'shelloption' > >> > >> shellrun = base + '/myshell.sh' > >> > >> os.execlp('open', 'open', '-a', 'Terminal.app', shellrun) > > > > Probably should specify /usr/bin/open instead of just open. > > > Same error (changed command to os.execl). What you really should do at this point is print out your environment variables to make sure they're the right thing. If the environment variables aren't the problem, then you probably forgot to include the shell script in your app. When I want to open something in Terminal I generate a temporary script on the fly, rather than having some static script with parameters wedged in with environment variables. There's even an example of this technique in the py2app source: http://svn.pythonmac.org/py2app/py2app/trunk/examples/EggInstaller/EggInstaller.py -bob From woklist at kyngchaos.com Fri Aug 11 01:24:22 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Thu, 10 Aug 2006 18:24:22 -0500 Subject: [Pythonmac-SIG] py2app run errors In-Reply-To: <6a36e7290608101526m307691a3rdcf97c127803e916@mail.gmail.com> References: <3E90F779-F30B-4F81-9E1C-FCE0DDAFEF70@kyngchaos.com> <5F4FDD8B-53C2-4CA2-B403-599F3DC09E73@redivi.com> <71FE981D-1DD5-4372-973C-08E4DDCAE367@kyngchaos.com> <6a36e7290608101526m307691a3rdcf97c127803e916@mail.gmail.com> Message-ID: On Aug 10, 2006, at 5:26 PM, Bob Ippolito wrote: > argv[0] and the name of the script aren't necessarily the same thing. > __file__ is the file of the script (all modules have a __file__ > attribute). > Like I said, just getting my feet wet. >>>> os.execlp('open', 'open', '-a', 'Terminal.app', shellrun) >>> >>> Probably should specify /usr/bin/open instead of just open. >>> >> Same error (changed command to os.execl). > > What you really should do at this point is print out your environment > variables to make sure they're the right thing. If the environment > variables aren't the problem, then you probably forgot to include the > shell script in your app. > > When I want to open something in Terminal I generate a temporary > script on the fly, rather than having some static script with > parameters wedged in with environment variables. There's even an > example of this technique in the py2app source: > > http://svn.pythonmac.org/py2app/py2app/trunk/examples/EggInstaller/ > EggInstaller.py > Well, some progress. I switched back to the spawn method - I didn't realize that the args behaves exactly like in exec, where the command and name (argv[0]) are repeated. I was doing spawnlp('open', '-a', 'Terminal.app', shellrun). So, now I have spawn finally opening the shell file in a new Terminal window. Now the environment vars aren't making it into the Terminal window. I guess that makes sense - the environment set by spawn/exec is for the command it's running, 'open', not the file that open is telling Terminal to open. I can't use that egginstaller method of writing a script, this application will likely be running without admin privileges, so wouldn't be able to write to the app package. Any ideas on getting environment vars into the new Terminal window? I can't use args for the shell script - it already uses args for something completely different for when it's run from a command line. Although, that already doesn't apply to when it's run as a Mac app like this. hmm... Maybe this is too much work to use Python as an open-source Mac app wrapper for a shell script (starts as a shell script, at least). In the future, though, the app will have a Python GUI that I may want to wrap like this. That'll be easier. ----- William Kyngesburye http://www.kyngchaos.com/ "I ache, therefore I am. Or in my case - I am, therefore I ache." - Marvin From bob at redivi.com Fri Aug 11 01:46:53 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 10 Aug 2006 16:46:53 -0700 Subject: [Pythonmac-SIG] py2app run errors In-Reply-To: References: <3E90F779-F30B-4F81-9E1C-FCE0DDAFEF70@kyngchaos.com> <5F4FDD8B-53C2-4CA2-B403-599F3DC09E73@redivi.com> <71FE981D-1DD5-4372-973C-08E4DDCAE367@kyngchaos.com> <6a36e7290608101526m307691a3rdcf97c127803e916@mail.gmail.com> Message-ID: <5CE10FC4-5BB2-48C2-BBD5-28A0EC9FA368@redivi.com> On Aug 10, 2006, at 4:24 PM, William Kyngesburye wrote: > On Aug 10, 2006, at 5:26 PM, Bob Ippolito wrote: > >> argv[0] and the name of the script aren't necessarily the same thing. >> __file__ is the file of the script (all modules have a __file__ >> attribute). >> > Like I said, just getting my feet wet. > >>>>> os.execlp('open', 'open', '-a', 'Terminal.app', shellrun) >>>> >>>> Probably should specify /usr/bin/open instead of just open. >>>> >>> Same error (changed command to os.execl). >> >> What you really should do at this point is print out your environment >> variables to make sure they're the right thing. If the environment >> variables aren't the problem, then you probably forgot to include the >> shell script in your app. >> >> When I want to open something in Terminal I generate a temporary >> script on the fly, rather than having some static script with >> parameters wedged in with environment variables. There's even an >> example of this technique in the py2app source: >> >> http://svn.pythonmac.org/py2app/py2app/trunk/examples/EggInstaller/ >> EggInstaller.py >> > Well, some progress. I switched back to the spawn method - I > didn't realize that the args behaves exactly like in exec, where > the command and name (argv[0]) are repeated. I was doing spawnlp > ('open', '-a', 'Terminal.app', shellrun). So, now I have spawn > finally opening the shell file in a new Terminal window. > > Now the environment vars aren't making it into the Terminal > window. I guess that makes sense - the environment set by spawn/ > exec is for the command it's running, 'open', not the file that > open is telling Terminal to open. I can't use that egginstaller > method of writing a script, this application will likely be running > without admin privileges, so wouldn't be able to write to the app > package. You should never write to the app package. In any case, the example I sent you writes a temporary file. Look a bit harder. -bob From woklist at kyngchaos.com Fri Aug 11 16:41:49 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri, 11 Aug 2006 09:41:49 -0500 Subject: [Pythonmac-SIG] py2app run errors In-Reply-To: <5CE10FC4-5BB2-48C2-BBD5-28A0EC9FA368@redivi.com> References: <3E90F779-F30B-4F81-9E1C-FCE0DDAFEF70@kyngchaos.com> <5F4FDD8B-53C2-4CA2-B403-599F3DC09E73@redivi.com> <71FE981D-1DD5-4372-973C-08E4DDCAE367@kyngchaos.com> <6a36e7290608101526m307691a3rdcf97c127803e916@mail.gmail.com> <5CE10FC4-5BB2-48C2-BBD5-28A0EC9FA368@redivi.com> Message-ID: <3914F6EB-5D07-480F-8F6C-855477115EAC@kyngchaos.com> On Aug 10, 2006, at 6:46 PM, Bob Ippolito wrote: >> Well, some progress. I switched back to the spawn method - I >> didn't realize that the args behaves exactly like in exec, where >> the command and name (argv[0]) are repeated. I was doing spawnlp >> ('open', '-a', 'Terminal.app', shellrun). So, now I have spawn >> finally opening the shell file in a new Terminal window. >> >> Now the environment vars aren't making it into the Terminal >> window. I guess that makes sense - the environment set by spawn/ >> exec is for the command it's running, 'open', not the file that >> open is telling Terminal to open. I can't use that egginstaller >> method of writing a script, this application will likely be >> running without admin privileges, so wouldn't be able to write to >> the app package. > > You should never write to the app package. That's why I didn't like the method, but... > In any case, the example I sent you writes a temporary file. Look a > bit harder. > ... yeah, I missed that bit - I saw just the parts I immediately understood. Anyways, better idea: the shell script is a bootstrap for the software - it sets a fixed root path as configured at build time and starts another script, the main command shell of the app. I added a test for the env var for when it's started from a Mac app package, so it could set the root path dynamically. I originally did this with an OnMyCommand droplet. Since I already changed the script, I decided to make it Mac-only and let the script figure out the root path. No Mac test needed, no env vars needed from the python startup. The py2app setup will install this copy of the startup shell instead of the one from the software. Bonus of less to change in the original software source. ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From woklist at kyngchaos.com Fri Aug 11 22:34:17 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Fri, 11 Aug 2006 15:34:17 -0500 Subject: [Pythonmac-SIG] py2app build problems Message-ID: <6A176390-C6D0-4BA5-8DF2-F71B022F4DD7@kyngchaos.com> I have a setup.py I generated from py2applet which I've expanded to copy in all the shell scripts and binaries and support files needed for an application (py2app is just for the app startup, the app is all shell scripts and C binaries). - I have dylib_excludes worked out so it doesn't pull in a bunch of extra frameworks (3rd party stuff) that are expected to be installed separately. One odd thing there, before I excluded them: a couple frameworks are wrappers (umbrella framework) for a collection of unix libraries or make use of a bunch of unix libraries, included in the framework. py2app copied the whole framework, then duplicated the included libraries needed by the framework in the top level of the Frameworks folder, like (simplified): Contents Frameworks Foo.framework Libraries libbar1.dylib libbar2.dylib Foo [uses libbar1 and libbar2] libbar1.dylib [Foo's new relative @executable_path libbar2.dylib linking uses these copies] If I wanted to include the frameworks, it would be a mess. - the dylib exclude option is not working for dylibs, just frameworks. I've tried various forms: the full path as specified in the install name, libfoo, libfoo.dylib, libfoo.version.dylib. It still copies them. - for libraries installed from the software, it's pulling in installed copies (makes sense, since that's where the install name has them). But these may be older than the ones I've just built for the app package and haven't installed yet. given the various issues with pulling in libraries and frameworks, an exclude option that would be nice is to exclude all libraries/ frameworks, without having to figure out what they might be and listing every one, a 'dylib_excludes: all' option. I would rather install needed libraries manually anyways (as resources), and the application sets DYLD_LIBRARY_PATH already so relative paths aren't needed. ----- William Kyngesburye http://www.kyngchaos.com/ "This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?" - The Ruler of the Universe From bob at redivi.com Sat Aug 12 04:34:48 2006 From: bob at redivi.com (Bob Ippolito) Date: Fri, 11 Aug 2006 19:34:48 -0700 Subject: [Pythonmac-SIG] py2app build problems In-Reply-To: <6A176390-C6D0-4BA5-8DF2-F71B022F4DD7@kyngchaos.com> References: <6A176390-C6D0-4BA5-8DF2-F71B022F4DD7@kyngchaos.com> Message-ID: <6a36e7290608111934h7903b31fnf46c67572b82c3e5@mail.gmail.com> On 8/11/06, William Kyngesburye wrote: > I have a setup.py I generated from py2applet which I've expanded to > copy in all the shell scripts and binaries and support files needed > for an application (py2app is just for the app startup, the app is > all shell scripts and C binaries). This use case isn't really covered very well by py2app. It's designed to build Python applications. It can probably be used for that, but you're mostly on your own. > - I have dylib_excludes worked out so it doesn't pull in a bunch of > extra frameworks (3rd party stuff) that are expected to be installed > separately. One odd thing there, before I excluded them: a couple > frameworks are wrappers (umbrella framework) for a collection of unix > libraries or make use of a bunch of unix libraries, included in the > framework. py2app copied the whole framework, then duplicated the > included libraries needed by the framework in the top level of the > Frameworks folder, like (simplified): file a ticket for this: http://trac.pythonmac.org/py2app/newticket > If I wanted to include the frameworks, it would be a mess. > > - the dylib exclude option is not working for dylibs, just > frameworks. I've tried various forms: the full path as specified in > the install name, libfoo, libfoo.dylib, libfoo.version.dylib. It > still copies them. This should be a separate ticket. (if you don't file tickets, I can pretty much guarantee I'll forget to do anything about it in any reasonable timeframe). > - for libraries installed from the software, it's pulling in > installed copies (makes sense, since that's where the install name > has them). But these may be older than the ones I've just built for > the app package and haven't installed yet. macholib respects all of the DYLD environment variables. If you want it to pick up libraries from some other location, start setting them. > given the various issues with pulling in libraries and frameworks, an > exclude option that would be nice is to exclude all libraries/ > frameworks, without having to figure out what they might be and > listing every one, a 'dylib_excludes: all' option. I would rather > install needed libraries manually anyways (as resources), and the > application sets DYLD_LIBRARY_PATH already so relative paths aren't > needed. This option is called --debug-skip-macholib -bob From woklist at kyngchaos.com Sat Aug 12 21:24:29 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat, 12 Aug 2006 14:24:29 -0500 Subject: [Pythonmac-SIG] py2app build problems In-Reply-To: <6a36e7290608111934h7903b31fnf46c67572b82c3e5@mail.gmail.com> References: <6A176390-C6D0-4BA5-8DF2-F71B022F4DD7@kyngchaos.com> <6a36e7290608111934h7903b31fnf46c67572b82c3e5@mail.gmail.com> Message-ID: <95687E00-C902-40AA-87DD-351FCF1AD65D@kyngchaos.com> On Aug 11, 2006, at 9:34 PM, Bob Ippolito wrote: > On 8/11/06, William Kyngesburye wrote: >> I have a setup.py I generated from py2applet which I've expanded to >> copy in all the shell scripts and binaries and support files needed >> for an application (py2app is just for the app startup, the app is >> all shell scripts and C binaries). > > This use case isn't really covered very well by py2app. It's designed > to build Python applications. It can probably be used for that, but > you're mostly on your own. > Understood. No complaints here. >> ... > > file a ticket for this: > http://trac.pythonmac.org/py2app/newticket > > (if you don't file tickets, I can pretty much guarantee I'll forget to > do anything about it in any reasonable timeframe). > OK. Just wanted to make sure there was a problem and it wasn't something I missed. >> - for libraries installed from the software, it's pulling in >> installed copies (makes sense, since that's where the install name >> has them). But these may be older than the ones I've just built for >> the app package and haven't installed yet. > > macholib respects all of the DYLD environment variables. If you want > it to pick up libraries from some other location, start setting them. > So, will the debug-skip-macholib option override the frameworks option? Or the other way around? >> given the various issues with pulling in libraries and frameworks, an >> exclude option that would be nice is to exclude all libraries/ >> frameworks, without having to figure out what they might be and >> listing every one, a 'dylib_excludes: all' option. I would rather >> install needed libraries manually anyways (as resources), and the >> application sets DYLD_LIBRARY_PATH already so relative paths aren't >> needed. > > This option is called --debug-skip-macholib > Cool, that did it. ----- William Kyngesburye http://www.kyngchaos.com/ "Oh, look, I seem to have fallen down a deep, dark hole. Now what does that remind me of? Ah, yes - life." - Marvin From bob at redivi.com Sat Aug 12 22:17:20 2006 From: bob at redivi.com (Bob Ippolito) Date: Sat, 12 Aug 2006 13:17:20 -0700 Subject: [Pythonmac-SIG] py2app build problems In-Reply-To: <95687E00-C902-40AA-87DD-351FCF1AD65D@kyngchaos.com> References: <6A176390-C6D0-4BA5-8DF2-F71B022F4DD7@kyngchaos.com> <6a36e7290608111934h7903b31fnf46c67572b82c3e5@mail.gmail.com> <95687E00-C902-40AA-87DD-351FCF1AD65D@kyngchaos.com> Message-ID: <6a36e7290608121317u4cb57926r16f834d439cd54db@mail.gmail.com> On 8/12/06, William Kyngesburye wrote: > On Aug 11, 2006, at 9:34 PM, Bob Ippolito wrote: > > > On 8/11/06, William Kyngesburye wrote: > >> I have a setup.py I generated from py2applet which I've expanded to > >> copy in all the shell scripts and binaries and support files needed > >> for an application (py2app is just for the app startup, the app is > >> all shell scripts and C binaries). > > > > This use case isn't really covered very well by py2app. It's designed > > to build Python applications. It can probably be used for that, but > > you're mostly on your own. > > > Understood. No complaints here. > > >> ... > > > > file a ticket for this: > > http://trac.pythonmac.org/py2app/newticket > > > > (if you don't file tickets, I can pretty much guarantee I'll forget to > > do anything about it in any reasonable timeframe). > > > OK. Just wanted to make sure there was a problem and it wasn't > something I missed. It shouldn't ever make two copies. It doesn't work because it's not tested against umbrella-style frameworks because those are rarely seen in third party frameworks (and Apple's stuff is never included in an app bundle). If you can contribute one to use as a test case, it'd get fixed faster. > >> - for libraries installed from the software, it's pulling in > >> installed copies (makes sense, since that's where the install name > >> has them). But these may be older than the ones I've just built for > >> the app package and haven't installed yet. > > > > macholib respects all of the DYLD environment variables. If you want > > it to pick up libraries from some other location, start setting them. > > > So, will the debug-skip-macholib option override the frameworks > option? Or the other way around? debug-skip-macholib takes precedence. Anything to do with dylibs or frameworks will not happen at all. They won't even be copied. It skips the entire branch of code that relates to macholib. -bob From woklist at kyngchaos.com Sat Aug 12 22:25:46 2006 From: woklist at kyngchaos.com (William Kyngesburye) Date: Sat, 12 Aug 2006 15:25:46 -0500 Subject: [Pythonmac-SIG] py2app build problems In-Reply-To: <6a36e7290608121317u4cb57926r16f834d439cd54db@mail.gmail.com> References: <6A176390-C6D0-4BA5-8DF2-F71B022F4DD7@kyngchaos.com> <6a36e7290608111934h7903b31fnf46c67572b82c3e5@mail.gmail.com> <95687E00-C902-40AA-87DD-351FCF1AD65D@kyngchaos.com> <6a36e7290608121317u4cb57926r16f834d439cd54db@mail.gmail.com> Message-ID: On Aug 12, 2006, at 3:17 PM, Bob Ippolito wrote: > It shouldn't ever make two copies. It doesn't work because it's not > tested against umbrella-style frameworks because those are rarely seen > in third party frameworks (and Apple's stuff is never included in an > app bundle). If you can contribute one to use as a test case, it'd get > fixed faster. Try my GDAL framework you can find on my site. It's not an umbrella framework, but it includes a few libraries it uses internally. My UnixImageIO framework is more like an umbrella framework - no sub- frameworks, but there are sub-libraries. ----- William Kyngesburye http://www.kyngchaos.com/ [Trillian] What are you supposed to do WITH a maniacally depressed robot? [Marvin] You think you have problems? What are you supposed to do if you ARE a maniacally depressed robot? No, don't try and answer, I'm 50,000 times more intelligent than you and even I don't know the answer... - HitchHiker's Guide to the Galaxy From mark at mophilly.com Wed Aug 16 17:35:28 2006 From: mark at mophilly.com (Mark Phillips) Date: Wed, 16 Aug 2006 08:35:28 -0700 Subject: [Pythonmac-SIG] examples of python Message-ID: <7D687DC6-FBF6-464C-A424-4DC236B086CE@mophilly.com> I apologize if this is off topic. I have been researching the following and I thought of this group. I am preparing a presentation about using python to extend existing applications. One of the things I will attempt to show is the power of OSS. That is, the availability of a wide variety of "ready to use" applications. Not applications in the sense of complete desktop applications, but rather code that handles the edges and nuance of business applications. A few areas are well covered. Database, UI framework and web service examples are plentiful. What I seek is the more esoteric. Examples that would be interesting to an experienced business database application developer who has a well stocked set of tools. And who is just learning about python. I have a handful of examples based on my own work. I am hoping that a few of you on the list might be willing to offer suggestions and links that would add breadth and interest to the presentation. Please feel free to contact me off list if you prefer. TIA, Mark Phillips From swillison at gmail.com Thu Aug 17 20:46:32 2006 From: swillison at gmail.com (Simon Willison) Date: Thu, 17 Aug 2006 19:46:32 +0100 Subject: [Pythonmac-SIG] readline on OS X 10.4 on Intel? Message-ID: Hi, I've just got my hands on a MacBook Pro, but the old trick for getting readline running for Python no longer works: $ python `python -c "import pimp; print pimp.__file__"` -i readline Traceback (most recent call last): ... ... urllib2.HTTPError: HTTP Error 404: Not Found Further investigation shows that the URL in question is: http://www.python.org/packman/version-0.5/prod-2.3-darwin_apple-8.7.1-i386.plist The files in http://www.python.org/packman/version-0.5/ haven't been touched since April of last year. What's the current recommended way of getting readline running with the python 2.3.5 that comes with Intel macs? Cheers, Simon Willison From bob at redivi.com Thu Aug 17 20:51:28 2006 From: bob at redivi.com (Bob Ippolito) Date: Thu, 17 Aug 2006 11:51:28 -0700 Subject: [Pythonmac-SIG] readline on OS X 10.4 on Intel? In-Reply-To: References: Message-ID: <6a36e7290608171151g249c59c2h3ca9c7daf712a65d@mail.gmail.com> On 8/17/06, Simon Willison wrote: > Hi, > > I've just got my hands on a MacBook Pro, but the old trick for getting > readline running for Python no longer works: > > $ python `python -c "import pimp; print pimp.__file__"` -i readline > Traceback (most recent call last): > ... ... > urllib2.HTTPError: HTTP Error 404: Not Found > > Further investigation shows that the URL in question is: > > http://www.python.org/packman/version-0.5/prod-2.3-darwin_apple-8.7.1-i386.plist > > The files in http://www.python.org/packman/version-0.5/ haven't been > touched since April of last year. > > What's the current recommended way of getting readline running with > the python 2.3.5 that comes with Intel macs? Install universal Python 2.4, it comes with readline. Otherwise, you have to build it yourself. -bob From Chris.Barker at noaa.gov Thu Aug 17 22:45:40 2006 From: Chris.Barker at noaa.gov (Christopher Barker) Date: Thu, 17 Aug 2006 13:45:40 -0700 Subject: [Pythonmac-SIG] readline on OS X 10.4 on Intel? In-Reply-To: <6a36e7290608171151g249c59c2h3ca9c7daf712a65d@mail.gmail.com> References: <6a36e7290608171151g249c59c2h3ca9c7daf712a65d@mail.gmail.com> Message-ID: <44E4D574.6060605@noaa.gov> Bob Ippolito wrote: > Install universal Python 2.4, http://www.pythonmac.org/packages/py24-fat/ -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 hengist.podd at virgin.net Thu Aug 17 22:50:29 2006 From: hengist.podd at virgin.net (has) Date: Thu, 17 Aug 2006 21:50:29 +0100 Subject: [Pythonmac-SIG] [ann] Appscript Installer 1.4 released Message-ID: Hi all, New appscript binaries are available at: http://appscript.sourceforge.net/download.html Some API changes, and various bug fixes, improvements and performance optimisations. Before installing appscript, please see the accompanying 'Read Me First' file for a list of changes and instructions on removing previous versions. Give it a spin and let us know if there's any problems. I'll do a wider announcement in a day or two once I've finished moving appscript into its new home. Cheers, has -- http://freespace.virgin.net/hamish.sanderson/ From rwgk at yahoo.com Sat Aug 19 02:04:57 2006 From: rwgk at yahoo.com (Ralf W. Grosse-Kunstleve) Date: Fri, 18 Aug 2006 17:04:57 -0700 (PDT) Subject: [Pythonmac-SIG] extensions linked against shared library? Message-ID: <20060819000457.26411.qmail@web31508.mail.mud.yahoo.com> I am wondering if it is possible to use Boost.Python based C++ extension modules with a non-framework Python 2.5 build. At runtime I'd like to import two different C++ extension modules. Both modules need to dynamically link against libboost_python: |------| |python| |------| | import | --------------------- | | |---------------| |---------------| |C++ extension 1| |C++ extension 2| |---------------| |---------------| | | --------------------- | dynamically linked | |---------------| |libboost_python| |---------------| I built python simply with ./configure --prefix=...; make; make install. I created libboost_python with: setenv MACOSX_DEPLOYMENT_TARGET 10.3 c++ -o lib/libboost_python.dylib -dynamic -undefined dynamic_lookup $bplobj where $bplobj is a list of *.o files. When I try to link a C++ extension module like this c++ -bundle -undefined dynamic_lookup -o lib/boost_python_meta_ext.so boost_adaptbx/meta_ext.o -Llib -lboost_python the result is ld: lib/libboost_python.dylib is input for the dynamic link editor, is not relocatable by the static link editor again Is there any way to make this work? -- It works with the framework Python that ships with OS X 10.3 and 10.4, but I'd like to know if it could also work with a non-framework Python. Ralf P.S.: I am working on a Mac OS X 10.3 system with gcc version 3.3 20030304 (Apple Computer, Inc. build 1493) __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From kent_quirk at cognitoy.com Tue Aug 22 20:42:26 2006 From: kent_quirk at cognitoy.com (Kent Quirk) Date: Tue, 22 Aug 2006 14:42:26 -0400 Subject: [Pythonmac-SIG] building universal pysqlite? Message-ID: <44EB5012.6060108@cognitoy.com> I'm trying to construct a current universal version of sqlite and pysqlite. I've got pysqlite building properly (which isn't hard!), but it was using the current (old -- 3.1.3) version of sqlite on my system, which is incompatible with the version I'm using on another platform. So now I'm trying to build sqlite 3.3.7. It builds, but it builds 386 only, which then chokes the build for pysqlite. I'm sure there's a set of patterns for how one converts a generic configure/make/make install system to build universal, but I haven't been able to find a good source for such information. This isn't strictly a python question, but as it's in support of python library compatibility, I'm hoping someone will be able to give me a pointer or two. Kent From bob at redivi.com Wed Aug 23 00:08:02 2006 From: bob at redivi.com (Bob Ippolito) Date: Tue, 22 Aug 2006 15:08:02 -0700 Subject: [Pythonmac-SIG] building universal pysqlite? In-Reply-To: <44EB5012.6060108@cognitoy.com> References: <44EB5012.6060108@cognitoy.com> Message-ID: <6a36e7290608221508g77371df5ma1c91c297b3415da@mail.gmail.com> On 8/22/06, Kent Quirk wrote: > I'm trying to construct a current universal version of sqlite and > pysqlite. I've got pysqlite building properly (which isn't hard!), but > it was using the current (old -- 3.1.3) version of sqlite on my system, > which is incompatible with the version I'm using on another platform. So > now I'm trying to build sqlite 3.3.7. It builds, but it builds 386 only, > which then chokes the build for pysqlite. I'm sure there's a set of > patterns for how one converts a generic configure/make/make install > system to build universal, but I haven't been able to find a good source > for such information. > > This isn't strictly a python question, but as it's in support of python > library compatibility, I'm hoping someone will be able to give me a > pointer or two. Take a look at what Python 2.5 does, or just use Python 2.5 which ships with universal pysqlite. http://svn.python.org/projects/python/branches/release25-maint/Mac/BuildScript/build-installer.py -bob From pedz at easesoftware.com Wed Aug 23 22:55:27 2006 From: pedz at easesoftware.com (Perry Smith) Date: Wed, 23 Aug 2006 15:55:27 -0500 Subject: [Pythonmac-SIG] fpconst Message-ID: <66CD4884-2396-408B-86FA-0187D9BF089F@easesoftware.com> Hi, Sorry to bother you guys but place to get fpconst is down and the backup place: http://www.warnes.net/rwndown is down too. Can someone either mail me a copy of it or point me to a place that is up where I can download it? If it matters, I'm on a Mac 10.4.7 using Python 2.4.3. Thank you Perry Smith Ease Software, Inc. pedz at easesoftware.com http://www.easesoftware.com AIX Kernel Level Consulting Services and SATA Products -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060823/7ac142f9/attachment.html From bob at redivi.com Thu Aug 24 06:39:46 2006 From: bob at redivi.com (Bob Ippolito) Date: Wed, 23 Aug 2006 21:39:46 -0700 Subject: [Pythonmac-SIG] fpconst In-Reply-To: <66CD4884-2396-408B-86FA-0187D9BF089F@easesoftware.com> References: <66CD4884-2396-408B-86FA-0187D9BF089F@easesoftware.com> Message-ID: <6a36e7290608232139j3c3f70as76f3db12cd3d4116@mail.gmail.com> On 8/23/06, Perry Smith wrote: > > Hi, > > Sorry to bother you guys but place to get fpconst is down and the backup > place: http://www.warnes.net/rwndown is down too. > > Can someone either mail me a copy of it or point me to a place that is up > where I can download it? > > If it matters, I'm on a Mac 10.4.7 using Python 2.4.3. There's a link mentioned here: http://twistedmatrix.com/pipermail/twisted-web/2006-June/002671.html -bob From dan at chalkie.org.uk Thu Aug 24 16:00:47 2006 From: dan at chalkie.org.uk (Dan White) Date: Thu, 24 Aug 2006 17:00:47 +0300 Subject: [Pythonmac-SIG] py2app and install_name changing to @executable_path/../Frameworks/libWhatever.dylib In-Reply-To: References: <8371BEDC-9C08-4921-AB3E-170210CC2536@redivi.com> <5D2B67B1-8D82-4382-8E97-36ED6AA5F0C9@mac.com> <7A1505BB-4BEF-4A2E-BFCB-68416EF930F2@chalkie.org.uk> <83DA00A6-1AB4-4A03-8532-F55ADF4B3CCE@mac.com> Message-ID: >> >> >> what should i rewrite it to be? >> using >> install_name_tool -id ? >> what would make pyapp automatically copy the library and rewrite >> the install_name? > > If I understand things correctly the install_name of libguide.dylib > is currently just libguide.dylib, whereas it should be /path/to/ > libguide.dylib. The install_name is copied into any objects that > link to the library (which is what you get to see when you use > otool -vL). > > If the install_name of a linked-to library points to a library that > py2app can find at that location that library will be copied into > the application bundle and it's install_name gets rewritten to > something relative to the executable in the application bundle. > > Now that I think a bit more about this issue, it might be possible > to solve this using a py2app recipe. I don't really have time to > work on this, even though I'd love to play with the Intel compiler > to see if that would speed up Python. I'm still trying to get py2app to work for our BioImageXD software, It appears to be the case that py2app is NOT re writing the install_name of included non system .dylibs (like the intel libguide and the vtk libs I am using) as you suggest it should be doing, so that they have @executable_path/../Frameworks/libWhatever.dylib instead of just libWhatever.dylib as their install_name, as can be seen by otool -L So now I wonder if this "should" be happening as the py2app code stands as you imply above, but isnt happeneing due to a problem, or if it is not happening since this is not what py2app is trying to do. Has it been fixed in a recent development version, or is it really broken in my case, or does that functionality need to be added? cheers Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From python at adhamh.com Sun Aug 27 07:20:14 2006 From: python at adhamh.com (Adhamh Findlay) Date: Sat, 26 Aug 2006 22:20:14 -0700 Subject: [Pythonmac-SIG] QuickTime module current status on windows? Message-ID: <44F12B8E.8070502@adhamh.com> Hello, I'm looking into the possibility of writing a cross platform wxPython app for Windows and Mac. Mac support comes first but I will need to support Windows too. I found this message from way back... http://mail.python.org/pipermail/image-sig/2002-October/002017.html In it, Jack Jansen mentions that the QuickTime module will work on Windows with a few minor modifications. Is this still in case in Python 2.4? Does anyone know what these modifications are? Has anyone done this before or am I just barking up the wrong tree to even think about a solution like this? Thanks, Adhamh From bwaters at nrao.edu Mon Aug 28 00:39:33 2006 From: bwaters at nrao.edu (Boyd Waters) Date: Sun, 27 Aug 2006 16:39:33 -0600 Subject: [Pythonmac-SIG] with libraries compiled with intel compilers, intel libguide.dylib not included Message-ID: From: bwaters at nrao.edu Subject: install_name changing Date: August 27, 2006 4:28:22 PM MDT To: white at cc.jyu.fi Cc: pythonmac-sig at python.org Dan: I saw your recent post on the Python-Mac SIG regarding the difficulty that you are having using libguide.dylib in a Python application, since you've built Python with the Intel compiler. I think that you're on the right track with the install_name_tool -- this is what I had to do to get the Intel binaries working: > # cd /opt/intel/cc/9.1.029/lib > > # for i in *.dylib > > do > > install_name_tool -id $(pwd)/$i $i > > done > Then I had to change the references to libirc.dylib in libimf and libsvml > for i in libimf.dylib libsvml.dylib > > do > > install_name_tool -change libirc.dylib $(pwd)/libirc.dylib $i > > done > When I was done, this is what it looks like: > $ otool -L /opt/intel/cc/9.1.029/lib/*.dylib > /opt/intel/cc/9.1.029/lib/libguide.dylib: > /opt/intel/cc/9.1.029/lib/libguide.dylib (compatibility > version 4.0.0, current version 4.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.3) > /opt/intel/cc/9.1.029/lib/libguide_stats.dylib: > /opt/intel/cc/9.1.029/lib/libguide_stats.dylib > (compatibility version 4.0.0, current version 4.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.3) > /opt/intel/cc/9.1.029/lib/libimf.dylib: > /opt/intel/cc/9.1.029/lib/libimf.dylib (compatibility > version 0.0.0, current version 0.0.0) > /opt/intel/cc/9.1.029/lib/libirc.dylib (compatibility > version 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.3) > /opt/intel/cc/9.1.029/lib/libirc.dylib: > /opt/intel/cc/9.1.029/lib/libirc.dylib (compatibility > version 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.3) > /opt/intel/cc/9.1.029/lib/libsvml.dylib: > /opt/intel/cc/9.1.029/lib/libsvml.dylib (compatibility > version 0.0.0, current version 0.0.0) > /opt/intel/cc/9.1.029/lib/libirc.dylib (compatibility > version 0.0.0, current version 0.0.0) > > Every dynamic library is referenced using the full path. In my distribution, I have to re-distribute these libraries, and put them in /opt/intel/cc/9.1.029/lib on the client. This is not the best option, but it works for the numerous open- source packages that we use for our image-processing system. Good luck! - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico http://www.aoc.nrao.edu/ From bwaters at nrao.edu Mon Aug 28 00:28:22 2006 From: bwaters at nrao.edu (Boyd Waters) Date: Sun, 27 Aug 2006 16:28:22 -0600 Subject: [Pythonmac-SIG] install_name changing Message-ID: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> Dan: I saw your recent post on the Python-Mac SIG regarding the difficulty that you are having using libguide.dylib in a Python application, since you've built Python with the Intel compiler. I think that you're on the right track with the install_name_tool -- this is what I had to do to get the Intel binaries working: > # cd /opt/intel/cc/9.1.029/lib > > # for i in *.dylib > > do > > install_name_tool -id $(pwd)/$i $i > > done Then I had to change the references to libirc.dylib in libimf and libsvml > for i in libimf.dylib libsvml.dylib > > do > > install_name_tool -change libirc.dylib $(pwd)/libirc.dylib $i > > done When I was done, this is what it looks like: > $ otool -L /opt/intel/cc/9.1.029/lib/*.dylib > /opt/intel/cc/9.1.029/lib/libguide.dylib: > /opt/intel/cc/9.1.029/lib/libguide.dylib (compatibility > version 4.0.0, current version 4.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.3) > /opt/intel/cc/9.1.029/lib/libguide_stats.dylib: > /opt/intel/cc/9.1.029/lib/libguide_stats.dylib > (compatibility version 4.0.0, current version 4.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.3) > /opt/intel/cc/9.1.029/lib/libimf.dylib: > /opt/intel/cc/9.1.029/lib/libimf.dylib (compatibility > version 0.0.0, current version 0.0.0) > /opt/intel/cc/9.1.029/lib/libirc.dylib (compatibility > version 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.3) > /opt/intel/cc/9.1.029/lib/libirc.dylib: > /opt/intel/cc/9.1.029/lib/libirc.dylib (compatibility > version 0.0.0, current version 0.0.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, > current version 88.1.3) > /opt/intel/cc/9.1.029/lib/libsvml.dylib: > /opt/intel/cc/9.1.029/lib/libsvml.dylib (compatibility > version 0.0.0, current version 0.0.0) > /opt/intel/cc/9.1.029/lib/libirc.dylib (compatibility > version 0.0.0, current version 0.0.0) > Every dynamic library is referenced using the full path. In my distribution, I have to re-distribute these libraries, and put them in /opt/intel/cc/9.1.029/lib on the client. This is not the best option, but it works for the numerous open- source packages that we use for our image-processing system. I have a question for you, if you don't mind: I cannot get the Python package to build with the Intel compiler. It does not find the _Py_Main symbol when linking the top-level "python.exe". I would be very happy to get pointed in the right direction regarding compiler and linker flags for building Python 2.4.3; if we need to use Python 2.5 then we can do that too. Thanks and good luck! - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico http://www.aoc.nrao.edu/ From bwaters at nrao.edu Mon Aug 28 00:44:04 2006 From: bwaters at nrao.edu (Boyd Waters) Date: Sun, 27 Aug 2006 16:44:04 -0600 Subject: [Pythonmac-SIG] Intel compilers to build Python? Message-ID: <1BF040ED-9023-41F1-BA94-364843472709@nrao.edu> I cannot get the Python package to build with the Intel compiler. It does not find the _Py_Main symbol when linking the top-level "python.exe". What environment variables, configure arguments, and linker tweaks are you all using to build Python on Macintosh with the Intel compilers? /usr/bin/install -c -d -m 755 Python.framework/Versions/2.4 icpc -dynamiclib -o Python.framework/Versions/2.4/Python -dynamic libpython2.4.a \ -lSystem -lSystemStubs -arch_only i386 -install_name /opt/ local/Library/Frameworks/Python.framework/Versions/2.4/Python - compatibility_version 2.4 -current_version 2.4 /usr/bin/install -c -d -m 755 \ Python.framework/Versions/2.4/Resources/English.lproj /usr/bin/install -c -m 644 ./Mac/OSXResources/framework/Info.plist \ Python.framework/Versions/2.4/Resources/Info.plist /usr/bin/install -c -m 644 ./Mac/OSXResources/framework/version.plist \ Python.framework/Versions/2.4/Resources/version.plist /usr/bin/install -c -m 644 ./Mac/OSXResources/framework/English.lproj/ InfoPlist.strings \ Python.framework/Versions/2.4/Resources/English.lproj/ InfoPlist.strings ln -fsn 2.4 Python.framework/Versions/Current ln -fsn Versions/Current/Python Python.framework/Python ln -fsn Versions/Current/Headers Python.framework/Headers ln -fsn Versions/Current/Resources Python.framework/Resources icpc -u _PyMac_Error Python.framework/Versions/2.4/Python -undefined dynamic_lookup -o python.exe \ Modules/ccpython.o \ -ldl case $MAKEFLAGS in \ *-s*) DYLD_FRAMEWORK_PATH=/opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_lang_python24/work/Python-2.4.3: CC='icc' LDSHARED='icc -bundle -undefined dynamic_lookup' OPT='-DNDEBUG -c99 -axT -O3 -parallel - fstack-security-check -fPIC -fno-common' ./python.exe -E ./setup.py - q build;; \ *) DYLD_FRAMEWORK_PATH=/opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_lang_python24/work/Python-2.4.3: CC='icc' LDSHARED='icc -bundle -undefined dynamic_lookup' OPT='-DNDEBUG -c99 -axT -O3 -parallel - fstack-security-check -fPIC -fno-common' ./python.exe -E ./setup.py build;; \ esac dyld: lazy symbol binding failed: Symbol not found: _Py_Main Referenced from: /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_lang_python24/work/Python-2.4.3/./python.exe Expected in: dynamic lookup dyld: Symbol not found: _Py_Main Referenced from: /opt/local/var/db/dports/build/ _opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dp orts_lang_python24/work/Python-2.4.3/./python.exe Expected in: dynamic lookup Thanks! - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico http://www.aoc.nrao.edu/ From bob at redivi.com Mon Aug 28 00:51:05 2006 From: bob at redivi.com (Bob Ippolito) Date: Sun, 27 Aug 2006 15:51:05 -0700 Subject: [Pythonmac-SIG] Intel compilers to build Python? In-Reply-To: <1BF040ED-9023-41F1-BA94-364843472709@nrao.edu> References: <1BF040ED-9023-41F1-BA94-364843472709@nrao.edu> Message-ID: <6a36e7290608271551r3aeed84cye7a2532669349e99@mail.gmail.com> On 8/27/06, Boyd Waters wrote: > I cannot get the Python package to build with the Intel compiler. It > does not find the _Py_Main symbol when linking the top-level > "python.exe". Have you tried building it with just the source, not DarwinPorts? -bob From hengist.podd at virgin.net Sun Aug 27 18:16:34 2006 From: hengist.podd at virgin.net (has) Date: Sun, 27 Aug 2006 17:16:34 +0100 Subject: [Pythonmac-SIG] [ann] Appscript Installer 1.4.1 released Message-ID: Hi all, Quick appscript update: http://appscript.sourceforge.net/download.html This addresses some terminology rendering problems in the osaterminology package used by htmldoc and appscript's help system. HTMLDictionary has also been updated. has -- http://freespace.virgin.net/hamish.sanderson/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060827/ecc290b4/attachment.html From bwaters at nrao.edu Mon Aug 28 04:22:28 2006 From: bwaters at nrao.edu (Boyd Waters) Date: Sun, 27 Aug 2006 20:22:28 -0600 Subject: [Pythonmac-SIG] Intel compilers to build Python? In-Reply-To: <6a36e7290608271551r3aeed84cye7a2532669349e99@mail.gmail.com> References: <1BF040ED-9023-41F1-BA94-364843472709@nrao.edu> <6a36e7290608271551r3aeed84cye7a2532669349e99@mail.gmail.com> Message-ID: <8D0BEF41-376A-4C7C-A9F4-EF0E14CCE1FA@nrao.edu> On Aug 27, 2006, at 4:51 PM, Bob Ippolito wrote: > On 8/27/06, Boyd Waters wrote: > >> I cannot get the Python package to build with the Intel compiler. It >> does not find the _Py_Main symbol when linking the top-level >> "python.exe". >> > > Have you tried building it with just the source, not DarwinPorts? > Thanks for the quick reply, Bob. Well, I'm the one who is hacking together the DarwinPort for using the Intel compiler, as there are no such DarwinPorts in the standard distribution. So no, it doesn't link without DP either. libtool uses the wrong thing for linking, and so fails to find the Intel libs: libtool -o Python.framework/Versions/2.4/Python -dynamic libpython2.4.a \ -lSystem -lSystemStubs -install_name /Library/Frameworks/ Python.framework/Versions/2.4/Python -compatibility_version 2.4 - current_version 2.4 ld: for architecture i386 ld: Undefined symbols: ___intel_security_check_cookie ___intel_security_cookie __intel_fast_memcpy __intel_fast_memcmp ___libm_sse2_atan2 ___libm_sse2_exp ___libm_sse2_log ___libm_sse2_sincos ___intel_cpu_indicator ___intel_cpu_indicator_init __intel_fast_memset ___divdi3 libtool: internal link edit command failed I have a patch that replaces "libtool" with "icpc -dynamiclib", which seems to link, but perhaps that does the wrong thing? If I do that manually, I get this error: $ icpc -dynamiclib -o Python.framework/Versions/2.4/Python -dynamic libpython2.4.a \ > -lSystem -lSystemStubs -arch_only i386 -install_name /opt/ local/Library/Frameworks/Python.framework/Versions/2.4/Python - compatibility_version 2.4 -current_version 2.4 $ make icpc -u _PyMac_Error Python.framework/Versions/2.4/Python -o python.exe \ Modules/ccpython.o \ -ldl ld: Undefined symbols: _PyMac_Error _Py_Main - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory Socorro, New Mexico http://www.aoc.nrao.edu/ From dan at chalkie.org.uk Mon Aug 28 09:29:31 2006 From: dan at chalkie.org.uk (Dan White) Date: Mon, 28 Aug 2006 10:29:31 +0300 Subject: [Pythonmac-SIG] install_name changing In-Reply-To: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> References: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> Message-ID: Hi Boyd, I am using the universal python build, which I guess was made with gcc comilers... I think there was a license problem using the intel compilers for python where it might be used in a commercial setting. Since our project BioImageXD is free and open source under GPL we could use an intel build, but for the sake of simplicity at the moment we will stick to the python guys universal build. Making a universal build with anython other than gcc might be tricky. Thanks for the install_name_tool tricks, it looks like that is the way I need to go ubtil i find out how to make py2app fix the install names in my .dylibs I think I will keep libguide.dylib inside my application bundle as i prefer to stick to a drag and drop .app installation if at all possible, and not use .pkg / installer . cheers Dan On Aug 28, 2006, at 1:28 AM, Boyd Waters wrote: > Dan: > > I saw your recent post on the Python-Mac SIG regarding the > difficulty that you are having using libguide.dylib in a Python > application, since you've built Python with the Intel compiler. > > > I think that you're on the right track with the install_name_tool > -- this is what I had to do to get the Intel binaries working: > >> # cd /opt/intel/cc/9.1.029/lib >> >> # for i in *.dylib >> > do >> > install_name_tool -id $(pwd)/$i $i >> > done > > Then I had to change the references to libirc.dylib in libimf and > libsvml > >> for i in libimf.dylib libsvml.dylib >> > do >> > install_name_tool -change libirc.dylib $(pwd)/libirc.dylib $i >> > done > > > When I was done, this is what it looks like: > >> $ otool -L /opt/intel/cc/9.1.029/lib/*.dylib >> /opt/intel/cc/9.1.029/lib/libguide.dylib: >> /opt/intel/cc/9.1.029/lib/libguide.dylib (compatibility >> version 4.0.0, current version 4.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, >> current version 88.1.3) >> /opt/intel/cc/9.1.029/lib/libguide_stats.dylib: >> /opt/intel/cc/9.1.029/lib/libguide_stats.dylib >> (compatibility version 4.0.0, current version 4.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, >> current version 88.1.3) >> /opt/intel/cc/9.1.029/lib/libimf.dylib: >> /opt/intel/cc/9.1.029/lib/libimf.dylib (compatibility >> version 0.0.0, current version 0.0.0) >> /opt/intel/cc/9.1.029/lib/libirc.dylib (compatibility >> version 0.0.0, current version 0.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, >> current version 88.1.3) >> /opt/intel/cc/9.1.029/lib/libirc.dylib: >> /opt/intel/cc/9.1.029/lib/libirc.dylib (compatibility >> version 0.0.0, current version 0.0.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, >> current version 88.1.3) >> /opt/intel/cc/9.1.029/lib/libsvml.dylib: >> /opt/intel/cc/9.1.029/lib/libsvml.dylib (compatibility >> version 0.0.0, current version 0.0.0) >> /opt/intel/cc/9.1.029/lib/libirc.dylib (compatibility >> version 0.0.0, current version 0.0.0) >> > > Every dynamic library is referenced using the full path. > > In my distribution, I have to re-distribute these libraries, and > put them in /opt/intel/cc/9.1.029/lib on the client. > > > > This is not the best option, but it works for the numerous open- > source packages that we use for our image-processing system. > > > I have a question for you, if you don't mind: I cannot get the > Python package to build with the Intel compiler. It does not find > the _Py_Main symbol when linking the top-level "python.exe". I > would be very happy to get pointed in the right direction regarding > compiler and linker flags for building Python 2.4.3; if we need to > use Python 2.5 then we can do that too. > > > Thanks and good luck! > > - boyd > > Boyd Waters > Scientific Programmer > National Radio Astronomy Observatory > Socorro, New Mexico > http://www.aoc.nrao.edu/ > Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From ronaldoussoren at mac.com Mon Aug 28 10:09:59 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 28 Aug 2006 10:09:59 +0200 Subject: [Pythonmac-SIG] install_name changing In-Reply-To: References: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> Message-ID: <8969F76F-6901-4337-A92F-BD5CEA17B813@mac.com> On 28-aug-2006, at 9:29, Dan White wrote: > Hi Boyd, > > I am using the universal python build, > which I guess was made with gcc comilers... That's right. > > I think there was a license problem using the intel compilers for > python > where it might be used in a commercial setting. The license is one problem, although I haven't looked very carefully at it, let alone asked Intel to clarify possible issues. Could someone who is using the Intel compiler say something about the performance of resulting binaries compared to binaries created by GCC. I'm obviously mostly interested in the speed of the python interpreter. Ronald From dan at chalkie.org.uk Mon Aug 28 10:21:17 2006 From: dan at chalkie.org.uk (Dan White) Date: Mon, 28 Aug 2006 11:21:17 +0300 Subject: [Pythonmac-SIG] intel compiler In-Reply-To: <8969F76F-6901-4337-A92F-BD5CEA17B813@mac.com> References: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> <8969F76F-6901-4337-A92F-BD5CEA17B813@mac.com> Message-ID: <6F82FAA1-E0F1-4A2C-A204-F8AF9238E037@chalkie.org.uk> > > Could someone who is using the Intel compiler say something about > the performance of resulting binaries compared to binaries created > by GCC. I'm obviously mostly interested in the speed of the python > interpreter. > > Ronald > for C++ code which is doing recursive / parallelisable tasks with processor optimisation flag -xP (for an intel core duo chip) it is faster than gcc4 with optimisation for auto vectorisation and other speed optimisations At least in my case. Of course mileage might vary... I suggest its at least worth running some benchmarks so wee what differece it makes for various kinds of tasks in python. I suppose what you are really getting with the intel compiler is their know how on how best to optimise for their chips, in this case core duo... so you benefit most where there are vectorisable loops etc, which can be thrown through the SSE processor extensions. Maybe other benefits too..... just have to test i suppose... Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From ronaldoussoren at mac.com Mon Aug 28 10:28:13 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 28 Aug 2006 10:28:13 +0200 Subject: [Pythonmac-SIG] intel compiler In-Reply-To: <6F82FAA1-E0F1-4A2C-A204-F8AF9238E037@chalkie.org.uk> References: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> <8969F76F-6901-4337-A92F-BD5CEA17B813@mac.com> <6F82FAA1-E0F1-4A2C-A204-F8AF9238E037@chalkie.org.uk> Message-ID: <09A18E52-729D-444C-BF4A-01028CF99758@mac.com> On 28-aug-2006, at 10:21, Dan White wrote: >> >> Could someone who is using the Intel compiler say something about >> the performance of resulting binaries compared to binaries created >> by GCC. I'm obviously mostly interested in the speed of the python >> interpreter. >> >> Ronald >> > > for C++ code which is doing recursive / parallelisable tasks > with processor optimisation flag -xP (for an intel core duo chip) > it is faster than gcc4 with optimisation for auto vectorisation and > other speed optimisations > > At least in my case. Of course mileage might vary... > I suggest its at least worth running some benchmarks > so wee what differece it makes for various kinds of tasks in python. I was hoping that someone had already done that :-). Having a look at the intel compiler is somewhere on my todo list, ever since a college noticed that he got higher pystones in Windows running in Parallels than running natively on the same mac. Ronald From pedz at easesoftware.com Mon Aug 28 19:42:27 2006 From: pedz at easesoftware.com (Perry Smith) Date: Mon, 28 Aug 2006 12:42:27 -0500 Subject: [Pythonmac-SIG] intel compiler In-Reply-To: <09A18E52-729D-444C-BF4A-01028CF99758@mac.com> References: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> <8969F76F-6901-4337-A92F-BD5CEA17B813@mac.com> <6F82FAA1-E0F1-4A2C-A204-F8AF9238E037@chalkie.org.uk> <09A18E52-729D-444C-BF4A-01028CF99758@mac.com> Message-ID: <9F72E33D-3E07-4412-B46B-13FB1FA8205C@easesoftware.com> Perhaps an email to gcc-help would get the info that you need. I could be the go-between but I don't feel like I know enough to convey your questions. Perry Smith Ease Software, Inc. pedz at easesoftware.com http://www.easesoftware.com AIX Kernel Level Consulting Services and SATA Products On Aug 28, 2006, at 3:28 AM, Ronald Oussoren wrote: > > On 28-aug-2006, at 10:21, Dan White wrote: > >>> >>> Could someone who is using the Intel compiler say something about >>> the performance of resulting binaries compared to binaries created >>> by GCC. I'm obviously mostly interested in the speed of the python >>> interpreter. >>> >>> Ronald >>> >> >> for C++ code which is doing recursive / parallelisable tasks >> with processor optimisation flag -xP (for an intel core duo chip) >> it is faster than gcc4 with optimisation for auto vectorisation and >> other speed optimisations >> >> At least in my case. Of course mileage might vary... >> I suggest its at least worth running some benchmarks >> so wee what differece it makes for various kinds of tasks in python. > > I was hoping that someone had already done that :-). Having a look at > the intel compiler is somewhere on my todo list, ever since a college > noticed that he got higher pystones in Windows running in Parallels > than running natively on the same mac. > > Ronald > _______________________________________________ > 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/20060828/e5159324/attachment.html From ronaldoussoren at mac.com Mon Aug 28 22:00:51 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 28 Aug 2006 22:00:51 +0200 Subject: [Pythonmac-SIG] intel compiler In-Reply-To: <9F72E33D-3E07-4412-B46B-13FB1FA8205C@easesoftware.com> References: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> <8969F76F-6901-4337-A92F-BD5CEA17B813@mac.com> <6F82FAA1-E0F1-4A2C-A204-F8AF9238E037@chalkie.org.uk> <09A18E52-729D-444C-BF4A-01028CF99758@mac.com> <9F72E33D-3E07-4412-B46B-13FB1FA8205C@easesoftware.com> Message-ID: <9E70A372-F116-4635-BB24-52D04B105D60@mac.com> On 28-aug-2006, at 19:42, Perry Smith wrote: > Perhaps an email to gcc-help would get the info that you need. I > could be the go-between but I don't feel like I know enough to > convey your questions. IMHO only benchmarks will help us here. At the very minimal I'd like to know how pystone compares on a python build with the Intel compiler and the version of GCC that ships with Xcode. If the difference is significant it could be useful to spent more time on doing other benchmarks as well and maybe eventually find a way to add support for the intel compiler to distutils (and if the license allows that to distribute a universal build of python where the intel part is build using the intel compiler). It is pretty unlikely at the moment that I'll do the benchmarking, as python is fast enough for my needs and I don't have much time to work on this. Ronald > > Perry Smith > Ease Software, Inc. > pedz at easesoftware.com > http://www.easesoftware.com > > AIX Kernel Level Consulting Services and SATA Products > > > > On Aug 28, 2006, at 3:28 AM, Ronald Oussoren wrote: > >> >> On 28-aug-2006, at 10:21, Dan White wrote: >> >>>> >>>> Could someone who is using the Intel compiler say something about >>>> the performance of resulting binaries compared to binaries created >>>> by GCC. I'm obviously mostly interested in the speed of the python >>>> interpreter. >>>> >>>> Ronald >>>> >>> >>> for C++ code which is doing recursive / parallelisable tasks >>> with processor optimisation flag -xP (for an intel core duo chip) >>> it is faster than gcc4 with optimisation for auto vectorisation and >>> other speed optimisations >>> >>> At least in my case. Of course mileage might vary... >>> I suggest its at least worth running some benchmarks >>> so wee what differece it makes for various kinds of tasks in python. >> >> I was hoping that someone had already done that :-). Having a look at >> the intel compiler is somewhere on my todo list, ever since a college >> noticed that he got higher pystones in Windows running in Parallels >> than running natively on the same mac. >> >> Ronald >> _______________________________________________ >> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >> http://mail.python.org/mailman/listinfo/pythonmac-sig >> > From pedz at easesoftware.com Mon Aug 28 23:20:40 2006 From: pedz at easesoftware.com (Perry Smith) Date: Mon, 28 Aug 2006 16:20:40 -0500 Subject: [Pythonmac-SIG] python wsdl newbie question Message-ID: I'm new to python, SOAP, and WSDL. I have my XXX.wsdl file. I know how to connect and do method calls. The interface to the web service I'm using has various classes. My question is how do I create (instantiate) one of those classes? Thank you, Perry Smith Ease Software, Inc. pedz at easesoftware.com http://www.easesoftware.com AIX Kernel Level Consulting Services and SATA Products -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060828/83c6cc0b/attachment.htm From dan at chalkie.org.uk Tue Aug 29 03:28:59 2006 From: dan at chalkie.org.uk (Dan White) Date: Tue, 29 Aug 2006 04:28:59 +0300 Subject: [Pythonmac-SIG] intel compiler In-Reply-To: <9E70A372-F116-4635-BB24-52D04B105D60@mac.com> References: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> <8969F76F-6901-4337-A92F-BD5CEA17B813@mac.com> <6F82FAA1-E0F1-4A2C-A204-F8AF9238E037@chalkie.org.uk> <09A18E52-729D-444C-BF4A-01028CF99758@mac.com> <9F72E33D-3E07-4412-B46B-13FB1FA8205C@easesoftware.com> <9E70A372-F116-4635-BB24-52D04B105D60@mac.com> Message-ID: <49225116-5BA5-453B-8127-B9308572BC90@chalkie.org.uk> Hi, when my MacBookPro comes back from hospital, I can try the pystone benchmarks with intel and gcc .... one of my processor fans died.. Dan On Aug 28, 2006, at 11:00 PM, Ronald Oussoren wrote: > > On 28-aug-2006, at 19:42, Perry Smith wrote: > >> Perhaps an email to gcc-help would get the info that you need. I >> could be the go-between but I don't feel like I know enough to >> convey your questions. > > IMHO only benchmarks will help us here. At the very minimal I'd > like to know how pystone compares on a python build with the Intel > compiler and the version of GCC that ships with Xcode. If the > difference is significant it could be useful to spent more time on > doing other benchmarks as well and maybe eventually find a way to > add support for the intel compiler to distutils (and if the license > allows that to distribute a universal build of python where the > intel part is build using the intel compiler). > > It is pretty unlikely at the moment that I'll do the benchmarking, > as python is fast enough for my needs and I don't have much time to > work on this. > > Ronald > >> >> Perry Smith >> Ease Software, Inc. >> pedz at easesoftware.com >> http://www.easesoftware.com >> >> AIX Kernel Level Consulting Services and SATA Products >> >> >> >> On Aug 28, 2006, at 3:28 AM, Ronald Oussoren wrote: >> >>> >>> On 28-aug-2006, at 10:21, Dan White wrote: >>> >>>>> >>>>> Could someone who is using the Intel compiler say something about >>>>> the performance of resulting binaries compared to binaries created >>>>> by GCC. I'm obviously mostly interested in the speed of the python >>>>> interpreter. >>>>> >>>>> Ronald >>>>> >>>> >>>> for C++ code which is doing recursive / parallelisable tasks >>>> with processor optimisation flag -xP (for an intel core duo chip) >>>> it is faster than gcc4 with optimisation for auto vectorisation and >>>> other speed optimisations >>>> >>>> At least in my case. Of course mileage might vary... >>>> I suggest its at least worth running some benchmarks >>>> so wee what differece it makes for various kinds of tasks in >>>> python. >>> >>> I was hoping that someone had already done that :-). Having a >>> look at >>> the intel compiler is somewhere on my todo list, ever since a >>> college >>> noticed that he got higher pystones in Windows running in Parallels >>> than running natively on the same mac. >>> >>> Ronald >>> _______________________________________________ >>> Pythonmac-SIG maillist - Pythonmac-SIG at python.org >>> http://mail.python.org/mailman/listinfo/pythonmac-sig >>> >> > Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From bwaters at nrao.edu Tue Aug 29 04:28:34 2006 From: bwaters at nrao.edu (Boyd Waters) Date: Mon, 28 Aug 2006 20:28:34 -0600 Subject: [Pythonmac-SIG] Intel compilers to build Python? In-Reply-To: <8D0BEF41-376A-4C7C-A9F4-EF0E14CCE1FA@nrao.edu> References: <1BF040ED-9023-41F1-BA94-364843472709@nrao.edu> <6a36e7290608271551r3aeed84cye7a2532669349e99@mail.gmail.com> <8D0BEF41-376A-4C7C-A9F4-EF0E14CCE1FA@nrao.edu> Message-ID: <22B70310-4145-4AA8-ADC0-66A92A0222B2@nrao.edu> On Aug 27, 2006, at 8:22 PM, Boyd Waters wrote: > I'm the one who is hacking together the DarwinPort for using the > Intel compiler This is probably arrogance on my part. But I could not find a recipe for building Python with the Intel compiler, so I created one. I have just finished building Python-2.5c1 (release candidate 1) with the Intel compiler (9.1.029) on a Mac Pro. This might lead to performance benefits with downstream plugins like NumPy, but it is more likely to lead to compatibility issues with those modules. I don't know yet. Anyway, I patched two files: the configure shell script, and the Mac/ PythonLauncher Makefile.in -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.diff Type: application/octet-stream Size: 1168 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060828/8720ec87/attachment-0002.obj -------------- next part -------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: Mac-PythonLauncher-Makefile.in.diff Type: application/octet-stream Size: 437 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060828/8720ec87/attachment-0003.obj -------------- next part -------------- The Mac/PythonLauncher/Makefile.in patch simply forces the use of GCC to compile Objective-C files in the Mac Cocoa launcher. The configure file slightly modifies the linking of top-level python.exe I applied the patches like this: # cd Python-2.5c1 # patch -p0 < ~/Mac-PythonLauncher-Makefile.in.diff # patch < ~/configure.diff I invoked configure like this: # CC=icc CXX=icpc OPT="-xT -O3 -fstack-security-check -fpic - parallel" ICC_LIBS="-L/opt/intel/cc/9.1.029/lib -lirc -limf" ./ configure --enable-framework This tells the compiler to optimize for the Woodcrest or Merom processor; to optimize for Core Solo/Duo, use -xP. I can reliably trip a compiler error if I use -axT, which tries to accommodate both types of processor. I build like this: # make -j4 # sudo make frameworkinstall This goes rather quickly on a four-core Mac Pro. This afternoon my colleagues came by to see what I was working on, gave me encouraging comments like "Hey, you can get it to crash that much faster on the new Mac..." I'll have a DarwinPort real soon... Feedback is welcome. - boyd From bwaters at nrao.edu Tue Aug 29 04:43:02 2006 From: bwaters at nrao.edu (Boyd Waters) Date: Mon, 28 Aug 2006 20:43:02 -0600 Subject: [Pythonmac-SIG] intel compiler In-Reply-To: <9E70A372-F116-4635-BB24-52D04B105D60@mac.com> References: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> <8969F76F-6901-4337-A92F-BD5CEA17B813@mac.com> <6F82FAA1-E0F1-4A2C-A204-F8AF9238E037@chalkie.org.uk> <09A18E52-729D-444C-BF4A-01028CF99758@mac.com> <9F72E33D-3E07-4412-B46B-13FB1FA8205C@easesoftware.com> <9E70A372-F116-4635-BB24-52D04B105D60@mac.com> Message-ID: <0B183808-F4F1-44E1-9902-EE5A5E690DE9@nrao.edu> On Aug 28, 2006, at 2:00 PM, Ronald Oussoren wrote: > IMHO only benchmarks will help us here. At the very minimal I'd like > to know how pystone compares on a python build with the Intel > compiler and the version of GCC that ships with Xcode. I could post results, can someone suggest a way to run pystone that is meaningful? - boyd Boyd Waters Scientific Programmer National Radio Astronomy Observatory http://www.aoc.nrao.edu/ From marcink at ieee.org Tue Aug 29 06:49:44 2006 From: marcink at ieee.org (Marcin Komorowski) Date: Tue, 29 Aug 2006 00:49:44 -0400 Subject: [Pythonmac-SIG] Please critique my first appscript - a fix for Palm sync of iCal Tasks (for kGTD) Message-ID: I am in the process of learning Python and appscript, and I wrote my first script using these two technologies. Please kindly critique my code - what could I have done better? What would have made this code more Pythonic? Any suggestions and comments are greatly appreciated. Thank You in advance, Marcin --------------------------------------- #!/usr/bin/env /usr/bin/pythonw from appscript import * import sys import cPickle import pprint import datetime def myDebug( txt ): if txt == None: sys.stderr.flush() else: sys.stderr.write( txt ) def getTaskList(): appCal = app( 'iCal' ) cal_todos = appCal.calendars.filter(its.name != '').todos.properties() tasks = [ todo for cals in cal_todos for todo in cals] # Iterate flattened list, builing a local dictionary of dictionaries, by uid tasks_data = {} for task in tasks: if task[ k.class__ ] == k.todo: uid = task[ k.uid ] tasks_data[uid] = task; myDebug('.') myDebug(None) myDebug('\n') return tasks_data def exportTaskListToFile( t_data, filename ): cPickle.dump( t_data, open( filename, 'w' ) ) def importTaskListFromFile( filename ): return cPickle.load( open( filename, 'r' ) ) k_decode = { k.priority : "k.priority", k.due_date : "k.due_date", k.completion_date : "k.completion_date", k.description : "k.description", k.url : "k.url", k.uid : "k.uid", k.summary : "k.summary", k.class__ : "k.class__" } def diffTaskLists( task_list1, task_list2 ): diff_list = [] for uid in [ id for id in task_list1.keys() if task_list2.has_key( id ) ]: t1 = task_list1[uid] t2 = task_list2[uid] found_difference = False for field in [ k.priority, k.due_date, k.completion_date, k.description, k.url, k.summary ]: if t1[field] != t2[field]: if found_difference == False: myDebug( " task ID %s:\n" % str( uid ) ) myDebug( " field %s: " % k_decode[field] ); try: myDebug( "t1 = '%s' t2 = '%s'" % ( t1[field], t2 [field] ) ) except: pass myDebug( "\n" ) found_difference = True break if found_difference and t1[k.stamp_date] == t2[k.stamp_date]: diff_list.append( uid ) return diff_list def updateTimeStamp( task_uid_list, timestamp ): myDebug( "Setting new timestamp for task UIDs %s\n" % repr ( task_uid_list ) ) for task_uid in task_uid_list: task_list = [ t for t in app('iCal').calendars.todos.filter ( its.uid == task_uid ).get() if t != k.MissingValue ] if len( task_list ) > 1: sys.stderr.write( "ERROR: found two tasks with UID %s, updating timestamp for both" % task_uid ) for t in task_list: t.stamp_date.set( timestamp ) def usage(): print "USAGE: " + sys.argv[0] + " save|check" def main(mode): if mode != 'save' and mode != 'check': usage() return myDebug( "Getting list of tasks from iCal...\n" ) tasks = getTaskList() pp = pprint.PrettyPrinter(indent=4) myDebug( "%d tasks\n" % len( tasks ) ) if mode == 'save': myDebug( "Saving current iCal tasks...\n" ) exportTaskListToFile( tasks, 'presync_task_save.tmp' ) sys.stdout.write( "%d tasks saved.\n" % len( tasks ) ) else: myDebug( "Getting saved iCal tasks...\n" ) ref_tasks = importTaskListFromFile( 'presync_task_save.tmp' ) myDebug( "Comparing iCal tasks...\n" ); diff_list = diffTaskLists( ref_tasks, tasks ) pp.pprint( diff_list ) myDebug( "Updating timestamps...\n" ); new_timestamp = datetime.datetime.today() updateTimeStamp( diff_list, new_timestamp ) myDebug( "Done.\n" ) sys.stdout.write( "%d timestamps updated.\n" % len ( diff_list ) ) if __name__ == '__main__': if len( sys.argv ) < 2: usage() else: main( sys.argv[1] ) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/pythonmac-sig/attachments/20060829/66968ec5/attachment.htm From ronaldoussoren at mac.com Tue Aug 29 09:04:30 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 29 Aug 2006 09:04:30 +0200 Subject: [Pythonmac-SIG] Intel compilers to build Python? In-Reply-To: <22B70310-4145-4AA8-ADC0-66A92A0222B2@nrao.edu> References: <1BF040ED-9023-41F1-BA94-364843472709@nrao.edu> <6a36e7290608271551r3aeed84cye7a2532669349e99@mail.gmail.com> <8D0BEF41-376A-4C7C-A9F4-EF0E14CCE1FA@nrao.edu> <22B70310-4145-4AA8-ADC0-66A92A0222B2@nrao.edu> Message-ID: <6E3A9C51-A1E2-4654-8E7C-56A3A755A509@mac.com> On 29-aug-2006, at 4:28, Boyd Waters wrote: > > Feedback is welcome. How fast is your intel-compiled version of python compared to a gcc- compiled one? Pystone is a good first approximation for that. Ronald From ronaldoussoren at mac.com Tue Aug 29 09:09:41 2006 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Tue, 29 Aug 2006 09:09:41 +0200 Subject: [Pythonmac-SIG] intel compiler In-Reply-To: <0B183808-F4F1-44E1-9902-EE5A5E690DE9@nrao.edu> References: <8607DA33-C9B1-4512-86FB-ACCF1772A1CF@nrao.edu> <8969F76F-6901-4337-A92F-BD5CEA17B813@mac.com> <6F82FAA1-E0F1-4A2C-A204-F8AF9238E037@chalkie.org.uk> <09A18E52-729D-444C-BF4A-01028CF99758@mac.com> <9F72E33D-3E07-4412-B46B-13FB1FA8205C@easesoftware.com> <9E70A372-F116-4635-BB24-52D04B105D60@mac.com> <0B183808-F4F1-44E1-9902-EE5A5E690DE9@nrao.edu> Message-ID: <4F6DFBA0-C962-4F3F-B6AC-B868C4CB16F2@mac.com> On 29-aug-2006, at 4:43, Boyd Waters wrote: > > On Aug 28, 2006, at 2:00 PM, Ronald Oussoren wrote: > >> IMHO only benchmarks will help us here. At the very minimal I'd like >> to know how pystone compares on a python build with the Intel >> compiler and the version of GCC that ships with Xcode. > > I could post results, can someone suggest a way to run pystone that > is meaningful? Just run it? Python Lib/test/pystone.py, or alternatively python -c 'from test.pystone import *; main()'. You should probably run pystone several times and report the best version (highest pystones/second value). What I'd like to see is the pystone results from both an intel and gcc compiled version of python from the same python sources and on the same machine. Ronald From dan at chalkie.org.uk Tue Aug 29 10:46:21 2006 From: dan at chalkie.org.uk (Dan White) Date: Tue, 29 Aug 2006 11:46:21 +0300 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 40, Issue 25 In-Reply-To: References: Message-ID: On Aug 29, 2006, at 5:28 AM, pythonmac-sig-request at python.org wrote: > patches like this: > > # cd Python-2.5c1 > # patch -p0 < ~/Mac-PythonLauncher-Makefile.in.diff > # patch < ~/configure.diff > > > I invoked configure like this: > > # CC=icc CXX=icpc OPT="-xT -O3 -fstack-security-check -fpic - > parallel" ICC_LIBS="-L/opt/intel/cc/9.1.029/lib -lirc -limf" ./ > configure --enable-framework > > This tells the compiler to optimize for the Woodcrest or Merom > processor; to optimize for Core Solo/Duo, use -xP. I can reliably > trip a compiler error if I use -axT, which tries to accommodate > both types of processor. Boyd you might already know the newest version of the intel compilers is version 30... so you might want to try that... so what about a build that is compatible with both core duo/solo and the Woodcrest/Merom ? Did you spot what compiler flags to use for that? Should it in fact be -axT, or is that a bogus flag? We are gonna have to so that for building software to distribute... Dan Dr. Daniel James White BSc. (Hons.) PhD Bioimaging Coordinator Nanoscience Centre and Department of Biological and Environmental Sciences Division of Molecular Recognition Ambiotica C242 PO Box 35 University of Jyv?skyl? Jyv?skyl? FIN 40014 Finland +358 14 260 4183 (work) +358 468102840 (mobile) http://www.bioimagexd.org http://www.chalkie.org.uk dan at chalkie.org.uk white at cc.jyu.fi From bwaters at nrao.edu Tue Aug 29 17:55:33 2006 From: bwaters at nrao.edu (Boyd Waters) Date: Tue, 29 Aug 2006 09:55:33 -0600 Subject: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 40, Issue 25 In-Reply-To: References: Message-ID: <13B27593-8642-4044-8E1B-85BD51A8BF84@nrao.edu> On Aug 29, 2006, at 2:46 AM, Dan White wrote: > you might already know the newest version of the intel compilers is > version 30... > so you might want to try that... Thanks for the tip, Dan! But Intel screwed up my licensing on the 9.1.030 release, so I can't use it, I've been trying to get a license from them for five days. Warning to all Mac users considering the Intel compilers: they generate great code, produce great warning messages, can help you clean up your projects. And the licensing is a real stumbling block. I don't think the re-distributables are an issue, frankly, from my reading of the user license. It's the logistics of procuring the product and maintaining the license files where our group is having trouble. With the update to 9.1.30, the compiler suddenly demanded a new FLEXlm license, contradicting the terms of our purchase, but try explaining that to a computer program... Okay. Rant over. For all that, Intel tech support has been very responsive. I honestly believe that the Intel compiler team is excited about the Macintosh platform... Another caveat is that the Intel compiler is 32-bit only at the moment. The GCC compiler seems to produce 64-bit code on my Mac Pro with the "-m64" switch, but I have to investigate this further. I'll try building with the 9.1.03x compiler as soon as I resolve the licensing issue. Can anyone out there in Pythonmac-SIG-land reproduce my recipe for Intel-compiler-built Python? I'm interested in results. Note that it isn't a fat binary, it's Intel-only... I'd like some suggestions for running pystone on this build. Thanks all! - boyd -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2361 bytes Desc: not available Url : http://mail.python.org/pipermail/pythonmac-sig/attachments/20060829/ae650594/attachment.bin From Chris.Barker at noaa.gov Tue Aug 29 19:31:51 2006 From: Chris.Barker at noaa.gov (root) Date: Tue, 29 Aug 2006 10:31:51 -0700 Subject: [Pythonmac-SIG] Please critique my first appscript - a fix for Palm sync of iCal Tasks (for kGTD) In-Reply-To: References: Message-ID: <44F47A07.4020800@noaa.gov> Marcin Komorowski wrote: > Please kindly critique my code - what could I have done better? What > would have made this code more Pythonic? I now nothing of appscript, and didn't even read it all, but a comment none the less. > def myDebug( txt ): > if txt == None: > sys.stderr.flush() > else: > sys.stderr.write( txt ) You should use: if txt is None: the equality operator can be overloaded, so you can't count on it for None. However, you could probably just do: def myDebug( txt ): if txt: sys.stderr.write( txt ) else: sys.stderr.flush() that will flush on both None and an empty string (or anything else that evaluates to False). -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 njriley at uiuc.edu Tue Aug 29 20:47:19 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Tue, 29 Aug 2006 13:47:19 -0500 Subject: [Pythonmac-SIG] Please critique my first appscript - a fix for Palm sync of iCal Tasks (for kGTD) In-Reply-To: References: Message-ID: <20060829184719.GA67148@uiuc.edu> These are (mostly) all issues of personal opinion, but anyway... On Tue, Aug 29, 2006 at 12:49:44AM -0400, Marcin Komorowski wrote: >#!/usr/bin/env /usr/bin/pythonw There's no point of using env if you specify an absolute path. "#!/usr/bin/env pythonw" is probably what you want. > def myDebug( txt ): > if txt == None: > sys.stderr.flush() > else: > sys.stderr.write( txt ) stderr should be unbuffered by default; you shouldn't need to flush it at all. Also, if you've got a sentinel value, try representing it with a default/optional argument, e.g.: def myDebug(txt, flush=False): or: def myDebug(txt=None): > def getTaskList(): > appCal = app( 'iCal' ) Use a bundle ID or creator to refer to iCal, in case it is renamed. > cal_todos = appCal.calendars.filter(its.name != > '').todos.properties() > tasks = [ todo for cals in cal_todos for todo in cals] Consider being more consistent about spacing - see PEP 8 for one possible coding style. Also, wow, I never noticed how backwards reading nested list comprehensions is - yuck (Python problem, not yours...). > # Iterate flattened list, builing a local dictionary of > dictionaries, by uid > tasks_data = {} > for task in tasks: > if task[ k.class__ ] == k.todo: Why do you need to do this? It seems if you ask for todos, all you get is todos, right? :) If you're working around some iCal bug it makes sense to comment it. > uid = task[ k.uid ] > tasks_data[uid] = task; > myDebug('.') > myDebug(None) You could do the above with a generator expression, e.g: tasks_data = dict((todo[k.uid], todo) for todos in cal_todos for todo in todos if todo[k.class__] == k.todo) (this should be fast enough; I can't imagine it'd be worth displaying progress) > k_decode = { > k.priority : "k.priority", > k.due_date : "k.due_date", > k.completion_date : "k.completion_date", > k.description : "k.description", > k.url : "k.url", > k.uid : "k.uid", > k.summary : "k.summary", > k.class__ : "k.class__" > } There's no need to do this; you can just print k.priority, etc., directly. > def diffTaskLists( task_list1, task_list2 ): > diff_list = [] > for uid in [ id for id in task_list1.keys() if > task_list2.has_key( id ) ]: You can use 'id in task_list2' instead of 'task_list2.has_key(id)'. For clarity (if not necessarily speed) you might consider using the set data type instead. > t1 = task_list1[uid] > t2 = task_list2[uid] > found_difference = False > for field in [ k.priority, k.due_date, k.completion_date, > k.description, k.url, k.summary ]: > if t1[field] != t2[field]: > if found_difference == False: I generally find it easier to read "if not found_difference". > myDebug( " task ID %s:\n" % str( uid ) ) You don't need to use 'str', that's what %s does already. And don't be afraid of the print statement, e.g.: print >> sys.stderr, ' task ID %s:' % uid > myDebug( " field %s: " % k_decode[field] ); > try: > myDebug( "t1 = '%s' t2 = '%s'" % ( t1[field], t2 > [field] ) ) > except: > pass Eww. If there are problems converting the fields to a string, you should address them (or report a bug in appscript or iCal...) At the very list, make your except statement more specific so it doesn't mask other exceptions. > myDebug( "\n" ) > found_difference = True > break Huh, what's the point of checking 'found_difference' then, if you break immediately after setting it to true? Looks like you can get rid of it completely. > def updateTimeStamp( task_uid_list, timestamp ): > myDebug( "Setting new timestamp for task UIDs %s\n" % repr > ( task_uid_list ) ) You can use '%r' % task_uid_list to get the repr. > def usage(): > print "USAGE: " + sys.argv[0] + " save|check" It's a bit more efficient (and clearer, IMO) to use commas to give print multiple arguments rathern than using + to concatenate strings. > def main(mode): > if mode != 'save' and mode != 'check': if mode not in ('save', check'): > pp = pprint.PrettyPrinter(indent=4) Since you only use this once, it makes sense to move it closer to its definition and/or combine the creation and invocation. -- Nicholas Riley | From hengist.podd at virgin.net Wed Aug 30 15:53:42 2006 From: hengist.podd at virgin.net (has) Date: Wed, 30 Aug 2006 14:53:42 +0100 Subject: [Pythonmac-SIG] Please critique my first appscript - a fix for Palm sync of iCal Tasks (for kGTD) In-Reply-To: References: Message-ID: <667C8537-F188-4392-AB9C-5D65812A86A5@virgin.net> Marcin Komorowski wrote: > Please kindly critique my code - what could I have done better? > What would have made this code more Pythonic? Not familiar with Palm syncing or related iCal issues, but a few minor pointers on the appscript side, FWIW: (Note: these comments apply to the latest appscript 0.16.2 release, though I recommend upgrading as soon as is convenient.) > #!/usr/bin/env /usr/bin/pythonw 'pythonw' is no longer required by appscript; 'python' is fine. 'pythonw' is only needed when using the osax package to display dialog boxes. > cal_todos = appCal.calendars.filter(its.name != > '').todos.properties() The filter() method will be going away in appscript 0.17.0. The new filter syntax is: cal_todos = appCal.calendars[its.name != ''].todos.properties() The current release supports both forms to provide users a period of grace in which to update their existing scripts. > if task[ k.class__ ] == k.todo: This test shouldn't be necessary, as the previous query should only return todos. Also, not sure where the k.class__ thing was coming from (presumably a bug in an earlier version) but it's now k.class_, which is correct. > k_decode = { > k.priority : "k.priority", > k.due_date : "k.due_date", > k.completion_date : "k.completion_date", > k.description : "k.description", > k.url : "k.url", > k.uid : "k.uid", > k.summary : "k.summary", > k.class__ : "k.class__" > } This table is unnecessary as Keyword objects can provide their own string representations. Just delete it and change: > myDebug( " field %s: " % k_decode[field] ); to: myDebug( " field %s: " % field ) HTH has -- http://freespace.virgin.net/hamish.sanderson/ From bwinton at latte.ca Wed Aug 30 18:48:14 2006 From: bwinton at latte.ca (Blake Winton) Date: Wed, 30 Aug 2006 12:48:14 -0400 Subject: [Pythonmac-SIG] MacPython/Subversion/Apache question Message-ID: <44F5C14E.2090106@latte.ca> Hello, I'm trying to get Subversion bindings for my installed version of MacPython (/Library/Frameworks/Python.framework/Versions/2.4/) This seems to mean that I want to install Subversion, and if so, I would like to get it hooked up to Apache so that I can connect to http://svn.latte.ca/ (or whatever) on my work computer and access my home repository. Now, I can install the subversion python bindings using DarwinPorts, but that won't hook into the Framework version of Python, so I've downloaded the Subversion 1.3.2 sources, and I can build them, but they complain about my version of Apache. Specifically, about apxs being too old. Do I really need to upgrade apache to Apache 2 to get this all working? Is there a good way of replacing the default Apache with Apache 2, or is that a really bad idea because the Software Update will get horribly confused? Is there another place I should be asking these questions? Thanks, Blake. From marc at precipice.org Wed Aug 30 19:08:16 2006 From: marc at precipice.org (Marc Hedlund) Date: Wed, 30 Aug 2006 12:08:16 -0500 (CDT) Subject: [Pythonmac-SIG] MacPython/Subversion/Apache question In-Reply-To: <44F5C14E.2090106@latte.ca> References: <44F5C14E.2090106@latte.ca> Message-ID: Try pysvn. I think it installed without any dependencies for me. http://pysvn.tigris.org/servlets/ProjectDocumentList?folderID=2860 Works great. -M On Wed, 30 Aug 2006, Blake Winton wrote: > Hello, > > I'm trying to get Subversion bindings for my installed version of > MacPython (/Library/Frameworks/Python.framework/Versions/2.4/) This > seems to mean that I want to install Subversion, and if so, I would like > to get it hooked up to Apache so that I can connect to > http://svn.latte.ca/ (or whatever) on my work computer and access my > home repository. > > Now, I can install the subversion python bindings using DarwinPorts, but > that won't hook into the Framework version of Python, so I've downloaded > the Subversion 1.3.2 sources, and I can build them, but they complain > about my version of Apache. Specifically, about apxs being too old. > > Do I really need to upgrade apache to Apache 2 to get this all working? > > Is there a good way of replacing the default Apache with Apache 2, or is > that a really bad idea because the Software Update will get horribly > confused? > > Is there another place I should be asking these questions? > > Thanks, > Blake. > > _______________________________________________ > Pythonmac-SIG maillist - Pythonmac-SIG at python.org > http://mail.python.org/mailman/listinfo/pythonmac-sig > From njriley at uiuc.edu Wed Aug 30 19:43:32 2006 From: njriley at uiuc.edu (Nicholas Riley) Date: Wed, 30 Aug 2006 12:43:32 -0500 Subject: [Pythonmac-SIG] MacPython/Subversion/Apache question In-Reply-To: <44F5C14E.2090106@latte.ca> References: <44F5C14E.2090106@latte.ca> Message-ID: <20060830174332.GA76589@uiuc.edu> On Wed, Aug 30, 2006 at 12:48:14PM -0400, Blake Winton wrote: > Now, I can install the subversion python bindings using DarwinPorts, but > that won't hook into the Framework version of Python, so I've downloaded > the Subversion 1.3.2 sources, and I can build them, but they complain > about my version of Apache. Specifically, about apxs being too old. > > Do I really need to upgrade apache to Apache 2 to get this all working? Yes, mod_dav_svn only works with Apache 2. > Is there a good way of replacing the default Apache with Apache 2, or is > that a really bad idea because the Software Update will get horribly > confused? You can copy /System/Library/StartupItems/Apache to /Library/StartupItems/Apache and change the paths to use your DarwinPorts-installed Apache 2 (assuming DarwinPorts doesn't already do something equivalent). Do not replace Apple's Apache installation; Mac OS X Server, for example, includes both Apache 1.3 and Apache 2; a future version of Mac OS X will likely be Apache 2-only. > Is there another place I should be asking these questions? Probably best on the Subversion users mailing list. -- Nicholas Riley | From mscott at springfieldtech.com Thu Aug 31 18:13:24 2006 From: mscott at springfieldtech.com (Matthew Scott) Date: Thu, 31 Aug 2006 11:13:24 -0500 Subject: [Pythonmac-SIG] Using pyqt4 with py2app trunk Message-ID: <44F70AA4.1070800@springfieldtech.com> I'm getting acquainted with PyQt4 lately, to build a GPL'd app intended to be used at least on OSX and Linux. I ran into this problem when trying to use py2app r44 from http://svn.pythonmac.org/py2app/py2app/trunk : http://mail.python.org/pipermail/pythonmac-sig/2006-April/017325.html Specifically, 'AttributeError: "qt_lib_dir" is not a valid configuration value or user option' This is definitely not the best thing to merge into py2app itself, but to kickstart a renewed discussion, here's the patch I applied to it in order to get a successful app build. Any assistance or ideas on how to generalize this in a way that could be folded into the py2app trunk are appreciated: Index: py2app/recipes/sip.py =================================================================== --- py2app/recipes/sip.py (revision 44) +++ py2app/recipes/sip.py (working copy) @@ -13,8 +13,15 @@ except NameError: from sets import Set as set - cfg = sipconfig.Configuration() + # XXX: PyQt4 hack. + # Original: + ## cfg = sipconfig.Configuration() + ## qtdir = cfg.qt_lib_dir + # Modified: + from PyQt4 import pyqtconfig + cfg = pyqtconfig.Configuration() qtdir = cfg.qt_lib_dir + # /XXX if not os.path.exists(qtdir): # half-broken installation? ignore. raise ImportError Relevant system info: System: OSX 10.4.7 build 8J2135 Intel Core Duo processor Universal framework build of Python: Python 2.4.3 (#1, Apr 7 2006, 10:54:33) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin Qt4 and PyQt4 (both GPL editions): >>>from PyQt4 import QtCore >>>QtCore.QT_VERSION_STR ---'4.1.4' >>>QtCore.PYQT_VERSION_STR ---'4.0.1' -- Matthew Scott mscott at springfieldtech.com From vip at avatar.com.au Tue Aug 29 08:09:25 2006 From: vip at avatar.com.au (David Worrall) Date: Tue, 29 Aug 2006 16:09:25 +1000 Subject: [Pythonmac-SIG] importing dynamic library on intelMac Message-ID: <72D50B39-9E28-46DF-9694-42C8726E677B@avatar.com.au> Hello All, I'm new here... and to dynamic libraries.... I've compiled a 3rd party's dynamic library , libXXX.dylib , a Mach- O dynamically linked shared library i386 and can't work out where to put it so that I can >>> import XXX is there a special place for such libraries? I've tried a few things without success. Would someone be kind enough to put me on the right path - [do I need to specifically have a dynamic libraries directory in my $PYTHONPATH for eg, and if so where should it be?] many thanks, David intelMac OS10.4.9 /Library/Frameworks/Python.framework/Versions/Current/bin/python Python 2.4.3 (#1, Mar 30 2006, 11:02:16) [GCC 4.0.1 (Apple Computer, Inc. build 5250)] on darwin _______________________________________ experimental polymedia: www.avatar.com.au Sonic Communications Research Group, University of Canberra: www.canberra.edu.au From cody.brocious at mp3tunes.com Wed Aug 30 22:34:30 2006 From: cody.brocious at mp3tunes.com (Cody Brocious) Date: Wed, 30 Aug 2006 13:34:30 -0700 Subject: [Pythonmac-SIG] Py2App + PyQt4 Universal Message-ID: Hey All, I recently hacked SIP and PyQt4 to build universal binaries and they seem to be working well. However, when I attempt to package them with py2app, it seems to find a circular dependency between QtCore and QtGui and copies them over and over into the build directory. Is there any way I can override the module graphing for this case, or even better, solve the underlying issue? Both options would be great, although the correct option would be nice to have for the long term. Any help would be appreciated. Thanks in advance, - Cody Brocious