[Pythonmac-SIG] py2App
Hello, Is py2App still working or is it an obsolete thing? I am unable to use it with the Python 2.4.3 that I have in '/Library/Frameworks/Python.framework/Versions/2.4/bin/python' but I can use it with the Darwin port of Python 2.4.2 in '/opt/local/bin' of my machine. With '/opt/local/bin/python' I can do an import of the py2app module but I cannot do the same with my default python in '/Library/Frameworks/Python.framework/Versions/2.4/bin/python' because the module is not found. I made a copy of the py2app folder located in the 'site_packages' folder from the 'opt' install to the standard 'Library' install at the root of my drive but the import is still not working. Can I use this method to make an install in '/Library' or should I do more than that? Are using py2app with Python 2.4.3? -- A+ Pierre ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] py2App
On May 9, 2006, at 9:32 AM, Pierre Thibault wrote: > Hello, > > Is py2App still working or is it an obsolete thing? I am unable to use > it with the Python 2.4.3 that I have in > '/Library/Frameworks/Python.framework/Versions/2.4/bin/python' but > I can > use it with the Darwin port of Python 2.4.2 in '/opt/local/bin' of my > machine. > > With '/opt/local/bin/python' I can do an import of the py2app > module but > I cannot do the same with my default python in > '/Library/Frameworks/Python.framework/Versions/2.4/bin/python' because > the module is not found. You need to install it (and anything else) for each Python you use. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] AE/PyObjC: how to use event loops to process AE
Daniel Lord wrote: >A PyObjC application using Appkit starts and event loop in AppHelper >thus: > > AppHelper.runEventLoop() > >But, the examples I have seen using Apple Events in Python (not >PyObjC) install their own handlers and then call the event loop: > > CarbonEvt.RunApplicationEventLoop() > >Unfortunately and unsurprisingly, trying to inject the handlers from >different methods in my PyObjC class inheriting from >NibClassBuilder.AutoBaseClass and then expecting them to be called >doesn't seem to work. Makes no difference if your app uses a Carbon or Cocoa event loop. You should be able to install your own Apple event handlers without any problem. You can use NSAppleEventManager, aemreceive or Cocoa Scripting; even Carbon.AE if you want (although there's no real reason to do so). Examples: 1. Using NSAppleEventManager (you'll need to do your own packing and unpacking of event descriptors, mind): from AppKit import * from PyObjCTools import NibClassBuilder, AppHelper import struct NibClassBuilder.extractClasses('MainMenu.nib') def aeKeyword(fourCharCode): return struct.unpack('L', fourCharCode)[0] class MyAppDelegate(NibClassBuilder.AutoBaseClass): def applicationWillFinishLaunching_(self, aNotification): aem = NSAppleEventManager.sharedAppleEventManager() aem.setEventHandler_andSelector_forEventClass_andEventID_( self, 'someEvent:reply:', aeKeyword('Some'), aeKeyword('Evnt')) def someEvent_reply_(self, event, reply): result = NSAppleEventDescriptor.descriptorWithInt32_(42) reply.setParamDescriptor_forKeyword_(result, aeKeyword('')) if __name__ == '__main__': AppHelper.runEventLoop() 2. Using aemreceive (you need to put function wrappers around PyObjC method calls, otherwise aemreceive's magic clashes with PyObjC's magic): from AppKit import * from PyObjCTools import NibClassBuilder, AppHelper import aemreceive NibClassBuilder.extractClasses('MainMenu.nib') class MyAppDelegate(NibClassBuilder.AutoBaseClass): def applicationWillFinishLaunching_(self, aNotification): aemreceive.installeventhandler( lambda:self.someEvent(), 'SomeEvnt') def someEvent(self): return 42 if __name__ == '__main__': AppHelper.runEventLoop() For doing it with Cocoa Scripting, follow Apple's documentation on implementing scriptability in Cocoa apps, translating to PyObjC as necessary. And remember to add any Info.plist settings and terminology resources as needed, of course. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] ical.py loose in the wild
John Hazen wrote: >Basically, I've got email messages with iCalendar (.ics) file >attachments. > >I can't seem to find the way in the iCal dictionary to make it import a >file (the "open" command thinks it's an iCal calendar, and errors out). If you can drag-n-drop the .ics file onto iCal's icon all right then 'tell app "iCal" to open alias "path:to:file.ics"' will work as well. Seems to on iCal 2.0 (OS 10.4); can't vouch for iCal 1.x. >I've tested the import of the .ics file using the Menu in iCal, and it >understands the files perfectly. Is there some way to do this under >script control? GUI Scripting (part of System Events). It's kludgy, tedious and fragile, but if you want to manipulate a GUI application directly and its scripting interface isn't up to snuff then manipulating its GUI objects is better than nothing. Probably best to ask on one of the AppleScript forums for help there; there'll be more folks there familiar with using it. >P.S. I'd prefer to do this with python, but this is essentially an >applescript question. Sorry if it's too OT. Python has very good application scripting support: http://freespace.virgin.net/hamish.sanderson/appscript.html Alternatively, I imagine you could bypass iCal and work directly with its iCalendar files; Google for Python+iCalendar. has -- http://freespace.virgin.net/hamish.sanderson/ ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] [JOB] Python/Mac Developer, NYC
My client is one of the world's premier auction houses. They are looking for a Python/Mac Developer with experience in all phases of development and, ideally, experience as a technical lead and architect. This is a full time, on-site, salaried job paying 60-90k dep on exp. More for the right guy/gal. They might allow some on-site and some off-site, but you must live within commutable distance to NYC. To be considered please submit resume and salary requirements to [EMAIL PROTECTED] Thank you, Beau J. Gould Open Source Staffing www.open-source-staffing.com [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] py2app corrupting libraries
Hi, all. We have a large mixed Python and C++ application with about a dozen frameworks which cross-reference one another. We’ve been shipping it for almost a year on PPC Macs using py2app to package things – so we know we have the py2app stuff approximately correct. We’ve been trying off and on to get a fat version of the app working. All the C++ code compiles and links cleanly on both architectures. We’ve installed fat Python 2.4.3 (the April 7 version). When we run the current (0.2-maint) branch of py2app on our Intel Mac, somewhere along the way, it tells us that it’s “Thinning” our “Events” library to the i386 part only…then, later on, it tries to thin the same library to both the ppc and i386 versions…but doesn’t find the ppc version anymore and crashes. Possibly of interest, but possibly a red herring: py2app spends a fair amount of time building the dependency graph and doing many operations over and over (the graph of our library dependencies is basically a web, not a hierarchy, and it seems to be doing a pretty exhaustive walk of the graph). We tried going into the macholib/util.py and stubbing out the thin_to_archs() function. As we only build the two architectures we care about, and we want both, we figured this should be safe. But then py2app crashes with an unrecognized magic number in some of the libraries. So we changed thin_to_archs() so that it always used both architectures, no matter what it was asked to build…and got the same (magic) problem. We even tried reversing the order of the two in case there was an order dependency somewhere. I know the macholib stuff is fairly tricky and at this point we’re kinda stumped. Below are the stack traces from the two types of crashes. Any advice or suggestions would be appreciated. Kent First one, unmodified py2app: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Thinning /Users/cb/blobs/trunk/Python/dist/Cosmic Blobs.app/Contents/Frameworks/Events.framework/Versions/A/Events to ppc, i386 /usr/bin/lipo: -extract ppc specified but fat file: /Users/cb/blobs/trunk/Python/dist/Cosmic Blobs.app/Contents/Frameworks/Events.framework/Versions/A/Events does not contain that architecture Traceback (most recent call last): File "setup.py", line 145, in ? argv_emulation=True, File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd) File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/dist.py", line 966, in run_command cmd_obj.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 373, in run self._run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 494, in _run self.run_normal() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 554, in run_normal self.create_binaries(py_files, pkgdirs, extensions, loader_files) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/py2app/build_app.py", line 652, in create_binaries platfiles = mm.run() File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/MachOStandalone.py", line 147, in run thin_to_archs(filename, nodearchs) File "/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/py2app/macholib/util.py", line 146, in thin_to_archs raise ValueError, 'Error %d returned by: %s' % (retval, ''.join(["'%s'" % arg for arg in command])) ValueError: Error 1 returned by: '/usr/bin/lipo''/Users/cb/blobs/trunk/Python/dist/Cosmic Blobs.app/Contents/Frameworks/Events.framework/Versions/A/Events''-output''/tmp/tmpxlJYOq''-extract''ppc''-extract''i386' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Second one, thin_to_archs() body commented out, is the same as the third try, with body of thin_to_archs() restored but archs param forced to ("ppc", "i386"), and also the same as the fourth try with the args reversed: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Graphing /Users/cb/blobs/trunk/Python/dist/Cosmic Blobs.app/Contents/Frameworks/Events.framework/Versions/A/Events (ppc) Traceback (most recent call last): File "setup.py", line 145, in ? argv_emulation=True, File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/core.py", line 149, in setup dist.run_commands() File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/dist.py", line 946, in run_commands self.run_command(cmd)
Re: [Pythonmac-SIG] py2app corrupting libraries
On May 10, 2006, at 5:14 PM, Kent Quirk wrote: > We have a large mixed Python and C++ application with about a dozen > frameworks which cross-reference one another. > > > > We’ve been shipping it for almost a year on PPC Macs using py2app > to package things – so we know we have the py2app stuff > approximately correct. We’ve been trying off and on to get a fat > version of the app working. All the C++ code compiles and links > cleanly on both architectures. We’ve installed fat Python 2.4.3 > (the April 7 version). > > > > When we run the current (0.2-maint) branch of py2app on our Intel > Mac, somewhere along the way, it tells us that it’s “Thinning” our > “Events” library to the i386 part only…then, later on, it tries to > thin the same library to both the ppc and i386 versions…but doesn’t > find the ppc version anymore and crashes. > > > > Possibly of interest, but possibly a red herring: py2app spends a > fair amount of time building the dependency graph and doing many > operations over and over (the graph of our library dependencies is > basically a web, not a hierarchy, and it seems to be doing a pretty > exhaustive walk of the graph). > > > > We tried going into the macholib/util.py and stubbing out the > thin_to_archs() function. As we only build the two architectures we > care about, and we want both, we figured this should be safe. But > then py2app crashes with an unrecognized magic number in some of > the libraries. So we changed thin_to_archs() so that it always used > both architectures, no matter what it was asked to build…and got > the same (magic) problem. We even tried reversing the order of the > two in case there was an order dependency somewhere. This probably isn't going to get fixed unless a patch or a set of binaries to reproduce this issue is available. I'm pretty much out of commission for the rest of the month though, so even with binaries I'm not going to get anywhere with it any time soon. -bob ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig