Re: [Pythonmac-SIG] Python completion in emacs fails on OSX
This is really an Emacs issue, not a Python issue. I don't even see where they say they are both using the version of the Python interpreter. Bill Leo sdl@gmail.com wrote: It seems the python interpreter built by Apple doesn't behave like the ones built from upstream. See this: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10295#19 Any idea what's happened to python from apple? Leo ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Problems with CoreGraphics API post-Snow Leopard
João Leão joaol...@gmx.net wrote: But now I'm getting another error (and I'll probably get some more) with another function that expects a CGFloat object instead of a plain integer. The code looks like this: --- self.pdf.drawPlainTextInRect(text_prov, textRect, 10) --- And the error (again caused by the last argument, in this case 10): --- TypeError: in method 'CGContext_drawPlainTextInRect', argument 4 of type 'CGFloat' --- I'm sure that it can't be so hard to create a CGFloat but I didn't find the right documentation or sample code to do it. Does anybody know how to do this? Did you try self.pdf.drawPlainTextInRect(text_prov, textRect, 10.0)? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python on iphone for developers
Alex Jouravlev al...@businessabstraction.com wrote: Is there a port of Python to iPhone? I want to be able to check-out from SVN, edit and run some Python server code now and then. See https://github.com/cobbal/python-for-iphone/blob/master/iOS-build.sh. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python on iphone for developers
Dan Ross d...@rosspixelworks.com wrote: So how does one use this to make an iOS app then? That's an exercise for the reader. Basically, you build an Objective-C iOS app, but implement the callbacks and program logic as thin C wrappers that call into Python to get things done. This is simpler with a working PyObjC for iOS, of course, but I don't know what the status of that is. Bill On Thu, 4 Aug 2011 11:58:58 PDT, Bill Janssen wrote: Alex Jouravlev al...@businessabstraction.com wrote: Is there a port of Python to iPhone? I want to be able to check-out from SVN, edit and run some Python server code now and then. See https://github.com/cobbal/python-for-iphone/blob/master/iOS-build.sh. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Lion
Dan Ross d...@rosspixelworks.com wrote: Anyone have reports of Pythons on Lion? It's Python 2.7.1 pre-installed in /System/Library, but I don't know about PyObjC or Twisted. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
Ronald Oussoren ronaldousso...@mac.com wrote: BTW. I've talked with Ned about this feature at Pycon and we'd like to move to a python-select command that gives you a command-line tool for managing the path to the current python (simular to gcc-select or xcode-select). That way it should be possible to do away with automaticly patching the shell profile. How about a Preference Pane? I could probably remember how to code one up with PyObjC and Python. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
I've got a Snow Leopard buildslave I'm trying to debug. So I thought I'd try Python 2.7 on it. Normally, I advise people to never try to install a different Python on a Mac, as it's too embedded in the OS to do safely, without a great deal of domain knowledge. But here, I figured I could always wipe the disk and start over without too much loss. So I ran the installer, and tried a few things, and it didn't solve my buildbot problems. So I decided to go back to the original System python. But now I find that the installer has put the 2.7 Python on my PATH?!? It does this apparently by hacking ~/.bash_profile. In there, there's a line saying The original version is saved in .bash_profile.pysave a file which doesn't seem to exist. So, why didn't I notice myself checking the checkbox to do this in the first place, and where is my original .bash_profile file? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
Ned Deily n...@acm.org wrote:
In article 64461.1302209...@parc.com, Bill Janssen jans...@parc.com
wrote:
I've got a Snow Leopard buildslave I'm trying to debug. So I thought
I'd try Python 2.7 on it. Normally, I advise people to never try to
install a different Python on a Mac, as it's too embedded in the OS to
do safely, without a great deal of domain knowledge. But here, I
figured I could always wipe the disk and start over without too much
loss.
I don't understand why you would say that.
I think it's gotten immensely better over the years, thanks to the
efforts of folks like you and Ronald. But I still think it tends to
have too many side-effects which surprise and confuse people.
The huge advantage of the
Python framework installation layout on OS X is precisely that it
*doesn't* get embedded into the OS and *does* allow multiple versions of
Python to co-exist on a system far more easily and safely than with the
traditional Python Unix layout. With a very few exceptions, all of the
files installed are under one root
(Library/Frameworks/Python.framework/Versions/m.n/) with some auxiliary
files under another (/Applications/Python m.n) and optionally some
symlinks in /usr/local/bin, with *zero* overlap with any Apple-supplied
files in OS X including the Apple-supplies Pythons. If for some reason
you do want to uninstall a framework build, it's a matter of two 'rm'
commands and optionally removing some obvious symlinks in /usr/local/bin
(which are not needed in the first place). An official uninstall
command would be nice to have and has been requested in the past (see
http://bugs.python.org/issue7107).
Yes, that would be nice.
So, why didn't I notice myself checking the checkbox to do this in the
first place, and where is my original .bash_profile file?
The Python 2.7.1 installer welcome file, the text that is shown in the
first installer screen, says this:
This package will by default update your shell profile to ensure that
this version of Python is on the search path of your shell. Please
deselect the Shell profile updater package on the package
customization screen if you want to avoid this modification.
Double-click Update Shell Profile at any time to make 2.7.1 the default
Python.
So it's a default operation.
(Earlier installers had slightly different wordings.)
The command that does this is in /Applications/Python m.n/Update Shell
Profile.command. Normally, it should have saved your .bash_profile as
~/.bash_profile.pysave, but, even if it didn't, the only modification it
makes to your original .bash_profile is to append these (or similar)
lines to the end of the file:
# Setting PATH for Python 2.7
# The orginal version is saved in .bash_profile.pysave
PATH=/Library/Frameworks/Python.framework/Versions/2.7/bin:${PATH}
export PATH
Hope that helps!
Yes, thanks, very complete explanation. Like I said, I never run this
installer, so lack of familiarity on my part is most of the problem.
Though, I wouldn't have defaulted that path hacking to On. But I
understand the problem with the range of user knowledge you guys are
trying to cope with.
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] why does the Mac installer hack the user's .bash_profile?
Christopher Barker chris.bar...@noaa.gov wrote: I'm a bit confused, Bill. You're just that kind of guy that shouldn't have any problem hacking your .bash_profile! i.e. you are not the target audience for the installer. Right, I usually just build from source with a non-Framework build if I need a different Python on OS X. I just thought I'd try the easy way this one time. Also: I'm pretty sure it's Apple's fault that a de-installer is not a easy and obvious part of a .mpg bundle. I don't think I've ever seen one with a uninstaller, as a matter of fact. The package management on Macs leaves something to be desired, to be sure. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] py2app not including /Library/Python/2.6/site-packages
Michael, I'm not sure what problem you are reporting? But some of those paths on sys.path look suspicious to me: /usr/Extras/lib/python, for instance. Might want to look into how those got on your sys.path. Also, in last week's discussion, we didn't really cover setuptools and easy_install, as they're not Mac-specific. But, after years of fighting with setuptools (easy_install is a part of that), trying to get it to do what I need done, my advice would be to steer clear of using it, as well. It's not clear how it will interact with the other package control systems you mention, such as MacPorts and pypm. Bill michael ferraro mich...@possibleworlds.com wrote: I have seen various posts regarding this problem over the years but I flummoxed by how I got here and what to do now that I am. I am running MacOS X 10.6.6 I started out using the system python 2.6. I built the 3d extensions (PyQt, numpy, PyOpenGL c) and they are installed in /Library/Python/2.6/site-packages As I expected. My app runs fine when invoked directly from the Terminal. Poor internet search results trying to locate and install py2app resulted in the installation of ActiveStates pypm and Macports hg along with some variants of easy_install. These missteps seem to have installed another version of python 2.6 in the path of /Library/Frameworks/Python.framework chain with it own site-packages folder. As a result my installed 3d party extension were no longer found when starting the app from the Terminal. Once I removed this framework. and the .local folder created in my home folder. I also removed the .profile file that was modified (created) by one of the previous installs. I discovered some installed put a python in /usr/local/bin and removed it. I tested my app from the Terminal and all was good again. The sys.path variable prints the expected site-packages. ['/Users/mef/Development/-Applications-/Teatro', '/Library/Python/2.6/site-packages/setuptools-0.6c12dev_r88124-py2.6.egg', '/Library/Python/2.6/site-packages/py2app-0.5.2-py2.6.egg', '/Library/Python/2.6/site-packages/macholib-1.3-py2.6.egg', '/Library/Python/2.6/site-packages/modulegraph-0.8-py2.6.egg', '/Library/Python/2.6/site-packages/altgraph-0.7.0-py2.6.egg', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python26.zip', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-darwin', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plat-mac/lib-scriptpackages', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-tk', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-old', '/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/lib-dynload', '/Library/Python/2.6/site-packages', '/Library/Python/2.6/site-packages/PIL', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/PyObjC', '/System/Library/Frameworks/Python.framework/Versions/2.6/Extras/lib/python/wx-2.8-mac-unicode'] After I run python setup.py py2app I run dist/Teatro.app and the sys.path contents printed to the console looks like this: 1/23/11 1:07:09 PMcom.apple.launchd.peruser.501[420] ([0x0-0xec0ec].org.pythonmac.unspecified.Teatro[25180]) Exited with exit code: 255 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] ['/Users/mef/Development/-Applications-/Teatro', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] '/Users/mef/Development/-Applications-/Teatro/dist/Teatro.app/Contents/Resources', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] '/Users/mef/Development/-Applications-/Teatro/dist/Teatro.app/Contents/Resources', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] '/usr/lib/python26.zip', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] '/usr/lib/python2.6', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] '/usr/lib/python2.6/plat-darwin', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] '/usr/lib/python2.6/plat-mac', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] '/usr/lib/python2.6/plat-mac/lib-scriptpackages', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] '/usr/Extras/lib/python', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233] '/usr/lib/python2.6/lib-tk', 1/23/11 1:07:23 PM[0x0-0xf20f2].org.pythonmac.unspecified.Teatro[25233]
Re: [Pythonmac-SIG] Python development on OSX
Charles Hartman co...@conncoll.edu wrote: it would seem to be short-sighted for anyone interested in Python on the Mac not to support py2app as fully as possible. You calling me short-sighted, Charles? That's OK -- it's true, you know; I've been wearing thick glasses since I was a kid :-). But I don't know that it has much to do with py2app. I think py2app is great, and I believe I even used it, once -- wanted to make a Preference Pane with Python, and couldn't figure out how to do it otherwise. But in general I've not needed it -- I just use Xcode and the system Python, and there's no need to bundle another Python with that approach. I should probably figure out how to use py2app with that approach, though; it might be more bullet-proof. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python development on OSX
Christopher Barker chris.bar...@noaa.gov wrote: and certainly the majority of those who need any help. I think that's key -- Bill's approach is fine one for some users, but not what Id recommend to newbies that aren't sure how to set a PATH. Hmmm. My experience is that those are exactly the folks who get into trouble by using the python.org installer on their macs -- those who don't understand how PATH influences their usage experience. The fact that there are a lot of ways to install Python on the Mac has really been a pain for the community to support (and pretty ironic, considering how the Mac platform usually is!). I'm not sure there is much that can be done about it Yep. By the way, Python is more than just another good scripting language. I build large systems with it. I do (rarely) write Mac applications with Python. I use Xcode and Cocoa-Python, and IMO it works great. Is that using py2app under the covers? This is another reason not to install a non-system Python; it sometimes screws up apps built using Xcode and Python. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python development on OSX
Adam Morris amor...@mistermorris.com wrote: By the way, Python is more than just another good scripting language. I build large systems with it. I do (rarely) write Mac applications with Python. I use Xcode and Cocoa-Python, and IMO it works great. Is that using py2app under the covers? This is another reason not to install a non-system Python; it sometimes screws up apps built using Xcode and Python. I'm trying really hard to unpack this. I tend to build command-line tools and services. But when I need to build something with a Mac UI I pull up Xcode and use the Cocoa-Python template. Works like a charm -- but I believe it depends on the system Python. By the way, if you need to do this, take a look at Hillegass' book, COCOA PROGRAMMING FOR MAC OS X. And read Will Larson's great series, starting with http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/ I can't use XCode and the py-objc bridge with my installed python 2.7 setup? (Installed isn't quite the right word, I know.) Don't know, because I always use the system Python for non-Python-dev coding. But I'm betting there are some dependencies in Xcode or the Xcode templates which require the system Python. Why not? I guess it's because something is hard-coded somewhere ... Sure. But anything hard-coded can be overridden. The sources are just sitting there... I don't particularly need XCode but I really want to understand this. Unless you're developing just for the Mac, I'd suggest using PyGUI or wxPython or PyGTK or some such, and build applications (small 'a') with that, instead of Cocoa. That experience will port out of the Mac to other Unices and Windows. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python development on OSX
Christopher Barker chris.bar...@noaa.gov wrote: On 1/17/11 9:17 AM, Bill Janssen wrote: And- I want to update the default python that came om my macbook pro to 2.7. Should I do install that from Python.org? My advice? I've never had good luck trying to update the default Python that comes with the Mac. Bill -- I'm really curious what issues you've had -- I haven't tried to use Apple's Python is many years (OS-X 10.2, I think) -- and it used to be painful to do so. Since then I've stuck with the Python.org versions, and had no problems (at least none that would have been solved by using Apple's Python). In general, there are issues around site-packages, paths, and other such things. I don't think you and I necessarily have much trouble with it, but I tend to help others with Python on Macs, and they seem to get into all kinds of trouble. The best one I've found is one group who had decided to upgrade their Leopard Python to 2.6. They'd installed the python.org Python, removed the symlink /usr/bin/python, and re-linked /usr/bin/python to the 2.6 version. They were happy, but plagued by odd problems with their machines that didn't (to them) seem to be Python-related. Another problem I've run into more than once was that the user had installed different incompatible versions of an extension, and couldn't see why an application (with an embedded Python interpreter) was misbehaving -- it was getting the wrong version of the extension. Not sure this is much use to anyone, but here's my decision tree, which has worked well for me over the past 7 years: 1) Do I do a bunch of unix-y command line stuff in general, and not want to develop OS-X GUIs? if yes -- use system Python. if no: Do I need/want a newer version than Apple provides? if yes: build non-framework version from source. Do I need/want to use py2app to distribute my app(s)? Never happens. Do I want to use pre-build binaries of common hard-to-build packages? if yes: cry about the general unfairness of the world, then build them from source instead to work with the system Python. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Python development on OSX
Tony Cappellini cappy2...@gmail.com wrote: And- I want to update the default python that came om my macbook pro to 2.7. Should I do install that from Python.org? My advice? I've never had good luck trying to update the default Python that comes with the Mac. I'd recommend just leaving it alone and using it, unless there's some reason you absolutely need 2.7. It is safe to build (and run) a non-Framework build of other versions of Python in various places on your Mac, but life gets complicated if you attempt to install it. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Loading Python on my Mac
Macs come with Python pre-installed. Open a Terminal window and type python at the prompt. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] sad state of OS X Python testing...
Folks, I was looking at the buildbots again. Do you realize that we have no OS X Snow Leopard buildbot? No Intel Leopard buildbot? Well over half of Mac users are using Snow Leopard, and we're not testing on that platform. In fact, the only Intel OS X machine we're testing on is a Core Duo, not a Core 2 Duo, and that's running Tiger. Surely someone could volunteer an old Intel Mac to run some tests? (Actually, two someones -- we'd need separate machines for Leopard and Snow Leopard.) I'd be happy to stick it in a server room at PARC and keep an eye on it. (Right now I've got a rack full of old eMacs and a G5 running PPC buildbots.) Perhaps we could get Apple to contribute some seconds? I believe donations to the PSF are deductible. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] get an OS X buildbot into the stable set
Dan Rabin daniel.e.rabin+re...@gmail.com wrote: Do we need 10.5 and powerpc coverage for python.org purposes, or is latest OS/current machines enough? Right now, I've got as many PPC 10.4 and 10.5 machines as we need. We could use Intel Core 2 Duo (or better) machines running Leopard, and Snow Leopard. Our current Intel OS X buildbot is a Core Duo (so no 64-bit) Mac Mini running Tiger. We also can't make them stable unless this is a kind of long-term 24x7 commitment, so machines already running as servers and unlikely to be decommissioned in the near future would be good. Bill -- Dan Rabin On Tue, Jun 22, 2010 at 11:05 AM, Bill Janssen jans...@parc.com wrote: Shashwat Anand anand.shash...@gmail.com wrote: I have Intel machine (2.53 GhZ, 4gb Ram) with Snow Leopard running on it and the system is 'ON' 24x7 with an average uptime of 1 month. I guess I can use mine to run the buildbots. That sounds great! Just install the buildbot software (see http://wiki.python.org/moin/BuildBot Installing a build slave for instructions), then send a note to Martin for a buildbot name. You can use the system Twisted and system Python to run buildbot. You have to look at the buildbot machine every week or so to see if there are hanging tests you might want to kill manually. I'm not sure why the regression testing software doesn't time out after a day or so, but it doesn't. Use ps auxww | grep regrtest to identify tests. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] get an OS X buildbot into the stable set
Ronald Oussoren ronaldousso...@mac.com wrote: On 21 Jun, 2010, at 21:17, Bill Janssen wrote: I just noticed that the list of stable Python buildbots don't include any OS X buildbots. From the web page, the definition of stable is this: ``The stable versions are the primary platforms that should always have all tests passing.'' Don't we want OS X in that set of platforms? Yes, but as you know we didn't even have OSX buildbots until recently. BTW. I have no idea how a buildbot can be added to the stable set. I guess Dave Bolen and I have taken the first step: set up some OS X buildbots. I'd be happy to maintain an Intel buildbot in the PARC server room if we can scrape up a donation of such a machine. Doesn't have to be new... The next step is to turn those buildbots green. After they're green, we can propose them for addition to the stable set. So, something the Mac SIG could do to help is to take a look at the buildbot output, and figure out why they're red, and not green. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] get an OS X buildbot into the stable set
Shashwat Anand anand.shash...@gmail.com wrote: Tk is a foreign domain for me :( Beside I do participate in roundup, will increase the frequency after I get over with GSoC. I thought may be I can be of help regarding buildbots ( you mentioned something similar in issue 9048) We could use faster modern Mac buildbots. Right now, there are no Intel buildbots running Leopard or Snow Leopard. I'm running a couple of old slow PPC machines as buildbots. It doesn't take much to set up a buildbot. Install XCode, install the buildbot software, talk to Martin v. Loewis to get a buildbot account, and just let it run. You have to look at it periodically to see if there are stuck tests etc. that have to be manually cleared. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] get an OS X buildbot into the stable set
Shashwat Anand anand.shash...@gmail.com wrote: I have Intel machine (2.53 GhZ, 4gb Ram) with Snow Leopard running on it and the system is 'ON' 24x7 with an average uptime of 1 month. I guess I can use mine to run the buildbots. That sounds great! Just install the buildbot software (see http://wiki.python.org/moin/BuildBot Installing a build slave for instructions), then send a note to Martin for a buildbot name. You can use the system Twisted and system Python to run buildbot. You have to look at the buildbot machine every week or so to see if there are hanging tests you might want to kill manually. I'm not sure why the regression testing software doesn't time out after a day or so, but it doesn't. Use ps auxww | grep regrtest to identify tests. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] get an OS X buildbot into the stable set
I just noticed that the list of stable Python buildbots don't include any OS X buildbots. From the web page, the definition of stable is this: ``The stable versions are the primary platforms that should always have all tests passing.'' Don't we want OS X in that set of platforms? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Still Unable to get my Python program working on the mac
An easy way to speak stuff on the Mac from Python is import os os.system(/usr/bin/say 'hello hello hello') Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Still Unable to get my Python program working on the mac
Mike, I looked back at your messages. I find that things work best on the Mac when I don't try to install things that Apple has already installed -- just my experience. Once you start doing that, you've almost got to take a couple of months and understand everything from source. There are also some red flags in your messages. Using a non-Apple version of Python on OS X is one, downloading a new version of PyObjC is a second, using easy_install (for anything) a third. Mixing PyObjC with Wx is a fourth, because it introduces issues about the event loop, but less red, because it is certainly doable. My advice would be to try getting this pyttsx module to work by itself, using the system Python on a vanilla OS X machine, first. Only then make life complicated. Good luck! Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] Still Unable to get my Python program working on the mac
I tried pyttsx on a Mac running 10.5.8: % ls MANIFEST.in README pyttsx setup.cfg PKG-INFOdocspyttsx.egg-info setup.py % python setup.py build Traceback (most recent call last): File setup.py, line 18, in module from ez_setup import use_setuptools ImportError: No module named ez_setup % So I opened up setup.py, and removed the two lines that read: from ez_setup import use_setuptools use_setuptools() Then, python setup.py build, and python setup.py install. Then: % python Python 2.5.1 (r251:54863, Jun 17 2009, 20:37:34) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type help, copyright, credits or license for more information. import pyttsx eng = pyttsx.init() eng.say(hello hello hello) eng.runAndWait() # and hello hello hello comes out of the speakers Seems to work. No additional downloads needed. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] buildbots for OS X: G4 eMacs useful?
Chris Barker chris.bar...@noaa.gov wrote: Bill Janssen wrote: I've got 3 eMacs just sitting around, and thought I'd deploy them as OS X Python buildbots, if they'd be useful. They're 1 GHz G4 machines, with 640 MB of memory, running Tiger If there is a need -- it would be great to keep one on Tiger -- it's a pain to build on leopard and have it work on tiger. Yes, I can keep one or two on Tiger, and upgrade the others to Leopard. I don't think I can put Snow Leopard on G4s, though. My question is, do the machines have enough oomph to build and test on? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
[Pythonmac-SIG] buildbots for OS X: G4 eMacs useful?
I've got 3 eMacs just sitting around, and thought I'd deploy them as OS X Python buildbots, if they'd be useful. They're 1 GHz G4 machines, with 640 MB of memory, running Tiger (I could upgrade to Leopard), 40 GB disks. Can we actually build and test on them? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig unsubscribe: http://mail.python.org/mailman/options/Pythonmac-SIG
Re: [Pythonmac-SIG] py-appscript 0.20.3, 0.21.0 and impending 1.0.0 release (addendum)
has hengist.p...@virgin.net wrote: The bouncing Dock icon is gone when using appscript 0.21.0 on a version of Python that was built against 10.5 or 10.6 SDKs. (Yay!) Yay! Now I can can my private copy of Python with the LSUIElement flag set... Perhaps it's time python.org started distributing framework builds for 10.5 and later? Seems like a good thought. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Py2app PIL recipe
Ronald Oussoren ronaldousso...@mac.com wrote: I don't know, I don't even know which name is the preferred one. The PIL Handbook (http://www.pythonware.com/library/pil/handbook/index.htm) uses 'import Image' throughout. Note that the on-line PIL handbook is from 4.5 years ago. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PIL and Snow Leopard
Jerry LeVan jerry.le...@eku.edu wrote: Is building PIL on Snow Leopard 'easy' I have the apple python (32/64) installed and the python.org 2.6.2 (32 bit) version installed. Yes, I just build it with /usr/bin/python, and it works fine. Assuming you have Xcode 3.2 installed. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard?
You could also use other test I've seen:
def arch():
import ctypes
return {4: i386, 8: x86_64}[ctypes.sizeof(ctypes.c_size_t)]
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools...
Ronald Oussoren ronaldousso...@mac.com wrote: On 17 Sep, 2009, at 23:50, Bill Janssen wrote: Ronald Oussoren ronaldousso...@mac.com wrote: Bill, Appscript probably gets installed as a zipped egg, the .python-eggs directory gets created when a real filesystem path is needed for an item in such an egg. Yes, that's part of the problem. The other part is that .pth handling seems to have changed from 2.5 to 2.6. If you install appscript as an unzipped egg the problem should go away. How does one do that? Either python setup.py bdist_egg and then use the right flags to easy_install; or add 'zip_safe = False' to the arguments of setup() in setup.py install install using python setup.py install. Thanks, Ronald. Hmmm. Neither seems ideal. The first idea involves actually *using* setuptools (easy_install), and the second involves editing the setup.py file. I suppose I could use python setup.py bdist_egg, then use unzip to unpack it in the right place, too. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools...
Ronald Oussoren ronaldousso...@mac.com wrote: Yes, that's part of the problem. The other part is that .pth handling seems to have changed from 2.5 to 2.6. That's news to me. I've been using zipped eggs with 2.6 without any problems. Don't know that it had anything to do with eggs. What I was seeing was different sys.path construction between 2.5 and 2.6, both on SL. In 2.5, it went through and added the directories specified by .pth files in /Library/Python/2.5/site-packages; in 2.6, it didn't. Perhaps I'm just misunderstanding the way the processing of .pth files works. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard?
I'm running /usr/bin/python on SL, and
import platform; print platform.machine()
give me
i386
But Activity Monitor shows Python as Intel (64-bit).
Is this a bug in platform.machine(), or am I misunderstanding what i386
means? platform.architecture() returns ('64bit', '').
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard?
William Kyngesburye wokl...@kyngchaos.com wrote:
If you run the CLI 'uname -m' on any Intel Mac, it always has returned
i386. So all it really means is 'Intel'.
On Sep 18, 2009, at 5:53 PM, Bill Janssen wrote:
I'm running /usr/bin/python on SL, and
import platform; print platform.machine()
give me
i386
But Activity Monitor shows Python as Intel (64-bit).
Is this a bug in platform.machine(), or am I misunderstanding what
i386
means? platform.architecture() returns ('64bit', '').
Hmmm. So what's the pythonic way of getting i386 vs. x86_64?
{'32bit': 'i386', '64bit': 'x86_64'}[platform.architecture()[0]]
seems so complicated that there should be a routine for it in sys or
platform.
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] machine architecture 32/64 with Python 2.6 on Snow Leopard?
I think I'm just going to put '32bit' or '64bit' in my installer name strings.
Bill
e...@apple.com wrote:
On Sep 18, 2009, at 5:05 PM, Bill Janssen wrote:
William Kyngesburye wokl...@kyngchaos.com wrote:
If you run the CLI 'uname -m' on any Intel Mac, it always has
returned
i386. So all it really means is 'Intel'.
On Sep 18, 2009, at 5:53 PM, Bill Janssen wrote:
I'm running /usr/bin/python on SL, and
import platform; print platform.machine()
give me
i386
But Activity Monitor shows Python as Intel (64-bit).
Is this a bug in platform.machine(), or am I misunderstanding what
i386
means? platform.architecture() returns ('64bit', '').
Hmmm. So what's the pythonic way of getting i386 vs. x86_64?
{'32bit': 'i386', '64bit': 'x86_64'}[platform.architecture()[0]]
seems so complicated that there should be a routine for it in sys or
platform.
I don't know the official way, but what I do is:
% python -c 'import sys;print sys.maxint'
9223372036854775807
% env VERSIONER_PYTHON_PREFER_32_BIT=1 python -c 'import sys;print
sys.maxint'
2147483647
So I would look at sys.maxint to determine if python is running 32 or
64-bit.
Ed
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools...
Ronald Oussoren ronaldousso...@mac.com wrote: Bill, Appscript probably gets installed as a zipped egg, the .python-eggs directory gets created when a real filesystem path is needed for an item in such an egg. Yes, that's part of the problem. The other part is that .pth handling seems to have changed from 2.5 to 2.6. If you install appscript as an unzipped egg the problem should go away. How does one do that? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Appscript and Snow Leopard and setuptools...
has hengist.p...@virgin.net wrote: On 13 Sep 2009, at 18:52, Bill Janssen wrote: Is it possible to disentangle appscript from setuptools? I just downloaded the sources to my Snow Leopard machine, did python setup.py build python setup.py install which went just fine. But then I did % python import appscript and got this big stack trace because a ~/.python-eggs subdirectory wasn't accessible. That shouldn't happen, and I'd like to remove any dependence on setuptools and eggs, if possible. You can install appscript from source using plain old distutils; the setup.py script will use setuptools if it's available and distutils if not. Though if there are problems with setuptools then I'd suggest filing bug reports on that as well. I'd like to suggest an option to use distutils even if setuptools is available. Filing bug reports on setuptools seems like a losing proposition; I'd have to understand how it works first. How about *you* file the bug reports there? You're the one using it. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Using Python 2.5 on Snow Leopard
I was happy to see that Python 2.5 still shipped with SL, but now I'm less happy. I can't seem to compile PIL for Python 2.5 on Snow Leopard. The problem is that when I build and install libjpeg or libpng, it builds 64-bit libraries, but Python 2.5 is 32-bit, so the libraries don't work when PIL tries to use them. You get an error message something like this: import _imaging ImportError: dlopen(/Library/Python/2.5/site-packages/PIL/_imaging.so, 2): Symbol not found: _jpeg_resync_to_restart Referenced from: /Library/Python/2.5/site-packages/PIL/_imaging.so Expected in: dynamic lookup Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard
Brad Howes ho...@ll.mit.edu wrote: On Sep 11, 2009, at 1:50 PM, Bill Janssen wrote: I was happy to see that Python 2.5 still shipped with SL, but now I'm less happy. I can't seem to compile PIL for Python 2.5 on Snow Leopard. The problem is that when I build and install libjpeg or libpng, it builds 64-bit libraries, but Python 2.5 is 32-bit, so the libraries don't work when PIL tries to use them. You get an error message something like this: Can you try recompiling with -arch i386 -arch x86_64 options in the CFLAGS? I think I had gotten this to work for some other libraries when I ran into the dreaded linking problem. You might instead need to do CC=gcc -arch... if the configure tool munges the CFLAGS too much. % CFLAGS=-arch i386 -arch x86_64 ./configure ... or % CC=gcc -arch... ./configure ... Brad Thanks, Brad, I've tried this. It does build the .a files multi-platform, but not the dylib files. And some libraries, like libpng, use -M switches which conflict with multiple architecture flags on the compile line. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Using Python 2.5 on Snow Leopard
Yes, 2.6 is there, but I thought I'd try building with 2.5. Now, given the issues with 32/64 bit, I think I'm just going to upgrade the OS X UpLib installation to 64 bits, and just use 2.6. Still haven't got the JPEG support in PIL 1.1.6 working that way, but most of the rest seems to work. Bill Thijs Triemstra | Collab li...@collab.nl wrote: On 11 Sep 2009, at 18:50, Bill Janssen wrote: I was happy to see that Python 2.5 still shipped with SL, but now I'm less happy. I can't seem to compile PIL for Python 2.5 on Snow Leopard. Hm, haven't upgraded to snow leopard yet but i'd expect 2.6 to be in there.. heard they also removed twisted :( Thijs ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Mac OS-X 10.5 and two icons bouncing in the dock problem
I guess the question is, why two dock icons? I'm seeing something perhaps similar; I have a Python-Cocoa app that when started will cause one of those pop-up windows, App quit unexpectedly, do you want to submit a bug report to Apple, and the crash report shows that a multi-threaded program crashed in thread 0 with SEGV attempting to access location 0. But the app seems to be running, just fine. When I poked at it a bit more, it looks like using open or double-click to launch the app somehow causes two instances to start (fork, somewhere?), and one of them is bad. This is with Xcode 3.1.3 and OS X 10.5, but no Qt, no Python-2.6.2. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Mac OS-X 10.5 and two icons bouncing in the dock problem
Anything having to do with Finder or the Dock (or Activity Monitor, for that matter) seems to be somewhat over-simplified and mysterious. Not responding, in Activity Monitor, for instance, seems to be due to an undocumented window server probe of processes marked somehow as applications, for which Python has no built-in support. I find Thread Viewer helpful in looking at programs. But even better is to build your own version of the system Python (2.5.1) with debugging symbols, and use that instead of /usr/bin/python (or, of course, you could use a different version of Python entirely). Then you can point gdb at that running application, and using the Python gdb macros, http://wiki.python.org/moin/DebuggingWithGdb, you can see exactly what's going on in all the threads. I don't use pyinstaller, either. I just build a standard OS X install bundle by hand, and then as I develop just change the contents of of the Resource subdirectory. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] how to recover from a framework build?
Bill Janssen jans...@parc.com wrote: Think I fixed things. I found two problems. First of all, my build wasn't universal, but it appparently overwrote the Python framework SDK in /Developer/. So when Xcode tried to build for both ppc and i386, it only found i386. That was the link error I originally posted. I'll re-install Xcode to see if I can fix that. By the way, this seems to me to be a bug. There are lots more people working on Python-Cocoa applications than people working on MacPython. I can see where this would be convenient for MacPython developers, but it shouldn't happen automagically. Secondly, when I then ran my Python-Cocoa app, it picked up the framework in /Library/Frameworks/Python..., which didn't have objc, so it bombed on that. I just deleted /Library/Frameworks/Python That seemed to fix that. Can anyone explain to me why this happened? Is this a side-effect of overwriting the /Developer version of the library? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] how to recover from a framework build?
Ned Deily n...@acm.org wrote: Sorry, I don't use Xcode for Python development but I'm having a hard time imagining what sequence of events would have caused the SDK to be overwritten. I'm assuming you mean: /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Python.framework Did you try to build Python within Xcode or something? Nope. I unpacked the sources to /tmp, then did a make frameworkinstall, I believe it was. I expected things to wind up in /Library/Frameworks/Python.Framework, which they did. I was surprised to see that the library under /Developer had the same timestamps. Secondly, when I then ran my Python-Cocoa app, it picked up the framework in /Library/Frameworks/Python..., which didn't have objc, so it bombed on that. I just deleted /Library/Frameworks/Python That seemed to fix that. Can anyone explain to me why this happened? Is this a side-effect of overwriting the /Developer version of the library? The normal install path for a frameworks build is /Library/Frameworks/ Python.frameworks/Version/... . And it appears that /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks is a symlink to /Library/Frameworks. Hmmm. OK, that makes it clearer what happened. Here's the link line that Xcode uses (I presume this comes from the Python-Cocoa project template): Ld /p/goodstuff/build/cocoa-gadget.build/Release/goodStuff.build/Objects-normal/ppc/goodStuff normal ppc cd /p/goodstuff setenv MACOSX_DEPLOYMENT_TARGET 10.5 /Developer/usr/bin/gcc-4.0 -arch ppc -isysroot /Developer/SDKs/MacOSX10.5.sdk -L/p/goodstuff/build/Release -F/p/goodstuff/build/Release -filelist /p/goodstuff/build/cocoa-gadget.build/Release/goodStuff.build/Objects-normal/ppc/goodStuff.LinkFileList -mmacosx-version-min=10.5 -framework Cocoa -framework Python -framework WebKit -o /p/goodstuff/build/cocoa-gadget.build/Release/goodStuff.build/Objects-normal/ppc/goodStuff ld warning: in /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks//Python.framework/Python, file is not of required architecture Undefined symbols: _Py_SetProgramName, referenced from: _main in main.o _Py_Initialize, referenced from: _main in main.o _PySys_SetArgv, referenced from: _main in main.o _PyRun_SimpleFileExFlags, referenced from: _main in main.o ld: symbol(s) not found collect2: ld returned 1 exit status Apparently gcc resolved -framework Python to /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks/Python.framework, my new build. But why did it use that in preference to /Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/Python.framework, which also exists? Ah, the ld page says that The default framework search path is /Library/Frameworks then /System/Library/Frameworks. I probably want to add -Z -F/System/Library/Frameworks to the default template. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] how to recover from a framework build?
I made the mistake of trying to build a version of Python with debugging symbols on my Mac. I downloaded the sources to 2.5.4, and did a make frameworkinstall DESTDIR=/tmp. Now my Python-Cocoa apps won't compile in Xcode. They compiled just fine before I did this... Line Location Tool:0: symbol(s) not found Line Location Tool:0: _main in main.o Line Location Tool:0: _PyRun_SimpleFileExFlags, referenced from: Line Location Tool:0: _main in main.o Line Location Tool:0: _PySys_SetArgv, referenced from: Line Location Tool:0: _main in main.o Line Location Tool:0: _Py_Initialize, referenced from: Line Location Tool:0: _main in main.o Line Location Tool:0: _Py_SetProgramName, referenced from: Any ideas? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] how to recover from a framework build?
Think I fixed things. I found two problems. First of all, my build wasn't universal, but it appparently overwrote the Python framework SDK in /Developer/. So when Xcode tried to build for both ppc and i386, it only found i386. That was the link error I originally posted. I'll re-install Xcode to see if I can fix that. Secondly, when I then ran my Python-Cocoa app, it picked up the framework in /Library/Frameworks/Python..., which didn't have objc, so it bombed on that. I just deleted /Library/Frameworks/Python That seemed to fix that. Bill Ned Deily n...@acm.org wrote: In article 6054.1248909...@parc.com, Bill Janssen jans...@parc.com wrote: I made the mistake of trying to build a version of Python with debugging symbols on my Mac. I downloaded the sources to 2.5.4, and did a make frameworkinstall DESTDIR=/tmp. Now my Python-Cocoa apps won't compile in Xcode. They compiled just fine before I did this... Line Location Tool:0: symbol(s) not found Line Location Tool:0: _main in main.o Line Location Tool:0: _PyRun_SimpleFileExFlags, referenced from: Line Location Tool:0: _main in main.o Line Location Tool:0: _PySys_SetArgv, referenced from: Line Location Tool:0: _main in main.o Line Location Tool:0: _Py_Initialize, referenced from: Line Location Tool:0: _main in main.o Line Location Tool:0: _Py_SetProgramName, referenced from: Any ideas? Long shot (Xcode 3.1.3): in the project's Groups Files list, select the Python.framework and do a Get Info on it to ensure that the path is set to /System/Library/... . -- Ned Deily, n...@acm.org ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Python program done, now need to Change Rocketship Icon, Remove Python menu?
Python Nutter pythonnut...@gmail.com wrote: 1. I wish to override the Rocketship icon and display an icon representing my Application. Put your icon in the Info.plist file of your application: keyCFBundleIconFile/key stringYourLogo.icns/string You can use /Developer/Applications/Utilities/Icon Composer to build the icons file. 3. I don't suppose there is an easy way to make an application folder in the Mac OS X Application folder representing my python program with the same Icon that would appear on the Dock when the user launches my program? I don't see any easy references to the folder structure for Python programmers to deploy on the OS X platform. Is there any good resources out there that will teach how to do this? Again, just set the icon bundle in the Info.plist. There are lots of different ways to do this. Kevin's advice to just use py2app may be a good idea. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Installing Pygame
My two cents: Don't try to install a new Python on OS X. Just use /usr/bin/python. artha...@sbcglobal.net wrote: I am using a Mac PPC with Tiger 10.4.11 and I recently downloaded and installed Python 2.6.2. and I am having difficulties getting started. What are you trying to do, learn Python? If so, don't mess around with games or any other package that requires you to use lots of extra packages that don't come with the standard Python. The Python that comes with Tiger is 2.3.5, a bit out of date but very stable and a good starting point. Work through the Python tutorial at http://www.python.org/doc/2.3.5/tut/tut.html. I purchased Python Programming, 2nd Ed. for the absolute beginner by Michael Dawson because he uses games to teach programming and the book got great reviews at Amazon.com. Well, games are great, once you know what you're doing. One step at a time. I don't see any pygame downloads for 10.4, so I wouldn't try to use it till I had some understanding of how to build it from scratch. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building a debug framework build of Python
Thanks, Ronald. It looks to me as if MacPython already includes the -g flags appropriately (at least build-script.py does); could I just download 2.5.4 from python.org and use that for debugging? Bill Ronald Oussoren ronaldousso...@mac.com wrote: Apple has the sources of the open-source components of OSX on their website, the python bits for 10.5.7 are here: http://www.opensource.apple.com/source/python/python-30.1.3/ . I haven't checked if this includes the configure invocation, although you could always use distutils to query the value of 'CONFIG_ARGS' . Ronald On 2 Jun, 2009, at 2:14, Bill Janssen wrote: I'd like to be able to connect to my Python programs, mainly long-running servers, and see what's going on in specific threads. To do that, I need a version of Python that's compiled with debug symbols in it. What's the correct invocation to build a debug version of Python (2.5) which matches what ships with OS X 10.5.7? I don't intend to replace the system Python; I just want to match it as closely as possible for debugging. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building a debug framework build of Python
Actually, I'm debugging Python code, but it's running in a multi-threaded Python server. So I need to attach with gdb to see what's going on. It would be nice if Thread Viewer had the ability to decode Python stack traces. Thanks for the info. I'll try building using the Apple sources. Bill Ronald Oussoren ronaldousso...@mac.com wrote: On 2 Jun, 2009, at 17:26, Bill Janssen wrote: Thanks, Ronald. It looks to me as if MacPython already includes the -g flags appropriately (at least build-script.py does); could I just download 2.5.4 from python.org and use that for debugging? Not necessarily. Apple's version of python includes a number of patches, some of which will affect the debug symbols (such as some support for dtrace). What I tend to do when I need to debug C code is to develop using the python.org installer which, as you mentioned, contains debugging symbols. The resulting C code should then work fine with the Apple installation of python. For really annoying bugs I have yet another seperate installation that was compiled using --with-pydebug, this tends to be the most helpful when dealing with refcounting bugs in C extensions. Ronald Bill Ronald Oussoren ronaldousso...@mac.com wrote: Apple has the sources of the open-source components of OSX on their website, the python bits for 10.5.7 are here: http://www.opensource.apple.com/source/python/python-30.1.3/ . I haven't checked if this includes the configure invocation, although you could always use distutils to query the value of 'CONFIG_ARGS' . Ronald On 2 Jun, 2009, at 2:14, Bill Janssen wrote: I'd like to be able to connect to my Python programs, mainly long-running servers, and see what's going on in specific threads. To do that, I need a version of Python that's compiled with debug symbols in it. What's the correct invocation to build a debug version of Python (2.5) which matches what ships with OS X 10.5.7? I don't intend to replace the system Python; I just want to match it as closely as possible for debugging. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building a debug framework build of Python
Yes, I do use the threading module, but it's not quite that simple. Some of my threads are actually running Java code, for PyLucene. This is part of UpLib, at http://uplib.parc.com/. Thanks for the pointers. Is there a home site for rpdb2? Or is it just part of winpdb? The nice thing about gdb is that it doesn't need to be on top; you can attach to a server you started without any magic invocation. UpLib has a complicated startup dance, and it's hard to start it with the kind of invocation needed for debuggers like rpdb2. Bill THREADING = None HAVE_PYLUCENE = None if @USE_PYLUCENE@ == jcc: # make sure the JVM DLL is on our path, a side-effect of finding the JAVAHOME find_JAVAHOME() HAVE_PYLUCENE = jcc THREADING = python class JavaCapableThread(threading.Thread): def run(self): if uthread.JAVA_ENV: uthread.JAVA_ENV.attachCurrentThread(self.getName(), self.isDaemon()) super(JavaCapableThread, self).run() if uthread.JAVA_ENV: uthread.JAVA_ENV.detachCurrentThread() class uthread: conf = configurator.default_configurator() maxheap = conf.get(java-max-heap, 512m) maxstack = conf.get(java-max-stack, 100m) vmargs = conf.get(java-vm-args, -Djava.awt.headless=true) def initialize(cls): import lucene cls.JAVA_ENV = lucene.getVMEnv() or lucene.initVM(classpath=lucene.CLASSPATH, vmargs=cls.vmargs, initialheap=64m, maxheap=cls.maxheap, maxstack=cls.maxstack) # make sure we can call in on the main thread cls.JAVA_ENV.attachCurrentThread(threading.currentThread().getName(), threading.currentThread().isDaemon()) initialize=classmethod(initialize) def get_ident(): return repr(threading.currentThread()) get_ident = staticmethod(get_ident) def create_new_thread(name, fn, args): t = JavaCapableThread(None, fn, name, args) note(0, creating new thread %s, t) t.setDaemon(true) return t create_new_thread=staticmethod(create_new_thread) def start_new_thread(fn, args, name=None): t = JavaCapableThread(None, fn, name, args) note(0, starting new thread %s, t) t.setDaemon(true) t.start() return t start_new_thread = staticmethod(start_new_thread) def allocate_lock(): return threading.RLock() allocate_lock = staticmethod(allocate_lock) if (not HAVE_PYLUCENE): THREADING = python class uthread: def initialize(cls): pass initialize=classmethod(initialize) def get_ident(): return repr(threading.currentThread()) get_ident = staticmethod(get_ident) def create_new_thread(name, fn, args): t = threading.Thread(None, fn, name, args) t.setDaemon(true) note(0, creating new thread %s, t) return t create_new_thread=staticmethod(create_new_thread) def start_new_thread(fn, args, name=None): t = threading.Thread(None, fn, name, args) t.setDaemon(true) note(0, starting new thread %s, t) t.start() return t start_new_thread = staticmethod(start_new_thread) def allocate_lock(): return threading.RLock() allocate_lock = staticmethod(allocate_lock) Leonardo Santagada santag...@gmail.com wrote: On Jun 2, 2009, at 1:18 PM, Bill Janssen wrote: Actually, I'm debugging Python code, but it's running in a multi-threaded Python server. So I need to attach with gdb to see what's going on. It would be nice if Thread Viewer had the ability to decode Python stack traces. Thanks for the info. I'll try building using the Apple sources. Is the server a multi-threaded python program, using thread or Threading? Then I think you could use rpdb2 or winpdb to debug it. -- Leonardo Santagada santagada at gmail.com ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] question about garbage collection with NSApplication.run()
Thanks, Ronald. Bill Ronald Oussoren ronaldousso...@mac.com wrote: On 31 May, 2009, at 20:34, Bill Janssen wrote: I'm writing a Python program that has a main that looks like this: application = NSApplication.sharedApplication() # set up handler for network change notification SCDynamicStoreSetNotificationKeys(DYNSTORE, None, [NETWORK_KEY,]) # Get a CFRunLoopSource for our store session and add it to the application's runloop: CFRunLoopAddSource( NSRunLoop.currentRunLoop().getCFRunLoop(), SCDynamicStoreCreateRunLoopSource(None, DYNSTORE, 0), kCFRunLoopCommonModes ) # add a timer for application scan events timer = NSTimer .scheduledTimerWithTimeInterval_target_selector_userInfo_repeats_( periodicity, scanner, objc.selector(scanner.scan, signature=v@:), None, True) # using an NSRunLoop avoids Activity Monitor complaining about not responding application.run() Do I need to do anything about NSAutoreleasePools? My understanding is that this is single-threaded, and that NSApplication.run will handle periodic drainage of the default main thread release pool. That's right. NSApplication.run manages the the pool for you. You only have to worry about autorelease pools when you create new threads running Cocoa code, and when you a long time without looping through the eventloop. Ronald ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Building a debug framework build of Python
I'd like to be able to connect to my Python programs, mainly long-running servers, and see what's going on in specific threads. To do that, I need a version of Python that's compiled with debug symbols in it. What's the correct invocation to build a debug version of Python (2.5) which matches what ships with OS X 10.5.7? I don't intend to replace the system Python; I just want to match it as closely as possible for debugging. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] crankd for monitoring OS X
I ran across this project yesterday, and thought I'd point it out to others: http://code.google.com/p/pymacadmin/ A collection of Python utilities for Mac OS X system administration. In particular, check out crankd, a Python program for monitoring various kinds of OS X events. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] question about garbage collection with NSApplication.run()
I'm writing a Python program that has a main that looks like this: application = NSApplication.sharedApplication() # set up handler for network change notification SCDynamicStoreSetNotificationKeys(DYNSTORE, None, [NETWORK_KEY,]) # Get a CFRunLoopSource for our store session and add it to the application's runloop: CFRunLoopAddSource( NSRunLoop.currentRunLoop().getCFRunLoop(), SCDynamicStoreCreateRunLoopSource(None, DYNSTORE, 0), kCFRunLoopCommonModes ) # add a timer for application scan events timer = NSTimer.scheduledTimerWithTimeInterval_target_selector_userInfo_repeats_( periodicity, scanner, objc.selector(scanner.scan, signature=v@:), None, True) # using an NSRunLoop avoids Activity Monitor complaining about not responding application.run() Do I need to do anything about NSAutoreleasePools? My understanding is that this is single-threaded, and that NSApplication.run will handle periodic drainage of the default main thread release pool. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
Ronald Oussoren ronaldousso...@mac.com wrote: On 14 May, 2009, at 4:31, Bill Janssen wrote: I think this depends on what you think the native Mac GUI is, and what you want to do with it. For instance, a non-framework build, combined with Xlib (http://python-xlib.sourceforge.net/) works quite well with the Apple X11 server, which in turn uses the native Mac GUI. This is totally off-topic, but I don't think an X11 based UI is a native Mac GUI. Anything that's a native GUI should at least conform to the usual UI conventions of OSX, such as a per-application menu instead of per windows menu's. And to be honest, I even have doubts about a toolkit such as Tk which uses native widgets but has a rather un-mac feeling unless the developer really knows what he's doing. That explains why IDLE looks ugly on OSX, I don't know what I'm doing w.r.t. Tk on OSX, and AFAIK Python's stdlib doesn't even ship with all components that are needed to get a proper native LF with Tkinter. Yes, I agree with all that -- anything non-Cocoa isn't real. I was just wondering what the OP meant by native Mac GUI. Though we could have lots of fun arguing about whether the X11 server provides access to the native Mac GUI... :-). Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
Christopher Barker chris.bar...@noaa.gov wrote: could build your own app using PyObjC to access the Cocoa GUI, using Python without a Python app bundle. Can you? Isn't a PyObjC app using the Python executable as the main app, just like any other python program? Yes, using the Python executable. But if you start with Xcode, and create a Python-Cocoa application, what you get is a separate app that's composed of a shim layer in Objective-C which starts up an embedded Python interpreter and runs main.py in that interpreter. That's what I was talking about. You could write a ObjC app, and embed python, if that's what you mean, but that's harder, too. Not when Xcode does it for you. The two things are logically separate, aren't they? You can have a framework build of Python without having a Python application bundle. yes, they are, but I think if you do a standard unix build, you don't get the application bundle That's right. I suspect that the default build of PyObjC assumes that Python is a framework build, too. I'm not sure it's relevant, but it won't work without out it. I'm no PyObjC expert, but, for instance, you can run wxPython with the non-bundle python, it just won't work (the point being that there is no difference in wxPython itself). That's why there used to be two pythons: python and pythonw, pythonw being required for GUI access. At the very least, you'd probably have to re-build wxPython against the non-framework Python, which seems like a lot of work. Bill Janssen wrote: I think this depends on what you think the native Mac GUI is, and what you want to do with it. For instance, a non-framework build, combined with Xlib (http://python-xlib.sourceforge.net/) works quite well with the Apple X11 server, which in turn uses the native Mac GUI. That's because it's the X11 server that is accessing the native Mac GUI, not your app directly. But I don't think anyone is thinking X when they say native Mac GUI -- in fact, I think the entire point of using the term native is to distinguish between X and Carbon/Cocoa. Even Carbon's not native, IMO! But X does draw on its windows using Carbon -- it's just at arm's reach :-). Ronald Oussoren wrote: And to be honest, I even have doubts about a toolkit such as Tk which uses native widgets but has a rather un-mac feeling I don't think TK does use native widgets -- it certainly didn't used to. It was originally built for X11, and got ported to other platforms by emulating the X11 drawing calls, still drawing its own widgets. I know they've added support for native standard dialogs, like the file dialog, but I think a great deal is still self drawn. The Tk canvas has alway seemed to me a nice appropriation of Joel Bartlett's most excellent ezd system (http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-91-6.html). But it's really 80's technology, so far as GUI toolkits go. Bill Janssen wrote: Yes, I agree with all that -- anything non-Cocoa isn't real. I think Carbon is still real -- though it is on its way out... We could have a holy war about that :-). Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
The Mac comes with a Framework build of Python pre-installed (and with PyObjC pre-installed, which you also need). Just use /usr/bin/python, and you'll be fine. It's the default way that Python builds on a Mac, too. Bill Brian Granger ellisonbg@gmail.com wrote: Hi, I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? If so, is this requirement documented somewhere? Thanks! Brian ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
Christopher Barker chris.bar...@noaa.gov wrote: Brian Granger ellisonbg@gmail.com wrote: I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? Pretty much -- to access the Mac GUI, an app needs to be in a proper Mac application bundle. But there's no pressing reason Python has to supply that bundle. You could build your own app using PyObjC to access the Cocoa GUI, using Python without a Python app bundle. The two things are logically separate, aren't they? You can have a framework build of Python without having a Python application bundle. I suspect that the default build of PyObjC assumes that Python is a framework build, too. But I don't know if you could build a non-framework Python and non-framework PyObjC, and use those together to write Python programs that could access Cocoa. I suspect you could, but I also suspect it would be a lot of work. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Why is Framework build of Python needed
I think this depends on what you think the native Mac GUI is, and what you want to do with it. For instance, a non-framework build, combined with Xlib (http://python-xlib.sourceforge.net/) works quite well with the Apple X11 server, which in turn uses the native Mac GUI. Bill Brian Granger ellisonbg@gmail.com wrote: Hi, I seem to recall that a Framework build of Python is needed if you want to do anything with the native Mac GUI. Is my understanding correct? If so, is this requirement documented somewhere? Thanks! Brian ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Leaning PyObjC
Kevin Walzer k...@codebykevin.com wrote: My strong preference is to keep my Python toolchain reasonably close to what I'm doing already, i.e. doing my development outside of Xcode and using py2app for bundling, rather than using Xcode. I found crossing this bridge a bit tricky, until I embraced Xcode. Start a Python-Cocoa project with Xcode. Look at the framework it builds for you. Go on and edit your app delegate, not necessarily using Xcode. Hit the Build and Run button in Xcode. See what happens. Repeat. After you've successfully built a couple of Python apps this way, you'll be better prepared to get into the whole py2app thing. The major problem there is that the folks who build and maintain it are overworked, and have little to no time to update documentation. So there are lots of out-of-date documentation pages and examples, which will mislead you mightily unless you have some other grounding to fall back on to see if they make sense. Even then, I have to admit I still don't know how to build a PreferencePane from scratch. I've got one working, but I had to take the example, and hack it into shape. Oh, and read Will Larson's series: http://lethain.com/entry/2008/aug/22/an-epic-introduction-to-pyobjc-and-cocoa/ all the way through. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building a PreferencePane with PyObjC?
Ronald Oussoren ronaldousso...@mac.com wrote: If you don't add the IBAction decorator Interface Builder won't show your action methods as actions when you ctrl-drag a connection to an instance of your class. Thanks, Ronald. So this is part of what IB looks for when you tell it to scan the class files. I've been adding the actions myself manually to the class in IB, before ctrl-dragging the connection, which is another way of doing it but laborious. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building a PreferencePane with PyObjC?
Ronald Oussoren ronaldousso...@mac.com wrote: The example that's in the repository is fully up-to-date, although it doesn't use Interface Builder. Good to know. I'd downloaded a version of the example from somewhere, which seems a bit antique compared to what's in http://svn.red-bean.com/pyobjc/trunk/ (I presume that's the repository?). But the repo code still has things like marking actions with @objc.IBAction, which I haven't found necessary in my code. Is that still necessary? The easiest way to develop preference panes for now is to have a dummy xcode project to get the nibfile integration in interface builder (that is, when you add python files to an xcode project IB automaticly knows about those files). Then use py2app to actually build the preference pane. OK, that seems straightforward. Do I have to run FileReload All Class Files to get IB to know about the specifics of the class? And, how do I build an appropriate setup.py file to run py2app on? Where is that documented? Py2app in subversion already can compile .xib files when building a bundle, unless you use the '-A' flag. In that case you're better of to instruct Interface builder to save your IB documents as '.nib' files. My problem is connecting things up in IB in the first place, which is why I was talking about a step-by-step example. Suppose I use XCode to build a stub PrefPane project called test. I remove the testPref.h and testPref.m files it provides, and add my own testPref.py file, using the Python class which inherits from NSObject template. I make sure that testPref.py is in the Classes part of the Xcode project. I edit testPref.py to have the class testPref inherit from NSPreferencePane instead of NSObject. I then double-click on testPref.xib to bring up IB. That's where I get lost. What specific actions do I need to do to connect the preference pane to that new class file? Here's what I think is right: 1. In IB, use File Reload All Class Files. 2. Select File's Owner, and set its Class type to testPref. 3. Build the UI of the PP and connect it up to outlets and actions on the File's Owner class. 4. Save everything in IB. 5. Run py2app to build the pane. BTW, AFAIK there are no Xcode templates for building plugin bundles in Python and I have no intention to create those because I don't like Xcode for Python development. Yeah, I use Emacs myself, but it's handy to generate that stub project you recommend. Bill Ronald On 17 Apr, 2009, at 19:56, Bill Janssen wrote: Hi, all. I'm trying to build a PreferencePane with Python and Interface Builder, and the examples I can find on the Web seem somewhat out-of-date. In particular, the EnvironmentPane example seems to use a magic NIB, which I can't figure out how to construct from scratch, and which I can't seem to convert to XIB format. If someone could outline the steps of what needs to happen to build a new PreferencePane XIB file from scratch, using IB, I'd be grateful. Or if you've got a pointer to an up-to-date Xcode 3 example, that would be useful, too. Thanks! Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building a PreferencePane with PyObjC?
Bill Janssen jans...@parc.com wrote: Ronald Oussoren ronaldousso...@mac.com wrote: The example that's in the repository is fully up-to-date, although it doesn't use Interface Builder. Good to know. I'd downloaded a version of the example from somewhere, which seems a bit antique compared to what's in http://svn.red-bean.com/pyobjc/trunk/ (I presume that's the repository?). But the repo code still has things like marking actions with @objc.IBAction, which I haven't found necessary in my code. Is that still necessary? The easiest way to develop preference panes for now is to have a dummy xcode project to get the nibfile integration in interface builder (that is, when you add python files to an xcode project IB automaticly knows about those files). Then use py2app to actually build the preference pane. OK, that seems straightforward. Do I have to run FileReload All Class Files to get IB to know about the specifics of the class? And, how do I build an appropriate setup.py file to run py2app on? Where is that documented? Py2app in subversion already can compile .xib files when building a bundle, unless you use the '-A' flag. In that case you're better of to instruct Interface builder to save your IB documents as '.nib' files. My problem is connecting things up in IB in the first place, which is why I was talking about a step-by-step example. Suppose I use XCode to build a stub PrefPane project called test. I remove the testPref.h and testPref.m files it provides, and add my own testPref.py file, using the Python class which inherits from NSObject template. I make sure that testPref.py is in the Classes part of the Xcode project. I edit testPref.py to have the class testPref inherit from NSPreferencePane instead of NSObject. I then double-click on testPref.xib to bring up IB. That's where I get lost. What specific actions do I need to do to connect the preference pane to that new class file? Here's what I think is right: 1. In IB, use File Reload All Class Files. 2. Select File's Owner, and set its Class type to testPref. 3. Build the UI of the PP and connect it up to outlets and actions on the File's Owner class. 4. Save everything in IB. 5. Run py2app to build the pane. BTW, AFAIK there are no Xcode templates for building plugin bundles in Python and I have no intention to create those because I don't like Xcode for Python development. Yeah, I use Emacs myself, but it's handy to generate that stub project you recommend. Bill Ronald On 17 Apr, 2009, at 19:56, Bill Janssen wrote: Hi, all. I'm trying to build a PreferencePane with Python and Interface Builder, and the examples I can find on the Web seem somewhat out-of-date. In particular, the EnvironmentPane example seems to use a magic NIB, which I can't figure out how to construct from scratch, and which I can't seem to convert to XIB format. If someone could outline the steps of what needs to happen to build a new PreferencePane XIB file from scratch, using IB, I'd be grateful. Or if you've got a pointer to an up-to-date Xcode 3 example, that would be useful, too. Thanks! Bill Yeah, I still can't get this to work. When I try to load the prefPane, I get the following error message on the console: *** -[NSCFArray insertObject:atIndex:]: attempt to insert nil I think I'm missing something in the NIB. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Building a PreferencePane with PyObjC?
Ronald Oussoren ronaldousso...@mac.com wrote: On 19 Apr, 2009, at 21:01, Bill Janssen wrote: Ronald Oussoren ronaldousso...@mac.com wrote: The example that's in the repository is fully up-to-date, although it doesn't use Interface Builder. Good to know. I'd downloaded a version of the example from somewhere, which seems a bit antique compared to what's in http://svn.red-bean.com/pyobjc/trunk/ (I presume that's the repository?). But the repo code still has things like marking actions with @objc.IBAction, which I haven't found necessary in my code. Is that still necessary? That isn't still necessary, it is necessary for the Python support in Interface Builder to work correctly. That's the purely functional reason for adding that decorator, although it also helps in documenting why the method is there. work properly? So, what breaks if it's omitted? As I say, I've written functioning Cocoa-Python code that doesn't use @objc.IBAction, but the actions seem to get called correctly. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Building a PreferencePane with PyObjC?
Hi, all. I'm trying to build a PreferencePane with Python and Interface Builder, and the examples I can find on the Web seem somewhat out-of-date. In particular, the EnvironmentPane example seems to use a magic NIB, which I can't figure out how to construct from scratch, and which I can't seem to convert to XIB format. If someone could outline the steps of what needs to happen to build a new PreferencePane XIB file from scratch, using IB, I'd be grateful. Or if you've got a pointer to an up-to-date Xcode 3 example, that would be useful, too. Thanks! Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Using Python with Emacs
Gregg Lobdell gmlobd...@seanet.com wrote: I can get it to start python 3.0 if, in python.el, I set python- python-command to /Library/Frameworks/Python.framework/Versions/3.0/ bin/python. But this seems like a kludge, to have to set the full path. There must be a better way. This is really a python-list question. But I set py-python-command in my .emacs file. And the full path is indeed the way to go. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] urllib2.urlopen fails in a forked daemon with a CoreFoundation error
Jarkko Laiho jarkko.la...@iki.fi wrote: So ultimately the question is: how should the forking code in the recipe be modified, so that it satisfies the requirements of OS X? What does an actual, concrete exec() call look like in this case, and at what point in the code should it occur? I don't know -- you didn't post your entire program. Read the Wikipedia page and follow the refs. Here's an example: def daemon (): try: pid = os.fork() if pid 0: sys.exit(0) # parent except OSError, e: msg = fork #1 failed: (%d) %s\n % (e.errno, e.strerror) sys.stderr.write(msg) sys.exit(1) os.umask(0) # now create a new session os.setsid() # and fork into the new session try: pid = os.fork() if pid 0: sys.exit(0) # session leader exits here except OSError, e: msg = fork #2 failed: (%d) %s\n % (e.errno, e.strerror) sys.stderr.write(msg) sys.exit(1) # here you could make any changes you need to the env, like setting PYTHONPATH env = os.environ.copy() # figure out how to invoke the actual program args = [sys.executable, -c, import mycode; + mycode.realmain() ] os.execve(sys.executable, args, env) def realmain(): start_server() # the real main... # this is basically just an event-handling loop while True: try: asyncore.loop() except (KeyboardInterrupt, SystemExit), x: note(4, Exited from main loop due to exception:\n%s, ''.join(traceback.format_exception(*sys.exc_info( raise except: note(0, Exited from main loop due to exception:\n%s, ''.join(traceback.format_exception(*sys.exc_info( if __name__ == __main__ and (not sys.platform.lower().startswith(win)): daemon() ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] urllib2.urlopen fails in a forked daemon with a CoreFoundation error
You need to do an exec after doing a fork. /usr/bin/python on OS X is a framework build, and some (most?) of the OS X frameworks just don't work after doing a fork. You have to restart with an exec. It's hard to say just what is using CF; I see you're importing some external packages (json doesn't come with 2.5.1 on OS X), so it might be one of them, instead of urllib2. But it's probably the urllib module, which uses CF to call into the SystemConfiguration system on the Mac to look up proxies and such. It would make sense that the error is triggered just when you call urlopen(). Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript path issue
Jack Jansen jack.jan...@cwi.nl wrote:
I wouldn't be surprised if the root of the problem is with
PowerPoint. It started its life as an OS9 application, so if it still
thinks it lives in an OS9 world with FSSpecs and colon-separated
pathnames, it could be trying to do the conversion to posix paths
itself.
No, it continues to deal with HFS paths. What I'm getting from it
is janssen:Documents as the directory for the presentation.
Which implies a disk called janssen, and a top-level directory called
Documents, which is pretty much what's there.
And osascript processes it correctly, so...
Bill
So, I thought I'd use FileManager to deal with this, by enumerating the
volumes and their names. Here's the program I wrote:
#include CoreServices/CoreServices.h
int main(int ac, char **av)
{
/* compile this with: cc -o test -framework CoreServices test.c */
OSErr err = 0;
FSVolumeRefNum actualVolume;
FSVolumeInfoBitmap whichInfo;
FSVolumeInfo info;
HFSUniStr255 volumeName;
FSRef rootDirectory;
int i;
for (i = 1; err != nsvErr; i++) {
volumeName.length = 0;
err = FSGetVolumeInfo (kFSInvalidVolumeRefNum,
i,
actualVolume,
kFSVolInfoGettableInfo,
info,
volumeName,
rootDirectory);
if (err = 0) {
char buf[512];
CFStringRef strRef = CFStringCreateWithCharacters(NULL, // use
default allocator
volumeName.unicode,
volumeName.length);
CFStringGetCString(strRef, buf, sizeof(buf),
kCFStringEncodingNonLossyASCII);
printf(%d: %s\n, actualVolume, buf);
} else if (err != nsvErr) {
printf(err %d accessing volume %d\n, err, i);
}
}
}
When I run it on my machine, with about 15 NFS-mounted volues on it
(according to the mount command), it only shows the two actual hard
disks on the machine! The FileManager reference is pretty unclear about
this; it says only physical volumes, but discusses AFP and NFS volumes
in talking about FSGetVolumeInfo.
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript path issue
has hengist.p...@virgin.net wrote: Bill Janssen wrote: I'm trying to write this scrap of Applescript in Python appscript: on run tell application Microsoft PowerPoint set this_item to path of active presentation end tell set unix_item to POSIX path of this_item display dialog of unix_item end run which yields /tilde/janssen/Documents, an NFS-mounted location. Is that correct? Shouldn't the volume appear under /Volumes? Is the volume identified by this path mounted at the time you run this code? If not, try it and see what happens. Yes, it's correct, and yes, the volume is mounted -- the code is running out of it, in fact. It's my home directory. The automounter mounts these NFS shares automatically under /tilde if they come from the mount.byname YP map. They don't show up under /Volumes at all. Appscript uses CFURL functions to convert POSIX to HFS paths and vice- versa. (I'd have thought AS would use the same functions, but maybe not.) The relevant code is in the ae.c file for your reference. Yes, I found it. I've been playing around with that code using Carbon.File... I was kind of hoping that this would do it Carbon.File.FSMakeFSSpec(0, 0, janssen:Documents).FSpMakeFSRef().as_pathname() but not so -- maybe that's the same bug that shows up in CFURLCreateWithFilesystemPath. I think what one has to do is to enumerate the volumes, identify the one labelled as janssen, and then use that volume ID as the parent to Carbon.File.FSMakeFSSpec(volumeID, 0, Documents).FSpMakeFSRef().as_pathname() (I think enumeration is necessary -- at least, I don't see any call that says, give me the volumeID of the volume known as 'janssen'.) If you find a problem in the way that HFS-POSIX paths are converted, I'd suggest writing up a test case in C to confirm the same behaviour there, then submit a bug report to Apple on it as its their APIs that are responsible for it. Sure. But I'm guessing that they don't actually use CFURLCreateWithFilesystemPath... And until the bug is fixed, I'd like to find a workaround for appscript to use. Sure like to know how POSIX path of does it... Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: Can you reproduce the issue in the second problem with a simple script? If so, please file a bug in the python bugtracker and assign it to me. If I could, I'd be halfway to fixing it -- but thanks! The dock icon should mean you're calling an API that requires access to the window server. Does the daemon program work when you start it without begin logged on to the console (that is, log in using an SSH session without being logged on on the console)? If that doesn't work, it shouldn't work either with and without the LSUIElement key. Right. But it also means that there are more things than appscript which can cause this. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: LSUIElement=1 completely surpresses the dock icon and menu bar for an application, although you can get those back by calling an API. This would be a support nightmare for python.app, any (OSX) newby that runs a Tkinter script from a tutorial ends up with a non-functional application. Whether we need to also upgrade the tutorials strikes me as a minor matter. Furthermore cross-platform scripts would have to call the upgrade-API to ensure they have a menu, making OSX different from Linux and Windows. No, as you then point out... Both could be worked around by including a call to the upgrade-API in the startup code for GUI toolkits (Tkinter, WxWidget, QT, ...), but that would mean you can no longer create agent applications using those toolkits. Yeah, we'd want to a call in the toolkit to make to enable that, which modifies the level that the automatic upgrade upgrades to. An agent application is supposed to be a mostly faceless background application that can pop-up a window when it needs to. I guess Growl would be a good example of such functionality, although I haven't checked if they use the LSUIElement key. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: Whether we need to also upgrade the tutorials strikes me as a minor matter. You'd have to modify every tutorial out there, including books. That's not really feaseable. Python changes. Tutorials need to keep changing. The right ways to fix the issue you're running into with appscript are 1) Wrap your script into an .app bundle that includes the LSUIElement setting (because appeartly you are writing an application that is an agent-style application) 2) Research why appscript causes the icon to appear on the dock. As has noted it should be possible to avoid that because the ScriptingBridge framework doesn't have this problem. The second option would be the most useful for the community, but is way harder than the first option. Yes, both of those are good ideas. But it's not just appscript; I'm doing something else in a different program (that doesn't use appscript) that also causes the rocket-in-the-dock problem. This one is particularly irritating, because it's a real daemon, and can't always get through to the dock. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Henning Hraban Ramm hra...@fiee.net wrote: But I wouldn't like to loose some GUI functionality. I'm sure that's true. But I think the change I'm proposing needn't cause any negative effects. I've lost the ability to log out, and would like that back! Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: if I understand the LSUIElement document correctly the setting you propose would make it impossible to use python sometkscript.py to run a simple GUI script. Then you misunderstand either LSUIElement, or the discussion so far. What we'd like to do is to retain that capability. Please read the Apple document I referenced earlier to get an idea of what the three different classes of application are. In any case, you can always promote an app to a heavier-weight presence; what Apple doesn't give us an interface for is to demote the app if it's been promoted by accident. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: On 2 Feb, 2009, at 21:53, Bill Janssen wrote: In any case, it does include a info.plist, and it may include a different launch stub, so setting LSUIElement = 1 may work in either case. Sounds reasonable, then. Set LSUIElement=1 in the Python.app Info.plist, and other apps that use python can set it differently if they wish. Does this actually solve the problem you want to fix? Yes. Have you looked into what causes the icon to occur into the doc in the first place? According to Hengist: Perhaps it's not the OS upgrading the process, but rather some code in some extension calling TransformProcessType It's the Carbon Process Manager. (There's no good reason for it to do so, but hey, I didn't write the thing.) Do we have the sources for that, do you know? What are possible side effects of setting this property? See the Apple doc I referenced earlier. I'm going to set this flag (LSUIElement) in the system Python of every Mac at PARC I can get my hands on, so we'll get some idea of the effects. I encourage others on this list to also set it, and see what kind of effects you notice. So far, my experience is positive. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote: Most of *my* wxPython-based (actually dabo-based) tools don't even need to be an app bundle - doubleclicking some .py file is mostly enough. But I wouldn't like to loose some GUI functionality. IMHO running the script shouldn't be the default action for .py files, ever. I have two reason's for that: (1) most .py files I run into are just source code instead of scripts and shouldn't be executed but opened in an editor, and (2) this makes it way to easy to accidently execute a random python script that you've downloaded from the internet. Yes, I agree. I'm seriously wondering if having Python Launcher.app is a good idea, and if we shouldn't scrap it entirely. If building full app bundles using py2app is too much of a burden we could look into providing an easier and more lightweight way to build such bundles. The fully standalone bundles that py2app creates are very useful, but I definitely see the need for very thin .app bundles as well. Interesting idea. What's the lightest thing that's an app, anyway? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
has hengist.p...@virgin.net wrote: Annoying, but tweaking the Python.app bundle's LSBackgroundOnly/LSUIElement flags isn't a solution, it's a kludge - one that will take us back to the bad old days where some scripts automatically fail when run with 'python'. *Right now*, some scripts fail when run with python. My scripts :-). Look, setting LSUIElement still allows access to the WM -- that's what it's for: ``LSUIElement (String). If this key is set to '1', Launch Services runs the application as an agent application. Agent applications do not appear in the Dock or in the Force Quit window. Although they typically run as background applications, they can come to the foreground to present a user interface if desired. A click on a window belonging to an agent application brings that application forward to handle events.'' I'm *only* suggesting this for Python.app -- other Python-based apps, like IDLE.app, that desire a dock icon can still have a different Info.plist. For that matter, even if we set LSBackgroundOnly, you'd still have access to the WM -- my appscript-based while True loop runs fine when I set this flag. The key is that you can always make the process more heavyweight, but you can't go in the other direction. So Python should start as low as possible, and work up as necessary. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] setting LSUIElement in Python.app Info.plist
I have to say, I find the somewhat uninformed resistance to this idea incredible. It's an *idea*, folks, not a patch. It can't hit OS X in any form till 10.7, which is well over a year away. Relax -- try it out, read the docs, and report back. Let's *find out* what the effects of doing this would be, not speculate about them. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ronald Oussoren ronaldousso...@mac.com wrote:
On 3 Feb, 2009, at 17:54, Bill Janssen wrote:
I'm seriously wondering if having Python Launcher.app is a good
idea, and if we shouldn't scrap it entirely. If building full app
bundles using py2app is too much of a burden we could look into
providing an easier and more lightweight way to build such bundles.
The fully standalone bundles that py2app creates are very useful, but
I definitely see the need for very thin .app bundles as well.
Interesting idea. What's the lightest thing that's an app, anyway?
AFAIK an executable + Info.plist + icon file (plus the right directory
structure). The executable can be shell-script on Leopard, but a
simple executable would IMHO be better. One way to structure such an
executable is to read the name of the actual script to execute from
the Info.plist (using a custom key) and then use the standard Python
C-
API to execute that script.
So you'd have a little custom launcher that would read that key and use
the Python C API -- sort of the way that Java apps use the
JavaApplicationStub. Doesn't actually have to be a C program, you know;
it could be a shell script:
#!/usr/bin/python
import plistlib, os
script =
os.path.normpath(plistlib.readPlist('../Info.plist')['ApplicationPythonScript'])
os.execv(['/usr/bin/python', script])
I didn't test that!
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Chris, I'm a bit confused, too. Could someone (Bill?) summarize what functionally will change if this change is applied? Basically, if you're running /usr/bin/python or Python.app directly, you still won't get a dock icon even if you're using appscript. The app is marked as an agent application -- still trying to figure out just what that means. Some python scripts that are GUI-free are calling some Carbon APIs that cause the system to promote them to full-GUI mode, and that then breaks things: - you get a icon in the doc, which you don't want - they are not shut down by the system when logging off/shutting down, 'cause they don't respond to the appropriate calls. Yep, that's what seems to be happening. By the way, that later issues confuses the heck out of me -- why the heck would anyone write a system shut down procedure that couldn't override a non-responsive application? -- weird. (of course, Windows does it too...) Excellent point. I think what happens is that the system thinks Python should be responding to it, and when it doesn't (because it's been improperly promoted), it feels it might have timed out, and to avoid losing your data, cancels the logout. I assume there's some magic key combo you could press while logging out to override that protection; I just don't know what it is. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Christopher Barker chris.bar...@noaa.gov wrote: This is a concern -- what if I do need to Force Quit my app? I can probably find it with ps, and kill it with kill, but that's only because I was a Linux geek before I got a Mac. Then give your app its own Info.plist. There are zillions of processes running on your Mac that don't appear in the Force Quit window -- that's what Activity Monitor is for. Also, if you do want an icon in the dock -- even the default rocket -- you would need to do something special to get it, no? Yes -- use a different Info.plist. Though: I've tried changing my info.plist and haven't seen any change at all -- how do I know if I did it right? I'm tempted to say: if you don't know whether or not you've done it right, don't try doing it at all. But in the spirit of education, here's what I've got in my Python.app's Info.plist: keyLSUIElement/key true/ The key is that you can always make the process more heavyweight, but you can't go in the other direction. So Python should start as low as possible, and work up as necessary Which does make sense. Thanks! As there are really only a few GUI toolkits: wxPython TkInter pyObjC pyQT It may be fine to have the GUI code promote the app, but we do need to get those devs on board (as Robin apparently already is). Sure. TkInter is part of Python, so any patch should cover that as well. PyObjC programs can make the call directly, if they wish to, but most PyObjC programs with windows are probably full-fledged apps, anyway. Don't know much about pyQt, or pyGTK. I also don't think the GUI toolkit should promote willy-nilly -- it should probably provide a call which the user program can make to promote. And another option is the pythonb option for background apps, analogous to the old pythonw Or PythonBackground.app, which would also be a way to slice this. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Kevin Walzer k...@codebykevin.com wrote: Bill, the behavior that you experiencing is the expected behavior of Python, albeit not what you want in this instance. Rather than re-doing the long-standing infractucture of Python on the Mac, wouldn't it be better to find the code that is causing the undesired rocket launch and fix it, or at least work around it? Woudn't a non-framework, Unix-style build of Python avoid these issues altogether? It would, and that's actually the long-standing infrastructure of Python on the Mac that you refer to. The Python.app formulation is recent, and not yet well-enough debugged. Try setting LSUIElement in your Python.app's Info.plist, and report back with what's broken. I think you'll find double-clicking on UI apps works just fine. Though I also think that launching by double-clicking on .py files is a mistaken binding. It should probably bring up an editor. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Bill Janssen jans...@parc.com wrote: It would, and that's actually the long-standing infrastructure of Python on the Mac that you refer to. The Python.app formulation is recent, and not yet well-enough debugged. Though, I should hasten to say, I think removing the distinction between python and pythonw was a decided improvement. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
I'm thinking that the right thing to do about rocket-in-the-dock should be to change the Info.plist of Python.app, to include the setting LSUIElement: 1. Here's the doc from Apple: ``LSUIElement (String). If this key is set to '1', Launch Services runs the application as an agent application. Agent applications do not appear in the Dock or in the Force Quit window. Although they typically run as background applications, they can come to the foreground to present a user interface if desired. A click on a window belonging to an agent application brings that application forward to handle events.The Dock and loginwindow are two applications that run as agent applications.'' It seems to me that this is what we want for the Python interpreter proper. Applications (like IDLE) that are indeed proper foreground apps can always call TransformProcessType() to override this setting and get a dock icon for themselves. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Christopher Barker chris.bar...@noaa.gov wrote: Bill Janssen wrote: It seems to me that this is what we want for the Python interpreter proper. could be. It sounds promising. Applications (like IDLE) that are indeed proper foreground apps can always call TransformProcessType() to override this setting and get a dock icon for themselves. Could you change it in the info.plist of a py2app'ed app also? Id suggest that that be default in py2app. You kind of need to use py2app (or similar) to get an app to act right in the GUI anyway. Yes, that sounds like a good idea to me. I've never used py2app; does it include a private copy of Python? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Christopher Barker chris.bar...@noaa.gov wrote: Bill Janssen wrote: Yes, that sounds like a good idea to me. I've never used py2app; does it include a private copy of Python? yes and no: yes, if you run it with the non-apple python no, if you run it with Apple's system python (which I think is next to useless, frankly -- Apple does not keep the system python consistent between versions) In any case, it does include a info.plist, and it may include a different launch stub, so setting LSUIElement = 1 may work in either case. Sounds reasonable, then. Set LSUIElement=1 in the Python.app Info.plist, and other apps that use python can set it differently if they wish. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Ned Deily n...@acm.org wrote: In article 73365.1233593...@parc.com, Bill Janssen jans...@parc.com wrote: I'm thinking that the right thing to do about rocket-in-the-dock should be to change the Info.plist of Python.app, to include the setting LSUIElement: 1. There's also LSBackgroundOnly. That might be even more appropriate. But OTOH ... Yes, I'm thinking that, too. I'm running my system Python with that set, and it seems to fix my various problems. For others following along, here's the pointer to the Apple docs: http://developer.apple.com/documentation/MacOSX/Conceptual/BPRuntimeConfig/Articles/PListKeys.html ... setting it does have the side effect of making IDLE's menus disappear when launched from the command line (bin/idle). (Launching via IDLE.app is unaffected.) Fascinating. But I don't think that's fatal -- shouldn't users be using IDLE.app? It also has the effect of removing the default Tcl/Tk-supplied menu bar for Tkinter programs; try running the turtleDemo, for instance. Those programs lose Copy/Paste/Cut and the Quit, though the app does quit if you click the red window close button. Perhaps tkinter can call TPT. Indeed. Given that there's already a #ifdef TK_AQUA section in Modules/_tkinter.c:init_tkinter(), I'd think that would be a fine place to put a call to TransformProcessType. That would probably make IDLE's menus reappear when launched from the command-line, too. I'm poking in that area at the moment and will be submitting a number of patches for 3.x and 2.x real soon now. I'll try to whip something up in the next few days and report back. I'll review them. One thing the background settings doesn't seem to change is the regression test (subprocess) that brings up the Application Failed dialog. But I haven't had time to look at that one in detail yet. Have you tried this with appscript? Yes. My appscript scanning app is working fine with LSBackgroundOnly set, and no rocket in the dock. I can logout, the various Python processes are terminated fine. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Christopher Barker chris.bar...@noaa.gov wrote: Ned Deily wrote: I'm thinking that the right thing to do about rocket-in-the-dock should be to change the Info.plist of Python.app, to include the setting LSUIElement: 1. There's also LSBackgroundOnly. That might be even more appropriate. I doubt it -- the whole point of this mess was to allow apps full-on desktop access. Setting LSBackgroundOnly doesn't prevent that, it just sets the default. Maybe we just need to return to the old python vs. pythonw distinction, but with a different default -- have a python-no-gui option. I don't believe we need to. ... setting it does have the side effect of making IDLE's menus disappear when launched from the command line (bin/idle). This is no OK -- it may be OK for IDLE itself, but when people are testing an debugging GUI apps (TK, or wx, or) they should be able to start a simple script at the command line without any restrictions. Sure, open myapp.app. But if you follow the conversation a bit further, I think we've found a place to enable that for _tkinter. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Should Python.app be an LSUIElement = 1 app?
Robin Dunn ro...@alldunn.com wrote: Bill Janssen wrote: But only tkinter is part of the Python distribution, I believe. Of course, whoever supports the various non-standard GUI toolkits might also want to make changes, if necessary. Of course, that's a pretty standard thing that most third-party packages have to do when a new version of Python is released, so I don't think it's a big deal. I have no problem adding a call to TransformProcessType (or whatever will be needed) to wxPython's startup code. I think it's safe to assume that if wx is being imported then the process should be promoted to a full desktop app. Not really -- that's why Apple has these three classes of application. I'd suggest that promotion to LSUIElement (agent application) by the toolkit is probably right, but I'd suggest that you only promote to full app by actually having an app bundle that overrides the default Info.plist. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript rocket-in-dock preventing logout
has hengist.p...@virgin.net wrote: ...or prevent the OS from automatically upgrading your python process to a GUI process (which it only does if it knows the executable is located in an application bundle, e.g. Python.app/ Contents/MacOS/python). Thanks! I'm not running Python.app -- I'm running /usr/bin/python, which if I follow the symlinks leads me to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5, which in turn file shows to be a dual-architecture executable, which in my case is Mach-O executable i386. So I don't see how this rule about automatic upgrading really applies -- I'm not using Python.app. Perhaps it's not the OS upgrading the process, but rather some code in some extension calling TransformProcessType (http://www.cocoadev.com/index.pl?TransformProcessType)? And I still don't see how to fix the logout/shutdown problem. The Apple Cocoa document on this, http://developer.apple.com/documentation/Cocoa/Conceptual/AppArchitecture/Tasks/GracefulAppTermination.html, seems to say In Cocoa, all raw events requiring application termination result in the invocation of the NSApplication delegation method applicationShouldTerminate:. If the delegate does not implement this method, the application is terminated regardless of any unsaved documents. Presumably, my script doesn't implement this method, and thus the application is terminated. How? Is it as simple as installing a SIGTERM handler? Bill Bill Janssen wrote: We discussed this a bit last year, but with no resolution that I remember. I've got a situation where a Python program is preventing logout/shutdown. It's a script that just runs in an endless loop watching what app I'm working with; when it sees one it knows (Preview, MS Word, Safari, etc.) it uses appscript to ask the app what document I'm looking at. It then squirrels that document away in a journal so that I've got a record of what I've been working with. The basic control loop is something like this: while True: ... see what's running, and possibly what document ... time.sleep(1.0) See: http://mail.python.org/pipermail/pythonmac-sig/2008-December/020792.html Two options described there: replace your 'while True' loop with a Carbon/Cocoa event loop, allowing a GUI-based process to handle incoming events, or prevent the OS from automatically upgrading your python process to a GUI process (which it only does if it knows the executable is located in an application bundle, e.g. Python.app/ Contents/MacOS/python). Regards, has ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript rocket-in-dock preventing logout
Bill Janssen jans...@parc.com wrote: I'm not running Python.app -- I'm running /usr/bin/python, which if I follow the symlinks leads me to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5, which in turn file shows to be a dual-architecture executable, which in my case is Mach-O executable i386. So I don't see how this rule about automatic upgrading really applies -- I'm not using Python.app. Hmmm, but when I do a ps, I see that the system, at least, thinks I'm using Python.app. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript rocket-in-dock preventing logout
Ned Deily n...@acm.org wrote: In article 55150.1233433...@parc.com, Bill Janssen jans...@parc.com wrote: has hengist.p...@virgin.net wrote: ...or prevent the OS from automatically upgrading your python process to a GUI process (which it only does if it knows the executable is located in an application bundle, e.g. Python.app/ Contents/MacOS/python). I'm not running Python.app -- I'm running /usr/bin/python, which if I follow the symlinks leads me to /System/Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5, which in turn file shows to be a dual-architecture executable, which in my case is Mach-O executable i386. So I don't see how this rule about automatic upgrading really applies -- I'm not using Python.app. Actually, you probably are. This can be a bit confusing unless you carefully trace through the steps in the Mac/Makefile.in, as I have been doing recently. Note that the binary at FW/bin/python2.5 is *not* the actual python interpreter binary. Rather it is the so-called pythonw binary whose only function is to execv to the real python binary which is located at FW/Resources/Python.app/Contents/MacOS/Python and that is inside an app bundle. Thanks, Ned. Yes, so I see, looking at the sources. The next question is, since the rocket-in-the-dock only happens sometime, is there something I can do to forestall the promotion? And, is the promotion happening because of the OS, or because of code in some extension (appscript, say, or PyObjC). Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] appscript rocket-in-dock preventing logout
We discussed this a bit last year, but with no resolution that I remember. I've got a situation where a Python program is preventing logout/shutdown. It's a script that just runs in an endless loop watching what app I'm working with; when it sees one it knows (Preview, MS Word, Safari, etc.) it uses appscript to ask the app what document I'm looking at. It then squirrels that document away in a journal so that I've got a record of what I've been working with. The basic control loop is something like this: while True: ... see what's running, and possibly what document ... time.sleep(1.0) When I fire this up, it creates a Python rocket icon in the dock. Not great, but I can live with it. But it also prevents logout and shutdown from working -- I keep getting the message Logout has timed out because the application Python has failed to quit. Does anyone know what I've got to do to this script to keep it from preventing logout? For bonus points, what do I have to do to keep it from putting the rocket in the dock? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] PDF reading
Paul Brown appwo...@mac.com wrote: anyone have any pointers on reading a pdf file. i need to extract the text content , page number , text style , block , ... all in XML if poss Paul Hi, Paul. I use a patched version of xpdf to get this stuff, which works pretty well. Extracts the text and wordbox info (page, word rectangle, font, bold/italic, etc.) for each word in the PDF. You can download the patch to xpdf from http://downloads.sourceforge.net/doceng-toolkit/doceng-package-sources.zip. You'll have to unpack the zip file and look for it in there, then apply it to the xpdf sources and build xpdf. I've sent the patch to the xpdf maintainer, but haven't heard more about it from him. See the (patched) xpdf man page for details of the output format (ASCII text, one word record per line). This is also included in the UpLib release at http://uplib.parc.com/; you'll have to register an account on the blog in order to get the download link for that. If you download and install one of the binary builds of UpLib, the patched xpdf is included. Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] socket code works on Win32 but not Mac :-(
Ranec python-...@cemery.org.uk wrote:
s.connect(('google.com', 0))
What does this even mean? google.com is a domain, not a server
(though it does forward to www.google.com). And port 0? Does
anything listen on port 0? Sounds like OS X is the only platform that
gets this right :-). Try this:
s.connect(('www.google.com', 80))
for instance, to connect to the Web server.
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] socket code works on Win32 but not Mac :-(
Sorry, my mistake. I didn't see you were using UDP... Bill Janssen jans...@parc.com wrote: does anything listen on port 0? Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] appscript Python script preventing logout
has hengist.p...@virgin.net wrote: copy Python.app's executable (.../Python.app/ Contents/MacOS/Python) to /usr/local/bin/pythonb and use that to run your scripts. Ah! That sounds easy. I'll try it. aemreceive's sfba module lets you run an event loop, which you need to handle any sort of incoming events, and installs a default 'quit' handler for you. It doesn't provide support for Carbon timers or background threads, however, so wouldn't be any use to you here. A better solution would be to build use Cocoa to provide your script with an event loop, as PyObjC isn't subject to the same restrictions as sfba. I was thinking the same thing. Thanks for the help! Bill ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
