pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] 10.8, 10.9, NSDocument, TypeError, "cannot change a method"

[Ronald O. <ron...@ma...>]

On 28 Aug, 2013, at 15:25, Erik van Blokland <er...@le...> wrote:

> Hi
> 
> I'm aware this is a bit of a long shot, but maybe someone recognises this issue. 
> 
> I have a python application generated with pyobjc on OSX 10.8.
> 	- Stock python Python 2.7.2 (default, Oct 11 2012, 20:14:37)
> 	- presumably also a stock objc 2.3.2a0, (at /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/objc/__init__.py)
> 
> On 10.7 and 10.8 I can get a new window when I select New from the menu. 
> On 10.9 (the current developer release) I get an exception, "cannot change a method" - see below. The app continues to run, but there isn't much of a traceback. 
> 
> Looking at the dump, I get the impression something goes wrong when NSDocumentController calls newDocument: My NSDocument subclass doesn't contain anything suspicious. I think I'm using up to date calls for reading and writing. Methods in my NSDocument subclass:  
> 	init
> 	readFromURL_ofType_error_
> 	writeSafelyToURL_ofType_forSaveOperation_error_
> 	makeWindowControllers
> 	+ a couple of callbacks for menus. 
> 
> I've tested this with two independent projects, both get the same exception. 
> Any guesses would be welcome, thanks.

The exception you're getting (``TypeError('cannot change a method')``) is raised when you try to set an instance attribute with the same name as a method, for example:

:>>> from Cocoa import NSObject
:>>> o = NSObject.alloc().init()
:>>> o.description = 42
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot change a method

This means that your document class problably has an attribute that has the same name as a method that is new in OSX 10.9.

BTW. Have you tried ``objc.setVerbose(1)``? That should print more information when converting exceptions from Python to ObjC.  I guess I should also change the code that raises the exception to include more information (such as the name of the attribute).

Ronald


> Erik
> 
> Exception Name: OC_PythonException
> Description: <type 'exceptions.TypeError'>: cannot change a method
> User Info: {
>   "__pyobjc_exc_traceback__" = "<traceback object at 0x112ea8680>";
>   "__pyobjc_exc_type__" = "<type 'exceptions.TypeError'>";
>   "__pyobjc_exc_value__" = "TypeError('cannot change a method',)";
> }
> 
> 0   CoreFoundation                      0x00007fff886878ce __exceptionPreprocess + 174
> 1   libobjc.A.dylib                     0x00007fff8f656f51 objc_exception_throw + 43
> 2   CoreFoundation                      0x00007fff8872d619 -[NSException raise] + 9
> 3   _objc.so                            0x000000010acb1366 PyObjCFFI_MakeClosure + 4418
> 4   libffi.dylib                        0x00007fff91c02a1f ffi_closure_unix64_inner + 509
> 5   libffi.dylib                        0x00007fff91c0211e ffi_closure_unix64 + 70
> 6   AppKit                              0x00007fff888e0b0f -[NSDocumentController newDocument:] + 36
> 7   AppKit                              0x00007fff88af90da -[NSApplication sendAction:to:from:] + 327
> 8   AppKit                              0x00007fff88c1d548 -[NSMenuItem _corePerformAction] + 394
> 9   AppKit                              0x00007fff88c1d234 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 117
> 10  AppKit                              0x00007fff8893e72d -[NSMenu _internalPerformActionForItemAtIndex:] + 35
> 11  AppKit                              0x00007fff8893e5a5 -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 104
> 12  AppKit                              0x00007fff88c16442 NSSLMMenuEventHandler + 716
> 13  HIToolbox                           0x00007fff8ad8a9a4 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 892
> 14  HIToolbox                           0x00007fff8ad89f67 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 385
> 15  HIToolbox                           0x00007fff8ad9f4f0 SendEventToEventTarget + 40
> 16  HIToolbox                           0x00007fff8add4380 _ZL18SendHICommandEventjPK9HICommandjjhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef + 420
> 17  HIToolbox                           0x00007fff8ad7b818 SendMenuCommandWithContextAndModifiers + 59
> 18  HIToolbox                           0x00007fff8ad7b7ba SendMenuItemSelectedEvent + 178
> 19  HIToolbox                           0x00007fff8ad7b697 _ZL19FinishMenuSelectionP13SelectionDataP10MenuResultS2_ + 94
> 20  HIToolbox                           0x00007fff8ad58d95 _ZL14MenuSelectCoreP8MenuData5PointdjPP13OpaqueMenuRefPt + 718
> 21  HIToolbox                           0x00007fff8ad58261 _HandleMenuSelection2 + 446
> 22  AppKit                              0x00007fff88ae8109 _NSHandleCarbonMenuEvent + 284
> 23  AppKit                              0x00007fff88a13f1e _DPSNextEvent + 2170
> 24  AppKit                              0x00007fff88a1328b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
> 25  AppKit                              0x00007fff88a0b53c -[NSApplication run] + 553
> 26  AppKit                              0x00007fff889b5563 NSApplicationMain + 940
> 27  _AppKit.so                          0x000000010cbfcbbe init_AppKit + 8609
> 28  Python                              0x000000010ab025a9 PyEval_EvalFrameEx + 9244
> 29  Python                              0x000000010ab00147 PyEval_EvalCodeEx + 1934
> 30  Python                              0x000000010ab068df _PyEval_SliceIndex + 989
> 31  Python                              0x000000010ab0263a PyEval_EvalFrameEx + 9389
> 32  Python                              0x000000010ab00147 PyEval_EvalCodeEx + 1934
> 33  Python                              0x000000010aaff9b3 PyEval_EvalCode + 54
> 34  Python                              0x000000010ab3bc70 PyParser_ASTFromFile + 299
> 35  Python                              0x000000010ab3bd3c PyRun_FileExFlags + 165
> 36  Python                              0x000000010aafa830 _PyBuiltin_Init + 4737
> 37  Python                              0x000000010ab025a9 PyEval_EvalFrameEx + 9244
> 38  Python                              0x000000010ab00147 PyEval_EvalCodeEx + 1934
> 39  Python                              0x000000010ab068df _PyEval_SliceIndex + 989
> 40  Python                              0x000000010ab0263a PyEval_EvalFrameEx + 9389
> 41  Python                              0x000000010ab00147 PyEval_EvalCodeEx + 1934
> 42  Python                              0x000000010aaff9b3 PyEval_EvalCode + 54
> 43  Python                              0x000000010ab3bc70 PyParser_ASTFromFile + 299
> 44  Python                              0x000000010ab3bd3c PyRun_FileExFlags + 165
> 45  Python                              0x000000010ab3b726 PyRun_SimpleFileExFlags + 410
> 46  Superpolator                        0x000000010a988e79 main + 5965
> 47  Superpolator                        0x000000010a987cad main + 1409
> 48  libdyld.dylib                       0x00007fff8d81160d start + 1
> 49  ???                                 0x0000000000000001 0x0 + 1
> ------------------------------------------------------------------------------
> Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
> Discover the easy way to master current and previous Microsoft technologies
> and advance your career. Get an incredible 1,500+ hours of step-by-step
> tutorial videos with LearnDevNow. Subscribe today and save!
> http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] 10.8, 10.9, NSDocument, TypeError, "cannot change a method"

[Erik v. B. <er...@le...>]

Hi

I'm aware this is a bit of a long shot, but maybe someone recognises this issue. 

I have a python application generated with pyobjc on OSX 10.8.
	- Stock python Python 2.7.2 (default, Oct 11 2012, 20:14:37)
	- presumably also a stock objc 2.3.2a0, (at /System/Library/Frameworks/Python.framework/Versions/2.7/Extras/lib/python/PyObjC/objc/__init__.py)

On 10.7 and 10.8 I can get a new window when I select New from the menu. 
On 10.9 (the current developer release) I get an exception, "cannot change a method" - see below. The app continues to run, but there isn't much of a traceback. 

Looking at the dump, I get the impression something goes wrong when NSDocumentController calls newDocument: My NSDocument subclass doesn't contain anything suspicious. I think I'm using up to date calls for reading and writing. Methods in my NSDocument subclass:  
	init
	readFromURL_ofType_error_
	writeSafelyToURL_ofType_forSaveOperation_error_
	makeWindowControllers
	+ a couple of callbacks for menus. 

I've tested this with two independent projects, both get the same exception. 
Any guesses would be welcome, thanks.
Erik

Exception Name: OC_PythonException
Description: <type 'exceptions.TypeError'>: cannot change a method
User Info: {
   "__pyobjc_exc_traceback__" = "<traceback object at 0x112ea8680>";
   "__pyobjc_exc_type__" = "<type 'exceptions.TypeError'>";
   "__pyobjc_exc_value__" = "TypeError('cannot change a method',)";
}

0   CoreFoundation                      0x00007fff886878ce __exceptionPreprocess + 174
1   libobjc.A.dylib                     0x00007fff8f656f51 objc_exception_throw + 43
2   CoreFoundation                      0x00007fff8872d619 -[NSException raise] + 9
3   _objc.so                            0x000000010acb1366 PyObjCFFI_MakeClosure + 4418
4   libffi.dylib                        0x00007fff91c02a1f ffi_closure_unix64_inner + 509
5   libffi.dylib                        0x00007fff91c0211e ffi_closure_unix64 + 70
6   AppKit                              0x00007fff888e0b0f -[NSDocumentController newDocument:] + 36
7   AppKit                              0x00007fff88af90da -[NSApplication sendAction:to:from:] + 327
8   AppKit                              0x00007fff88c1d548 -[NSMenuItem _corePerformAction] + 394
9   AppKit                              0x00007fff88c1d234 -[NSCarbonMenuImpl performActionWithHighlightingForItemAtIndex:] + 117
10  AppKit                              0x00007fff8893e72d -[NSMenu _internalPerformActionForItemAtIndex:] + 35
11  AppKit                              0x00007fff8893e5a5 -[NSCarbonMenuImpl _carbonCommandProcessEvent:handlerCallRef:] + 104
12  AppKit                              0x00007fff88c16442 NSSLMMenuEventHandler + 716
13  HIToolbox                           0x00007fff8ad8a9a4 _ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec + 892
14  HIToolbox                           0x00007fff8ad89f67 _ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec + 385
15  HIToolbox                           0x00007fff8ad9f4f0 SendEventToEventTarget + 40
16  HIToolbox                           0x00007fff8add4380 _ZL18SendHICommandEventjPK9HICommandjjhPKvP20OpaqueEventTargetRefS5_PP14OpaqueEventRef + 420
17  HIToolbox                           0x00007fff8ad7b818 SendMenuCommandWithContextAndModifiers + 59
18  HIToolbox                           0x00007fff8ad7b7ba SendMenuItemSelectedEvent + 178
19  HIToolbox                           0x00007fff8ad7b697 _ZL19FinishMenuSelectionP13SelectionDataP10MenuResultS2_ + 94
20  HIToolbox                           0x00007fff8ad58d95 _ZL14MenuSelectCoreP8MenuData5PointdjPP13OpaqueMenuRefPt + 718
21  HIToolbox                           0x00007fff8ad58261 _HandleMenuSelection2 + 446
22  AppKit                              0x00007fff88ae8109 _NSHandleCarbonMenuEvent + 284
23  AppKit                              0x00007fff88a13f1e _DPSNextEvent + 2170
24  AppKit                              0x00007fff88a1328b -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 122
25  AppKit                              0x00007fff88a0b53c -[NSApplication run] + 553
26  AppKit                              0x00007fff889b5563 NSApplicationMain + 940
27  _AppKit.so                          0x000000010cbfcbbe init_AppKit + 8609
28  Python                              0x000000010ab025a9 PyEval_EvalFrameEx + 9244
29  Python                              0x000000010ab00147 PyEval_EvalCodeEx + 1934
30  Python                              0x000000010ab068df _PyEval_SliceIndex + 989
31  Python                              0x000000010ab0263a PyEval_EvalFrameEx + 9389
32  Python                              0x000000010ab00147 PyEval_EvalCodeEx + 1934
33  Python                              0x000000010aaff9b3 PyEval_EvalCode + 54
34  Python                              0x000000010ab3bc70 PyParser_ASTFromFile + 299
35  Python                              0x000000010ab3bd3c PyRun_FileExFlags + 165
36  Python                              0x000000010aafa830 _PyBuiltin_Init + 4737
37  Python                              0x000000010ab025a9 PyEval_EvalFrameEx + 9244
38  Python                              0x000000010ab00147 PyEval_EvalCodeEx + 1934
39  Python                              0x000000010ab068df _PyEval_SliceIndex + 989
40  Python                              0x000000010ab0263a PyEval_EvalFrameEx + 9389
41  Python                              0x000000010ab00147 PyEval_EvalCodeEx + 1934
42  Python                              0x000000010aaff9b3 PyEval_EvalCode + 54
43  Python                              0x000000010ab3bc70 PyParser_ASTFromFile + 299
44  Python                              0x000000010ab3bd3c PyRun_FileExFlags + 165
45  Python                              0x000000010ab3b726 PyRun_SimpleFileExFlags + 410
46  Superpolator                        0x000000010a988e79 main + 5965
47  Superpolator                        0x000000010a987cad main + 1409
48  libdyld.dylib                       0x00007fff8d81160d start + 1
49  ???                                 0x0000000000000001 0x0 + 1

Re: [Pyobjc-dev] Towards PyObjC 3.0

[Ronald O. <ron...@ma...>]

On 4 Jul, 2013, at 17:08, Ronald Oussoren <ron...@ma...> wrote:
> 
> My self-imposed dead-line for a 3.0 release is "before OSX 10.9 is released", that's the easiest way to avoid getting carried away with wrapping all new APIs in OSX 10.9 and delaying the release even further.

That seems to be overly optimistic on my part, I've done almost no work on PyObjC since my previous mail due to lack of time.

Ronald

Re: [Pyobjc-dev] Fwd: SillyBallsSaver

[Ronald O. <ron...@ma...>]

On 6 Jul, 2013, at 15:22, Dinu Gherman <gh...@da...> wrote:

> Ronald Oussoren:
> 
>> It is possible, and don't understand yet why it works on my machine and not on other systems.
> 
> BTW, what's the testing strategy behind PyObjC, and does it involve systematic testing on several versions of OS X?

"Testing strategy" is not quite the term I'd use. I primairily test on my laptop (currently running 10.8) and try to test on older OSX releases before pushing out larger updates.  A test suite would probably not have found this problem though, for frameworks I basicly check that the framework can be important and that symbols have the expected definition. The ScreenSaver framewor has always worked in non-GC processes to be able to configure a screensaver from system preferences, while actually using a screensaver required GC support in a number of OSX releases and that also wasn't caught by the testsuite.

I have a helper script to run the testsuite with a number of python versions and publish the results, and still want to use that to do some form of CI (even if that consists of running the testsuite weekly from a cron job, PyObjC doesn't change that much in general). The primary stumbling block for doing that is lack of resources, I need a machine other than my main one that I can use to run the testsuite in VMs with the various OSX releases.  I might use my current machine for that when Apple releases the next generation of macbooks ;-). At one time I hoped to use a Linux system with KVM for this, but AFAIK KVM doesn't support OSX guests yet.

Ronald

Re: [Pyobjc-dev] Fwd: SillyBallsSaver

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> It is possible, and don't understand yet why it works on my machine and not on other systems.

BTW, what's the testing strategy behind PyObjC, and does it involve systematic testing on several versions of OS X?

Cheers,

Dinu

Re: [Pyobjc-dev] Fwd: SillyBallsSaver

[Ronald O. <ron...@ma...>]

On 6 Jul, 2013, at 2:58, Jason Sundram <jsu...@gm...> wrote:

> I'm trying to get a PyObjC screensaver to run on osx 10.8, but not having any luck.
> Is it possible?

It is possible, and don't understand yet why it works on my machine and not on other systems.

Ronald

> 
> ---------- Forwarded message ----------
> From: Jason Toffaletti <tof...@gm...>
> Date: Sun, Jun 9, 2013 at 9:57 PM
> Subject: Re: SillyBallsSaver
> To: Jason Sundram <jsu...@gm...>
> 
> 
> I'm sorry I can't help. I haven't done any Mac programming for many years.
> 
> On Jun 9, 2013, at 5:23 PM, Jason Sundram <jsu...@gm...> wrote:
> 
>> Hi Jason,
>> 
>> I'm writing to you because I saw your email address in the readme for SillyBallsSaver. I've been trying to run it on osx 10.8, which should apparently work (according to this thread on stackoverflow), but couldn't get it to work.
>> 
>> Do you know what needs to be done to get it to run?
>> 
>> Thanks,
>> 
>> Jason
> 
> 
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
> 
> Build for Windows Store.
> 
> http://p.sf.net/sfu/windows-dev2dev_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Fwd: SillyBallsSaver

[Jason S. <jsu...@gm...>]

I'm trying to get a PyObjC screensaver to run on osx 10.8, but not having
any luck.
Is it possible?

---------- Forwarded message ----------
From: Jason Toffaletti <tof...@gm...>
Date: Sun, Jun 9, 2013 at 9:57 PM
Subject: Re: SillyBallsSaver
To: Jason Sundram <jsu...@gm...>


I'm sorry I can't help. I haven't done any Mac programming for many years.

On Jun 9, 2013, at 5:23 PM, Jason Sundram <jsu...@gm...> wrote:

Hi Jason,

I'm writing to you because I saw your email address in the readme for
SillyBallsSaver<https://bitbucket.org/ronaldoussoren/pyobjc/src/78d315181dd4d7c7c18f366af5d7afb3b8583013/pyobjc-framework-ScreenSaver/Examples/SillyBallsSaver?at=default>.
I've been trying to run it on osx 10.8, which should apparently work
(according to this thread on
stackoverflow<http://stackoverflow.com/questions/7821589/compile-64-bit-mac-app-with-py2app/7840593?noredirect=1#comment24574484_7840593>),
but couldn't get it to work.

Do you know what needs to be done to get it to run?

Thanks,

Jason

[Pyobjc-dev] Towards PyObjC 3.0

[Ronald O. <ron...@ma...>]

Hi,

I recently realised that I've been much to silent on the development of PyObjC.  I'm making steady progress on a new major release of PyObjC and am getting closer to a beta release of PyObjC 3.0, although progress is too slow to my taste :-)

In januari (6 months ago already...) I was at a hackweek @Dropbox where I seriously started work on this new release. During that week I basicly rewrote the way that PyObjC looks for methods, the old way was inherently ugly and slow, the new one is cleaner and faster (although it appears to be not so much faster that its actually noticable...).  That rewrite probably wouldn't have happened without hackweek, it required several days of concentrated hacking and that is something I can't do in my regular environment (there's those pesky customers that also want to get work done).

Since then I've done further cleanup work and some optimization (first tests indicate that the bridge uses less memory and is faster).  I'm finally closing in on a situation where the core bridge is cleaned up and can be reasonably sure that I won't have to make backward incompatible changes in the future. 

Now up to the really hard work: clean up the documentation and example code. That will probably eat away a lot of nights (with a lot of simple changes in the examples and hard thinking on how to improve the documentation; writing usable documentation is hard).

My self-imposed dead-line for a 3.0 release is "before OSX 10.9 is released", that's the easiest way to avoid getting carried away with wrapping all new APIs in OSX 10.9 and delaying the release even further.

Currently side-tracked on trying to get a change to super() into Python 3.4,

   Ronald

P.S. A small public service announcement: try to avoid "from Cocoa import *", and use explicit imports (either "import Cocoa; o = Cocoa.NSObject.new()" or "from Cocoa import NSObject"). The current release of PyObjC contains optimizations that make explicit imports faster by doing much less work, and I expect to improve this further in future release.  A nice side effect of avoiding '*' imports is that code analysis tools like pyflakes will do a much better jobs on your code.

[Pyobjc-dev] lazyimport.py introduced in pyobjc 2.4

[Marc V. O. <ma...@ac...>]

hi,

Just upgraded an old pyobjc app from 2.2 to 2.5.1 and noticed that launching the app was very slow.
After using cProfile and analyzing in runsnake. I notice that lazyimport.py takes 18 seconds on the app. 
On launch the app loads a lot of views.

from Cocoa import *
I replaced them quickly just for test in the app. because this was every but this didn't help my app loading performance.

I was looking at this:
http://pythonhosted.org/pyobjc/metadata/compiled.html

And i'm wondering what is the best way to upgrade my app to take advantage of the new compiled metadata system.

thanks

marc

Re: [Pyobjc-dev] Problem running PyObjC/py2app app on machine without PyObjC installed

[Zachery B. <zb...@ur...>]

On May 10, 2013, at 10:33 AM, Ronald Oussoren <ron...@ma...> wrote:

> On 10 May, 2013, at 16:16, Zachery Bir <zb...@ur...> wrote:
>>> 
>>> What are the OSX versions of the machine where you build PyObjC and where you tried to start the application?  This might be a deployment target issue, that is a binary with a deployment target that is higher than the OS you try to run the app on.
>> 
>> I'm building Zem on 10.8.2, but I get the error on other 10.8.2 machines without PyObjC installed. The specific error I pasted earlier came from 10.7.5. What's the best way to declare deployment target in a totally script-driven py2app environment?
> 
> That's the easy part, you don't have to :-)
> 
> The harder part is building the binaries for Python and all extensions that you use. The easiest way is to use a Python installation with the proper deployment target, I use the following configure line to build a Python framework that I can use on OSX 10.5:
> 
> $ ../configure --enable-framework --with-framework-name=Python105 --enable-universalsdk=/ --with-universal-archs=intel MACOSX_DEPLOYMENT_TARGET=10.5
> 
> Then install all libraries that you use in Python105.framework and use that to create the application.

Excellent, I'll try that next.

Zac

Re: [Pyobjc-dev] Problem running PyObjC/py2app app on machine without PyObjC installed

[Ronald O. <ron...@ma...>]

On 10 May, 2013, at 16:16, Zachery Bir <zb...@ur...> wrote:
>> 
>> 
>> What are the OSX versions of the machine where you build PyObjC and where you tried to start the application?  This might be a deployment target issue, that is a binary with a deployment target that is higher than the OS you try to run the app on.
> 
> I'm building Zem on 10.8.2, but I get the error on other 10.8.2 machines without PyObjC installed. The specific error I pasted earlier came from 10.7.5. What's the best way to declare deployment target in a totally script-driven py2app environment?

That's the easy part, you don't have to :-)

The harder part is building the binaries for Python and all extensions that you use. The easiest way is to use a Python installation with the proper deployment target, I use the following configure line to build a Python framework that I can use on OSX 10.5:

$ ../configure --enable-framework --with-framework-name=Python105 --enable-universalsdk=/ --with-universal-archs=intel MACOSX_DEPLOYMENT_TARGET=10.5

Then install all libraries that you use in Python105.framework and use that to create the application.

NOTE: This works for Python itself and PyObjC, but you may have to do more work when you use other C libraries. One problem I've run into in the past is that some configure scripts quite helpfully picked up that the build machine had an API available, but that API wasn't available on older OSX releases. Actually building stuff for deployment on older OSX systems isn't too hard, but can require some tinkering.   That's ignoring deployment to PPC machine, AFAIK the only supported way to to that is to keep a 10.5 machine around (for example in a VM). There are some hacks to install Xcode 3 on Lion, but I haven't tried those and I've seen reports that those hacks don't work on 10.8.

I might be tempted to start a project for building binary packages once the dust settles on support for wheel packages in the stdlib (with some luck before Python 3.4 is released).

Ronald

> 
> Thanks,
> 
> Zac
> 
> 
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and 
> their applications. This 200-page book is written by three acclaimed 
> leaders in the field. The early access version is available now. 
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Problem running PyObjC/py2app app on machine without PyObjC installed

[Zachery B. <zb...@ur...>]

On May 10, 2013, at 5:11 AM, Ronald Oussoren <ron...@ma...> wrote:

> On 9 May, 2013, at 20:14, Zachery Bir <zb...@ur...> wrote:
> 
>> Hey, all. Long time no see.
> 
> Welcome back :-)
> 
>> 
>> So, I've revived one of my PyObjC apps (Zem), but am running into problems getting the resulting app to launch on systems that don't already have PyObjC installed. This hasn't so far happened with my other PyObjC apps, so I'm wondering if I'm just doing something wrong.
>> 
>> Here's a link to the py2app-built binary: http://swng.it/nP7QK
>> 
>> Here's the code: https://github.com/orangutango/Zem/
>> 
>> I could tell that some things had changed in the PyObjC/py2app worlds since the last time I heavily used them.
>> 
>> I built this bundle the standard way:
>> 
>> $ python setup.py py2app --iconfile Resources/Zem.icns
>> 
>> (Incidentally, I'm not sure why it doesn't pick up on my Info.plist entry for CFBundleIconFile, but whatever)
> 
> That is a bug, py2app should pick up CFBundleIconFile (although you should arrange for it to be copied into the app bundle, which your setup.py file does).

I figured as much. This is less an immediate problem, of course.

>> The error I get on machines without PyObjC installed is:
>> 
>> Zacherys-Mac:~ zbir$ Downloads/Zem.app/Contents/MacOS/Zem 
>> Traceback (most recent call last):
>> File "/Users/zbir/Downloads/Zem.app/Contents/Resources/__boot__.py", line 316, in <module>
>>   _run()
>> File "/Users/zbir/Downloads/Zem.app/Contents/Resources/__boot__.py", line 311, in _run
>>   exec(compile(source, path, 'exec'), globals(), globals())
>> File "/Users/zbir/Downloads/Zem.app/Contents/Resources/ZemAppDelegate.py", line 12, in <module>
>>   from PyObjCTools import AppHelper
>> File "PyObjCTools/AppHelper.pyc", line 14, in <module>
>> File "AppKit/__init__.pyc", line 43, in <module>
>> File "AppKit/_AppKit.pyc", line 14, in <module>
>> File "AppKit/_AppKit.pyc", line 10, in __load
>> ImportError: dlopen(/Users/zbir/Downloads/Zem.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
>> Referenced from: /Users/zbir/Downloads/Zem.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
>> Expected in: /usr/lib/libobjc.A.dylib
>> in /Users/zbir/Downloads/Zem.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
>> 2013-05-09 13:54:37.926 Zem[347:707] Zem Error
> 
> It shouldn't make a difference whether or not you installed PyObjC, the app should always load the version of PyObjC that is in the bundle. 
> 
> What are the OSX versions of the machine where you build PyObjC and where you tried to start the application?  This might be a deployment target issue, that is a binary with a deployment target that is higher than the OS you try to run the app on.

I'm building Zem on 10.8.2, but I get the error on other 10.8.2 machines without PyObjC installed. The specific error I pasted earlier came from 10.7.5. What's the best way to declare deployment target in a totally script-driven py2app environment?

Thanks,

Zac

Re: [Pyobjc-dev] Problem running PyObjC/py2app app on machine without PyObjC installed

[Ronald O. <ron...@ma...>]

On 9 May, 2013, at 20:14, Zachery Bir <zb...@ur...> wrote:

> Hey, all. Long time no see.

Welcome back :-)

