[Pythonmac-SIG] py2App

2006-05-10 Thread Pierre Thibault
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

2006-05-10 Thread Bob Ippolito

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

2006-05-10 Thread has
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

2006-05-10 Thread has
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

2006-05-10 Thread Beau Gould
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

2006-05-10 Thread Kent Quirk








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

2006-05-10 Thread Bob Ippolito

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