> 
> So, I've revived one of my PyObjC apps (Zem), but am running into problems getting the resulting app to launch on systems that don't already have PyObjC installed. This hasn't so far happened with my other PyObjC apps, so I'm wondering if I'm just doing something wrong.
> 
>  Here's a link to the py2app-built binary: http://swng.it/nP7QK
> 
>  Here's the code: https://github.com/orangutango/Zem/
> 
> I could tell that some things had changed in the PyObjC/py2app worlds since the last time I heavily used them.
> 
> I built this bundle the standard way:
> 
>  $ python setup.py py2app --iconfile Resources/Zem.icns
> 
> (Incidentally, I'm not sure why it doesn't pick up on my Info.plist entry for CFBundleIconFile, but whatever)

That is a bug, py2app should pick up CFBundleIconFile (although you should arrange for it to be copied into the
app bundle, which your setup.py file does).

> 
> The error I get on machines without PyObjC installed is:
> 
> Zacherys-Mac:~ zbir$ Downloads/Zem.app/Contents/MacOS/Zem 
> Traceback (most recent call last):
>  File "/Users/zbir/Downloads/Zem.app/Contents/Resources/__boot__.py", line 316, in <module>
>    _run()
>  File "/Users/zbir/Downloads/Zem.app/Contents/Resources/__boot__.py", line 311, in _run
>    exec(compile(source, path, 'exec'), globals(), globals())
>  File "/Users/zbir/Downloads/Zem.app/Contents/Resources/ZemAppDelegate.py", line 12, in <module>
>    from PyObjCTools import AppHelper
>  File "PyObjCTools/AppHelper.pyc", line 14, in <module>
>  File "AppKit/__init__.pyc", line 43, in <module>
>  File "AppKit/_AppKit.pyc", line 14, in <module>
>  File "AppKit/_AppKit.pyc", line 10, in __load
> ImportError: dlopen(/Users/zbir/Downloads/Zem.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
>  Referenced from: /Users/zbir/Downloads/Zem.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
>  Expected in: /usr/lib/libobjc.A.dylib
> in /Users/zbir/Downloads/Zem.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
> 2013-05-09 13:54:37.926 Zem[347:707] Zem Error

It shouldn't make a difference whether or not you installed PyObjC, the app should always load the version of PyObjC that is in the bundle. 

What are the OSX versions of the machine where you build PyObjC and where you tried to start the application?  This might be a deployment target issue, that is a binary with a deployment target that is higher than the OS you try to run the app on.

Ronald

> 
> Thanks,
> 
> Zac
> 
> 
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and 
> their applications. This 200-page book is written by three acclaimed 
> leaders in the field. The early access version is available now. 
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Problem running PyObjC/py2app app on machine without PyObjC installed

[Zachery B. <zb...@ur...>]

Hey, all. Long time no see.

So, I've revived one of my PyObjC apps (Zem), but am running into problems getting the resulting app to launch on systems that don't already have PyObjC installed. This hasn't so far happened with my other PyObjC apps, so I'm wondering if I'm just doing something wrong.

  Here's a link to the py2app-built binary: http://swng.it/nP7QK

  Here's the code: https://github.com/orangutango/Zem/

I could tell that some things had changed in the PyObjC/py2app worlds since the last time I heavily used them.

I built this bundle the standard way:

  $ python setup.py py2app --iconfile Resources/Zem.icns

(Incidentally, I'm not sure why it doesn't pick up on my Info.plist entry for CFBundleIconFile, but whatever)

The error I get on machines without PyObjC installed is:

Zacherys-Mac:~ zbir$ Downloads/Zem.app/Contents/MacOS/Zem 
Traceback (most recent call last):
  File "/Users/zbir/Downloads/Zem.app/Contents/Resources/__boot__.py", line 316, in <module>
    _run()
  File "/Users/zbir/Downloads/Zem.app/Contents/Resources/__boot__.py", line 311, in _run
    exec(compile(source, path, 'exec'), globals(), globals())
  File "/Users/zbir/Downloads/Zem.app/Contents/Resources/ZemAppDelegate.py", line 12, in <module>
    from PyObjCTools import AppHelper
  File "PyObjCTools/AppHelper.pyc", line 14, in <module>
  File "AppKit/__init__.pyc", line 43, in <module>
  File "AppKit/_AppKit.pyc", line 14, in <module>
  File "AppKit/_AppKit.pyc", line 10, in __load
ImportError: dlopen(/Users/zbir/Downloads/Zem.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so, 2): Symbol not found: _OBJC_CLASS_$_NSObject
  Referenced from: /Users/zbir/Downloads/Zem.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
  Expected in: /usr/lib/libobjc.A.dylib
 in /Users/zbir/Downloads/Zem.app/Contents/Resources/lib/python2.7/lib-dynload/AppKit/_AppKit.so
2013-05-09 13:54:37.926 Zem[347:707] Zem Error

Thanks,

Zac

[Pyobjc-dev] python to objective-c

[Stoleru A. <at...@gm...>]

Hi everyone

As the subject says: I need some help in converting a python library to native objective-c for iOS (I don't want to include the python library but really convert from python to objective-c).
Of course, based on the time required, your effort will be remunerated.

Thank you.

Re: [Pyobjc-dev] ANN: PyObjC 2.5.1

[Aahz <aa...@py...>]

On Tue, Jan 22, 2013, Ronald Oussoren wrote:
>
> I've just pushed PyObjC 2.5.1 to PyPI.  This is primarily a bugfix
> release, the list of changes since 2.4 (the last version on PyPI) is
> included below.

Huzzah!  Wow, that's a lot of stuff!
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote 
programs, then the first woodpecker that came along would destroy civilization.

[Pyobjc-dev] ANN: PyObjC 2.5.1

[Ronald O. <ron...@ma...>]

Hi,

I've just pushed PyObjC 2.5.1 to PyPI.  This is primarily a bugfix release, the list of changes since 2.4 (the last version on PyPI) is included below.

There will probably be a py2app bugfix later this week as well, I'm currently working on a bugfix that's holding up that release.

Ronald



Version 2.5.1
-------------

- PyObjC could crash when calling a method that is dynamicly generated
  (that is, the selector is not present in the class according to the 
  Objective-C runtime but the instance responds to it anyway). 

  The cases that used to crash now raise :exc:`objc.error` instead.

  .. note:: 

     It is highly unlikely that real code would run into this, found
     while working on PyObjC 3.x.

- When writing a python unicode object to an NSArchiver or NSKeyedArchiver
  the object is now stored exactly the same as a normal NSString, and will
  be read back as such.

  This increases interoperability with code that expects to read back a
  non-keyed archive in a different proces. An example of this is the use
  of Growl (see issue #31)

  Instances of subclasses of unicode are not affected by this change, and
  can only be read back by other PyObjC programs.

- Issue #43: It was no longer possible to create instances of
  LaunchServices.LSLaunchURLSpec due to incomplete metadata.

- Issue #41: the 'install.py' script in the root of pyobjc repository 
  failed to perform an install when running in a clean checkout of the tree.

- Issue #44: the various Cocoa frameworks only export @protocol defintions when
  they happen to be used by code in the framework. Added extensions to the
  various framework wrappers to ensure that all protocols are available to
  python code.

- Opaque pointer types now can be constructed with a "c_void_p" keyword  
  argument that contains a :type:`ctypes.c_void_p` value for the pointer.

  This is the reverse of the *__c_void_p__()* method that was added
  earlier.

- Issue #46: It was not possible to use the Quartz.CoreGraphics module
  on OSX 10.5 when the binary was build on 10.8 (and using a 10.5 deployment
  target).

  Simular issues may be present in some of the other framework wrappers,
  there will be a more generic fix for this issue in a future release.

Version 2.5
-----------

- Add conversion to/from ctypes.c_void_p to proxies for Cocoa objects.

  To use::

     anObject = NSArray.array()
     void_p = anObject.__c_void_p__()
     # use void_p with ctypes

     otherObject = NSObject(c_void_p=voip_p)
     assert anObject is otherObject

  Note that it is save to contruct the python proxy from NSObject,
  the class will return an instance of the correct proxy type (in this
  example an instance of NSArray)

- Fixed problem where the result of ``anObject.__cobject__()`` could not be converted
  back to a PyObjC object again.

- A number of framework wrappers have a "protocols" submodule containing
  protocol objects (for example the module 'Foundation.protocol'). Use
  of these modules is deprecated, they will be removed in PyObjC 3.0.

  Use :func:`objc.protocolNamed` to access protocols instead.

- Instances of :class:`objc.ivar` now have slots for introspection:

  - *__typestr__*: The type encoding

  - *__name__*: The Objective-C name

  - *__isOutlet__*: :data:`True` if the instance variable is an IBOutlet

  - *__isSlot__*: :data:`True` if the instance variable is a Python slot

- Added implementation of '==' and '!=' for selectors defined in Python
  that is slightly smarter than the default (identity based) implementation
  in Python. 

  This is mostly done for the PyObjC unittests and shouldn't affect user
  code.

- Issue #30: Explicitly check if the compiler works, and try to
  fall back to clang if it doesn't. This uses a simular algoritm as
  the fix for <http://bugs.python.org/issue13590> in Python's tracker.

- Issue #22: Reimplement support for bridgesupport files

  This reintroduces ``objc.parseBridgeSupport`` and 
  ``objc.initFrameworkWrapper``, both are reimplemented in Python 
  (previous version used C code)

  .. note::

     The implementation is currently barely tested and therefore likely
     contains bugs.

- Struct types created by the framework wrappers once again create class
  methods on :class:`objc.ivar` to generate instance variables of that type::

     myLocation = objc.ivar.NSPoint()

  This has the same result as::

    myLocation = objc.ivar(typer=NSPoint.__typestr__)

- :func:`objc.IBAction` now raises TypeError when the argument is :data:`None`.

- :func:`objc.instancemethod` is now actually exported by the :mod:`objc` package.

- :func:`objc.accessor` and :func:`objc.typedAccessor` were not 64-bit safe.

- :func:`objc.accessor` and :func:`objc.typedAccessor` didn't support the entire
  set of KVC accessors.

- Add methods "_asdict" and "_replace" and field "_fields" to the struct wrapper
  types. These new attributes mirror the :class:`collections.namedtuple` interface.

  .. note::

     In the long run I'd like to make struct wrappers immutable to allow using
     them as dictionary keys. This is a first step in that direction and makes
     it possible to verify that immutable struct wrappers are useable.

- Added :func:`objc.createStructAlias`, and deprecated 
  :func:`objc.registerStructAlias`. The new function has a "name" argument
  and can register types with the :class:`objc.ivar` type (see previous item)

- Add explicit deprecation warnings to ``objc.CFToObject`` and
  ``objc.ObjectToCF``. Both functions barely function at all and will
  be removed with PyObjC 3.0.

- ``objc.CFToObject`` and ``objc.ObjectToCF`` are no longer available
  when using Python 3.x, the APIs are used for MacPython support and
  that part of the standard library is not available with Python 3.x.

- ``objc.splitStruct`` is renamed to ``objc.splitStructSignature`` 
  and now actually works. The old name is temporarily available as
  an alias.

- Fix refcounting leak in ``objc.splitSignature``.

- ``objc._loadFunctionList`` is renamed to ``objc.loadFunctionList``
  and is fully documented. The old name is temporarily available as
  an alias.

- Move (deprected) decorator "signature" from objc._functions to objc._descriptors,
  and remove the former module.

  .. note:: 
     The names op submodules of objc are implementation details, don't import
     them directly.

- The optional argument for the decorator :func:`objc.selectorFor` was broken

- The :class:`PyObjCTools.KeyValueCoding.kvc` wrapper `__setattr__` wrapper 
  incorrectly set attributes on itself as well as on the wrapped object (the latter
  using Key-Value Coding)

- Renamed (private) function injectSuffixes to inject_suffixes to match the
  other code in objc._dyld.

- Slight restructuring of objc._pythonify to reduce code duplication between the
  python 2.x and python 3.x cases. 

- Removed deprecated methods from PyObjCTools.TestSupport

- :class:`collections.Sequence` objects are now automaticly proxied as NSArray 
  instances

- :class:`collections.Mapping` objects are now automaticly proxies as NSDictionary
  instances

- Removed some objects and functions from objc._bridges that weren't public
  and weren't used by PyObjC itself:

  - *BRIDGED_STRUCTURES*: mapping of python type to proxy class
  - *BRIDGED_STRUCTURES2*: mapping of python type to proxy class (not used at all)
  - *BRIDGED_TYPES*: mapping of python type to proxy class
  - *_bridgePythonTypes*: uses BRIDGED_STRUCTURES and BRIDGED_TYPES to update bridge data

  *_bridgePythonTypes* was called unconditionally, but never did anything because
  the data structures were empty and no code adds anything to them.

- Improved documentation

- For Objective-C blocks: try to extract the block signature from the (Objective-)C runtime
  when there is no metadata for the block. The block signature is available only when the
  code that creates the block is compiled using a recent enough compiler (although "recent
  enough" is fairly old by now)

- Fixes some issues with :class:`objc.object_property` which were found by
  improved unittests. In particular:

  - The selector names for boolean properties were wrong

  - Properties with a "depends_on" list didn't inherit properly

  - Properties that were used in subclasses didn't generate the correct KVO 
    events when they were observed.

  - KVO issues with computed (read-only) properties

- Fixed some issues with :class:`objc.array_property` and :class:`objc.set_property`
  that were found by much improved unittests.

- Fixed issues with :mod:`PyObjCTools.KeyValueCoding` that were found by improved
  unittests:

  - ``getKey`` didn't work propertly on dictionaries (dictionaries were treated as sequences)

  - ``getKeyPath(list, "@avg.field")`` didn't work when field wasn't a valid key for all
     items in the list, and likewise for the '@sum', '@min', '@max' special keys.

  - ``getKeyPath`` didn't raise the correct exception for empty key paths

  - ``@unionOfObjects`` and ``@distinctUnionOfObjects`` operators for Python sequences
    didn't raise an exception when the selected keypath didn't exist on an item of the sequence.

  - ``@unionOfArrays`` and ``@distinctUnionOfArrays`` operators for Python sequences
    didn't raise an exception when the selected keypath didn't exist on an item of the sequence.

  - ``@distinctUnionOfArrays`` and ``@distinctUnionOfObjects`` didn't work properly when
     the keypath pointed to objects that weren't hashable.

  - ``@distinctUnionOfSets`` operator was not present at all. 

- 'PyObjCTools.KeyValueCoding.setKey' now sets keys in dictionaries, that is::

     >>> a = {}
     >>> setKey(a, 'foo', 42)
     >>> a
     {'foo': 42 }

- 'PyObjCTools.KeyValueCoding.setKey(object, 'key', value)' now sets attribute 'key' when
  the object already has that attribute, before looking at '_key'. This avoids that ``setKey``
  changes the underlying storage for a common Python property pattern::

      class Record (object):
         @property 
	 def prop(self):
	     return self._prop

	 @prop.setter
	 def prop(self, value):
	     self._prop = calculate_using(value)

  Until PyObjC 2.5 the property setter for 'prop' would not be called when using KeyValueCoding.

- Removed Mac OS X 10.2 (!) compatibility from :mod:`PyObjCTools.KeyValueCoding`.

- PyObjCTools.KeyValueCoding has undocumented attributes 'ArrayOperators' and 'arrayOperators',
  both will be removed in a future release.

- Using NSArchiver or NSKeyedArchiver to encode and then decode a python list or tuple could
  result in an unexpected value. In particular, if any element of the sequence was :data:`None`
  before archiving it would by ``NSNull.null()`` when read back.

- Using NSArchiver or NSKeyedArchiver to encode and decode (pure) python objects didn't always
  work correctly. Found by improved unittests.

- Using NSArchiver or NSKeyedArchiver to encode and decode bytes objects in Python 3 would
  result in an instance of NSData instead of bytes.

- The implementation of cmp() for NSSet instances now matches the behavior of regular python
  sets, that is calling ``cmp(anNSSet, aValue)`` will raise a TypeError exception unless
  both arguments are the same object (``anNSSet is aValue``).

- Issue #36: explictly document that PyObjC does not support the Objective-C Garbage Collection
  system (introduced in OSX 10.5, deprecated in OSX 10.8), and also mention this in the
  documentation for the screen saver framework because the screen saver engine uses GC on 
  OSX 10.6 and 10.7.

- Issue #37: Fix runtime link error with EPD (Enthought Python Distribution),
  which doesn't include the pymactoolbox functionality.

- Various improvements to the documentation

Version 2.4.1
-------------

.. note:: 2.41 was never released, all bugfixes are in the 2.4 branch as well as the 2.5 release.

- Cocoa wrappers: fix metadata for ``copy``, ``mutableCopy``, 
  ``copyWithZone:`` and ``mutableCopyWithZone:``

- Fix for issue 3585235 on SourceForge: the threading helper category on
  NSObject didn't work due to a typo (defined in the Cocoa bindings)

  Fix is based on a patch by "Kentzo" with further updates and tests by
  Ronald.

- Rename ReadMe.txt to README.txt to work around misfeature in the 
  sdist command in distutils.

- Issue #28: Avoid crash when using CGEventTabProxy values.

- Issue #33: "easy_install pyobjc" no longer tries to install the
  InterfaceBuilderKit bindings on OSX 10.7 or later.

Re: [Pyobjc-dev] Integrating py2app with Xcode

[Ronald O. <ron...@ma...>]

On 13 Jan, 2013, at 0:13, Frank Illenberger <ill...@me...> wrote:

> Hi folks,
> 
> I always have been using py2app directly from the command line for building plugin bundles which get loaded into Cocoa apps. Does anybody know if it is possible to integrate this manual process into Xcode so that I can use it as an IDE for the development of these plugins? I know the Xcode target template for external build systems, but with it I would still have to edit the data_files entries in the setup.py file myself. 
> Thanks for any hints.

The external build system option would be the best option for now.  

The pyobjc repository contains some xcode templates (at <https://bitbucket.org/ronaldoussoren/pyobjc/src/be79abf0d8ae649292f66cdae40f67b2b6bb89f5/pyobjc-xcode?at=default>), but those haven't been updated for a while and don't use py2app. 

In the longer run I'd like to create Xcode templates that use py2app, and extend py2app to either optionally read some information from the Xcode project file, or run in a mode where Xcode controls the build and py2app "just" adds the files needed to make the build a standalone build (that is, copy dependencies into the bundle).   I don't know when I'll get around to doing that though.

Ronald

Re: [Pyobjc-dev] py2app not picking up additional .py files

[Ronald O. <ron...@ma...>]

On 13 Jan, 2013, at 1:49, Frank Illenberger <ill...@me...> wrote:

> Hi there,
> 
> I am developing a plugin with py2app using the following setup.py file:
> 
> from setuptools import setup
> 
> plist = {
>     'NSPrincipalClass':'MyClass',
>     'CFBundleName':'MyPlugin',
>     'CFBundleIdentifier':'net.test',
>     'CFBundleGetInfoString':'MyPlugin 0.1',
>     'CFBundleVersion':'0.1',
>     'CFBundleShortVersionString':'0.1',
> }
> 
> setup(
>     name = "MyPlugin",
>     plugin = ["MyClass.py"],
>     data_files=[],
>     setup_requires=["py2app"],
>     options=dict(py2app=dict(extension='.myPlugin', plist=plist)),
> )
> 
> 
> 
> 
> The MyClass.py file looks like this:
> 
> import objc
> from Foundation import *
> import MyClass2
> 
> class MyClass(NSObject):
> 
>     def init(self):
>         self = super(MyClass, self).init()
>         print "I am a python object"
>         return self
> 
> 
> 
> The compiled bundle contains the MyClass.py file but not the other python file "MyClass2.py" that resides in the same source directory although I explictly import it.

Does the import work when you load the plugin bundle?  Py2app currently stores the main python file as is in the resource folder, all other sources are stored in a site-packages.zip archive. A future version of py2app might store the main python file there as well. 

> 
> Do I have to explicitly name all files in the setup.py?

No.

Ronald

[Pyobjc-dev] py2app not picking up additional .py files

[Frank I. <ill...@me...>]

Hi there,

I am developing a plugin with py2app using the following setup.py file:

from setuptools import setup

plist = {
    'NSPrincipalClass':'MyClass',
    'CFBundleName':'MyPlugin',
    'CFBundleIdentifier':'net.test',
    'CFBundleGetInfoString':'MyPlugin 0.1',
    'CFBundleVersion':'0.1',
    'CFBundleShortVersionString':'0.1',
}

setup(
    name = "MyPlugin",
    plugin = ["MyClass.py"],
    data_files=[],
    setup_requires=["py2app"],
    options=dict(py2app=dict(extension='.myPlugin', plist=plist)),
)




The MyClass.py file looks like this:

import objc
from Foundation import *
import MyClass2

class MyClass(NSObject):

    def init(self):
        self = super(MyClass, self).init()
        print "I am a python object"
        return self



The compiled bundle contains the MyClass.py file but not the other python file "MyClass2.py" that resides in the same source directory although I explictly import it.

Do I have to explicitly name all files in the setup.py?

Thanks for your help.

Cheers

Frank

[Pyobjc-dev] Integrating py2app with Xcode

[Frank I. <ill...@me...>]

Hi folks,

I always have been using py2app directly from the command line for building plugin bundles which get loaded into Cocoa apps. Does anybody know if it is possible to integrate this manual process into Xcode so that I can use it as an IDE for the development of these plugins? I know the Xcode target template for external build systems, but with it I would still have to edit the data_files entries in the setup.py file myself. 
Thanks for any hints.

Cheers

Frank

Re: [Pyobjc-dev] PyObjC 2.5 release

[Diez B. R. <de...@we...>]

On Jan 7, 2013, at 4:31 PM, Ronald Oussoren wrote:

> Hi,
> 
> I've tagged pyobjc 2.5 in my bitbucket repository, but haven't uploaded it to PyPI yet (and haven't updated the website either). I'll finish the release proces later this week or next weekend.
> 
> The most important changes w.r.t. 2.4:
> 
> * Reinstated support for .bridgesupport files (PyObjC no longer uses them itself, but these files can be handy to access other frameworks)
> 
> * Much improved test coverage, which has resulted in numerous small bugfixes.

Woot!

[Pyobjc-dev] PyObjC 2.5 release

[Ronald O. <ron...@ma...>]

Hi,

I've tagged pyobjc 2.5 in my bitbucket repository, but haven't uploaded it to PyPI yet (and haven't updated the website either). I'll finish the release proces later this week or next weekend.

The most important changes w.r.t. 2.4:

* Reinstated support for .bridgesupport files (PyObjC no longer uses them itself, but these files can be handy to access other frameworks)

* Much improved test coverage, which has resulted in numerous small bugfixes.

Ronald

[Pyobjc-dev] pyobjc status and future

[Ronald O. <ron...@ma...>]

Hi,

Early november I finally got a new release of PyObjC out (version 2.4), and unless an unexpected problem crops up there will be another release (2.5) next Sunday. Version 2.5 will re-add some functionality that accidently got dropped in the 2.4 release (in particular the support for BridgeSupport files), and improves testing (which led to a number of bugfixes).

I've also migrated the website to http://packages.python.org/pyobjc, the old URL (http://pyobjc.sf.net/) is now just a redirect to the new location. The website is once again generated from the PyObjC source tree, the old one hadn't been updated in a long while because the scripts generating that site didn't work anymore due to restructuring of the pyobjc repository and documentation files.   I'd like to replace the current sphinx theme by something less generic, and that should happen sometime next year.    The same is true for the examples: that code needs to be cleaned up and updated.

I'll try to get on a more regular release pattern next year, with some luck leading up to a 3.0 release during the summer. That release would then feature a cleaned up core bridge, removing some cruft that was needed to support Python release before 2.6 and that cleanup should improve the performance of all of PyObjC.   The major stumbling block w.r.t. getting to 3.0 is time: I know what I want to do and how to get there, but expect to need a couple of days to work on this; my regular development pattern of doing a couple of hours development during the evening or in the weekend will probably be too inefficient to make serious progres.

Before 3.0 is out there should be at least a 2.6 release, and possibly other point releases, with improved framework coverage (not all system frameworks are available through PyObjC at the moment), other minor feature updates and bugfixes.

One thing I'm not sure about is Xcode support, in particular support for designing GUI using the Interface Builder tool embedded in Xcode. I don't like Xcode as a Python editor (which is why the xcode templates are basicly dead at the moment), and haven't made my mind up on how to proceed here.   Two major options are to either generate an Xcode project when needed (just to enough to let Xcode know where to find resource files and source code), and to just ignore Xcode completely but design the UI in Xcode.  That last option should be a lot easier with autolayout (introduced in OSX 10.7), but might need a helper library to keep code readable (I've noticed with other toolkits that it is very easy to end up with long blocks of code that create UI elements and have no useful structure).

Happy holidays,

   Ronald

Re: [Pyobjc-dev] sys.excepthook and AppHelper.runEventLoop

[Ronald O. <ron...@ma...>]

On 20 Nov, 2012, at 3:11, Ben Smith <bcs...@gm...> wrote:

> Benjamin Smith <bcsmith05 <at> gmail.com> writes:
> 
>> 
>> Hi all,
>> 
>> I have a python script that I'm bundling with py2app and run using
> AppHelper.runEventLoop.  In my script, I
>> set sys.excepthook to a custom function in order to do some cleanup when there
> is an unhandled exception. 
>> However, because runEventLoop runs the entire runloop inside a try, except
> block, sys.excepthook is
>> never called and the application simply terminates.  It looks like the only
> way to mimic this behavior is to
>> pass in my cleanup code within the 'unexpectedErrorAlert' parameter to
> runEventLoop, but that seemed to
>> not be the best approach.  Is there another way to mimic sys.excepthook that
> I'm missing?
>> 
>> Thanks!
>> Ben
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> 
> 
> Hi again,
> 
> It looks like my understanding earlier was not correct.  The problem was
> unrelated to runEventLoop's try/catch blocks, but rather seemed to be related to
> the fact that my exception was being raised in code that was fired off from
> applicationDidFinishLaunching.  It seems that when python code raises an
> exception within a method called from the run loop, the exception is handled by
> the run loop (generating an objective C exception) and so never reaches the
> python unhandled exception handler.

The Objective-C exception should be converted to a Python one by the bridge,
unless the runloop swallows the exception (and it does that at least for some
exceptions).

> 
> The first thing we tried was to use NSSetUncaughtExceptionHandler to catch the
> objective-C exceptions, but it seems like that function is not implemented.  So
> now what we're going with is to write a decorator to wrap methods that could be
> called from the run loop in try, except, and then on the except, route the
> exception to our sys.excepthook function.  Does that sound reasonable?

That's the best solution. In general Apple's code doesn't like exceptions at all,
throwing exceptions through an Objective-C callstack could result in resource
leaks and other misbehavior. That's because Apple tends to use exceptions only
to signal programmer errors, "normal" errors are usually signalled using return
values and/or NSError values.

You could also call "objc.setVerbose(1)". After that call PyObjC will print exceptions
when converting them to/from Objective-C. 

Ronald
> 
> Thanks a bunch!
> Ben
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev