pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] [ pyobjc-Bugs-1827746 ] repr(kCFAllocatorUseContext) crashes

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

On 7 Nov, 2007, at 19:21, Ben Artin wrote:

> I filed this bug, but I was accidentally anonymous when I did so.
>
> The circuitous path that got me into this mess is that
> twisted.failure.Failure records exception backtraces, including all
> locals and globals in each frame. When constructing a Failure whose
> stack includes a function in a module that globally imported
> kCFAllocatorUseContext, twisted crashes trying to repr() globals in
> that frame.
>
> PyObjCTools/AppHelper.py has a "from Foundation import *", which means
> that anyone using AppHelper.py and twisted dies as soon as they fail()
> from under AppHelper. Ouch.

Ouch indeed. That constant is a magic pointer in ObjC (or rather plain  
C), appearently I missed a location where I should treat is specially.

Ronald

>
>
> Ben
>
> --
>
> <http://artins.org/ben>
>
> "Computers! All they ever think of is hex!"
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] [ pyobjc-Bugs-1827746 ] repr(kCFAllocatorUseContext) crashes

[Ben A. <be...@ar...>]

I filed this bug, but I was accidentally anonymous when I did so.

The circuitous path that got me into this mess is that  
twisted.failure.Failure records exception backtraces, including all  
locals and globals in each frame. When constructing a Failure whose  
stack includes a function in a module that globally imported  
kCFAllocatorUseContext, twisted crashes trying to repr() globals in  
that frame.

PyObjCTools/AppHelper.py has a "from Foundation import *", which means  
that anyone using AppHelper.py and twisted dies as soon as they fail()  
from under AppHelper. Ouch.

Ben

--

<http://artins.org/ben>

"Computers! All they ever think of is hex!"

[Pyobjc-dev] [ pyobjc-Bugs-1827746 ] repr(kCFAllocatorUseContext) crashes

[SourceForge.net <no...@so...>]

Bugs item #1827746, was opened at 2007-11-07 09:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1827746&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: repr(kCFAllocatorUseContext) crashes

Initial Comment:
/usr/bin/python
Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from CoreFoundation import kCFAllocatorUseContext
>>> repr(kCFAllocatorUseContext)
Trace/BPT trap




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1827746&group_id=14534

Re: [Pyobjc-dev] custom IB classes

[Phil C. <ph...@bu...>]

On Nov 7, 2007, at 12:47 PM, Bill Bumgarner wrote:
> On Nov 7, 2007, at 7:21 AM, Phil Christensen wrote:
>>    class ProfileListController:
>
> Make that...
>
> class ProfileListController(NSObject):
> 	...
>
> ... and try again.   There is quite a bit of functionality  
> implemented on NSObject that is not inherently a part of Objective-C  
> and, as a result, is not auto-bridged to Python (since, in the rare  
> case one exists, a different root Obj-C class would not necessarily  
> want all of the behavior).

Aha! That did the trick.

Thanks again,

-phil

[Pyobjc-dev] [ pyobjc-Bugs-1827735 ] CFShow(NSMessageBuilder) crashes

[SourceForge.net <no...@so...>]

Bugs item #1827735, was opened at 2007-11-07 09:50
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1827735&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: CFShow(NSMessageBuilder) crashes

Initial Comment:
/usr/bin/python
Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from CoreFoundation import CFShow
>>> from Foundation import NSMessageBuilder
>>> CFShow(NSMessageBuilder)
2007-11-07 12:42:13.265 Python[7004:613] *** NSInvocation: warning: object 0x0 of class 'nil' does not implement methodSignatureForSelector: -- trouble ahead
2007-11-07 12:42:13.267 Python[7004:613] *** NSInvocation: warning: object 0x0 of class 'nil' does not implement doesNotRecognizeSelector: -- abort
Trace/BPT trap



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=1827735&group_id=14534

Re: [Pyobjc-dev] custom IB classes

[Bill B. <bb...@ma...>]

On Nov 7, 2007, at 7:21 AM, Phil Christensen wrote:
>     class ProfileListController:

Make that...

class ProfileListController(NSObject):
	...

... and try again.   There is quite a bit of functionality implemented  
on NSObject that is not inherently a part of Objective-C and, as a  
result, is not auto-bridged to Python (since, in the rare case one  
exists, a different root Obj-C class would not necessarily want all of  
the behavior).

b.bum

Re: [Pyobjc-dev] custom IB classes

[Phil C. <ph...@bu...>]

On Nov 7, 2007, at 12:37 AM, Ronald Oussoren wrote:
> On 6 Nov, 2007, at 22:24, Phil Christensen wrote:
>> On Nov 6, 2007, at 4:16 PM, Ronald Oussoren wrote:
>>> On 6 Nov, 2007, at 22:08, Phil Christensen wrote:
>>>> However, when I launch the app, this happens during runtime:
>>>>
[wrong traceback removed]
>>>
>>> You have to import the source file somewhere, otherwise you're code
>>> won't get loaded.
>>
>> I thought so, here's my main.py:
>>
>>
>> #import modules required by application
>> import objc
>> import Foundation
>> import AppKit
>>
>> from PyObjCTools import AppHelper
>>
>> # import modules containing classes required to start application and
>> load MainMenu.nib
>> import ClarityAppDelegate
>> import ProfileListController
>>
>> # pass control to AppKit
>> AppHelper.runEventLoop()
>>
>>
>> Do I need to import the class itself?
>
> You just have to import the module that defines the class. Which  
> module defines ServiceListController?

Sorry, the first traceback was from a sample minimal program I put  
together to make sure I hadn't screwed something else up. The code is  
from my actual program, still very minimal, but with a more  
developed .xib.

I added this line just before the call to runEventLoop():

	Foundation.NSLog(str(ProfileListController))

Here's the new traceback:


11/7/07 10:07:09 AM Clarity[4002] <module 'ProfileListController' from  
'/Users/phil/Workspace/Clarity/build/Release/Clarity.app/Contents/ 
Resources/ProfileListController.pyc'>
11/7/07 10:07:09 AM Clarity[4002] Unknown class  
`ProfileListController' in nib file, using `NSObject' instead.
11/7/07 10:07:09 AM Clarity[4002] Could not connect the action  
addProfile: to target of class NSObject
11/7/07 10:07:09 AM Clarity[4002] Could not connect the action  
removeProfile: to target of class NSObject
11/7/07 10:07:09 AM Clarity[4002] *** -[_NSControllerObjectProxy  
copyWithZone:]: unrecognized selector sent to instance 0x1f29330


It definitely appears that the module is loaded. The IB class is  
extremely simple:


     from Foundation import *
     from AppKit import *
     import objc

     class ProfileListController:
         profileArrayController = objc.IBOutlet()

         @objc.IBAction
         def addProfile_(self, sender):
             pass

         @objc.IBAction
         def removeProfile_(self, sender):
             pass


Thanks again for any help...

-phil

Re: [Pyobjc-dev] playing nice with Objective-C @synchronized

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

On 7 Nov, 2007, at 2:41, Barry Wark wrote:

> Ronald,
>
> I had forgotten there was an API already. I incorrectly remembered
> that it was implemented in NSObject. I think a contextmanager wrapper
> is an ideal solution. Let me know how/if I can help.

The attached module 'objc_sync' is a quick&dirty wrapper for the  
synchronization facilty in the objc runtime. It is of the "it compiles  
hence must be correct" variaty, that is it is completely untested.

It defines the functions in the <objc/objc-sync.h> header as well as a  
contextmanager that allows you to use a with statement for locking.  
Such as:

  obj = <some NSObject instance>
with objc_sync.synchronized(obj):
     pass # Do something with lock held

There are four things that need to be done next, although the code  
should be perfectly functional as it is:

1) Add proper error-handling, the code currently ignores the return  
code of API functions

2) Verify that this indeed interacts with @synchronized statements

3) Write unittests for the contextmanager

4) Integrate into pyobjc-core

I'll probably also release this as a seperate module to make it  
possible to use this functionality without installing a new version of  
pyobjc-core.

Ronald

Re: [Pyobjc-dev] custom IB classes

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

On 6 Nov, 2007, at 22:24, Phil Christensen wrote:

>
> On Nov 6, 2007, at 4:16 PM, Ronald Oussoren wrote:
>> On 6 Nov, 2007, at 22:08, Phil Christensen wrote:
>>> However, when I launch the app, this happens during runtime:
>>>
>>>
>>> 11/6/07 3:57:02 PM Clarity[3508] Unknown class
>>> `ServiceListController'
>>> in nib file, using `NSObject' instead.
>>> 11/6/07 3:57:02 PM Clarity[3508] Could not connect the action
>>> addService: to target of class NSObject
>>> 11/6/07 3:57:02 PM Clarity[3508] Could not connect the action
>>> removeService: to target of class NSObject
>>> 11/6/07 3:57:02 PM Clarity[3508] *** -[_NSControllerObjectProxy
>>> copyWithZone:]: unrecognized selector sent to instance 0x1f179d0
>>> 11/6/07 3:57:05 PM Clarity[3508] An exception has occured:
>>>
>>>
>>> I'm sure there's something obvious I'm missing, but any help would  
>>> be
>>> greatly appreciated...
>>
>> You have to import the source file somewhere, otherwise you're code
>> won't get loaded.
>
> I thought so, here's my main.py:
>
>
> #import modules required by application
> import objc
> import Foundation
> import AppKit
>
> from PyObjCTools import AppHelper
>
> # import modules containing classes required to start application and
> load MainMenu.nib
> import ClarityAppDelegate
> import ProfileListController
>
> # pass control to AppKit
> AppHelper.runEventLoop()
>
>
> Do I need to import the class itself?

You just have to import the module that defines the class. Which  
module defines ServiceListController?

Ronald

Re: [Pyobjc-dev] custom IB classes

[Phil C. <ph...@bu...>]

On Nov 6, 2007, at 4:16 PM, Ronald Oussoren wrote:
> On 6 Nov, 2007, at 22:08, Phil Christensen wrote:
>> However, when I launch the app, this happens during runtime:
>>
>>
>> 11/6/07 3:57:02 PM Clarity[3508] Unknown class  
>> `ServiceListController'
>> in nib file, using `NSObject' instead.
>> 11/6/07 3:57:02 PM Clarity[3508] Could not connect the action
>> addService: to target of class NSObject
>> 11/6/07 3:57:02 PM Clarity[3508] Could not connect the action
>> removeService: to target of class NSObject
>> 11/6/07 3:57:02 PM Clarity[3508] *** -[_NSControllerObjectProxy
>> copyWithZone:]: unrecognized selector sent to instance 0x1f179d0
>> 11/6/07 3:57:05 PM Clarity[3508] An exception has occured:
>>
>>
>> I'm sure there's something obvious I'm missing, but any help would be
>> greatly appreciated...
>
> You have to import the source file somewhere, otherwise you're code  
> won't get loaded.

I thought so, here's my main.py:


#import modules required by application
import objc
import Foundation
import AppKit

from PyObjCTools import AppHelper

# import modules containing classes required to start application and  
load MainMenu.nib
import ClarityAppDelegate
import ProfileListController

# pass control to AppKit
AppHelper.runEventLoop()


Do I need to import the class itself?

Thanks again,

-phil

Re: [Pyobjc-dev] custom IB classes

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

On 6 Nov, 2007, at 22:08, Phil Christensen wrote:

> Hello all,
>
> It's been awhile since I tried PyObjC, but my new installation of
> Leopard has prompted me to try it again.
>
> The problem I'm having is that I can't seem to get my custom classes
> created in Interface Builder to be "seen" when my app is built/ 
> executed.
>
> The steps I've followed are as follows:
>
> 1.) In XCode, I created a "Cocoa-Python Application"
> 2.) After opening up the xib file, I dragged an NSObject instance to
> my xib
> 3.) In the attribute palette, I set the class identity to
> 'ServiceListController'
> 4.) Create outlets and actions, and link them up
> 5.) Select the ServiceListController instance in IB and choose "Write
> class files"
> 6.) Add the created .py file to my XCode project
>
> However, when I launch the app, this happens during runtime:
>
>
> 11/6/07 3:57:02 PM Clarity[3508] Unknown class `ServiceListController'
> in nib file, using `NSObject' instead.
> 11/6/07 3:57:02 PM Clarity[3508] Could not connect the action
> addService: to target of class NSObject
> 11/6/07 3:57:02 PM Clarity[3508] Could not connect the action
> removeService: to target of class NSObject
> 11/6/07 3:57:02 PM Clarity[3508] *** -[_NSControllerObjectProxy
> copyWithZone:]: unrecognized selector sent to instance 0x1f179d0
> 11/6/07 3:57:05 PM Clarity[3508] An exception has occured:
>
>
> I'm sure there's something obvious I'm missing, but any help would be
> greatly appreciated...

You have to import the source file somewhere, otherwise you're code  
won't get loaded.

Ronald

[Pyobjc-dev] custom IB classes

[Phil C. <ph...@bu...>]

Hello all,

It's been awhile since I tried PyObjC, but my new installation of  
Leopard has prompted me to try it again.

The problem I'm having is that I can't seem to get my custom classes  
created in Interface Builder to be "seen" when my app is built/executed.

The steps I've followed are as follows:

1.) In XCode, I created a "Cocoa-Python Application"
2.) After opening up the xib file, I dragged an NSObject instance to  
my xib
3.) In the attribute palette, I set the class identity to  
'ServiceListController'
4.) Create outlets and actions, and link them up
5.) Select the ServiceListController instance in IB and choose "Write  
class files"
6.) Add the created .py file to my XCode project

However, when I launch the app, this happens during runtime:


11/6/07 3:57:02 PM Clarity[3508] Unknown class `ServiceListController'  
in nib file, using `NSObject' instead.
11/6/07 3:57:02 PM Clarity[3508] Could not connect the action  
addService: to target of class NSObject
11/6/07 3:57:02 PM Clarity[3508] Could not connect the action  
removeService: to target of class NSObject
11/6/07 3:57:02 PM Clarity[3508] *** -[_NSControllerObjectProxy  
copyWithZone:]: unrecognized selector sent to instance 0x1f179d0
11/6/07 3:57:05 PM Clarity[3508] An exception has occured:


I'm sure there's something obvious I'm missing, but any help would be  
greatly appreciated...

-phil

Re: [Pyobjc-dev] playing nice with Objective-C @synchronized

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

On 6 Nov, 2007, at 19:53, Ronald Oussoren wrote:
>>
>>
>> Any pointers appreciated.
>
> That is not possible with the current version of pyobjc.  Trying to  
> make this possible is on my todo list, but I haven't found a public   
> interface yet that would make it possible to implement this.

It turns out that I didn't look closely enough. There is a header file  
in /usr/include/objc that describes the API that's used to implement  
the @synchronized statement. Creating a nice python wrapper for that  
(and I'm thinking about a contextmanager for that[1]) should be easy  
enough.

The hardest part will be the creation of a good unittest for this  
feature.

Ronald

[1] http://www.python.org/dev/peps/pep-0343/
>
>
> Ronald
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] playing nice with Objective-C @synchronized

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

On 6 Nov, 2007, at 18:05, Barry Wark wrote:

> Is it possible to use the mutex created by the Objective-C
> @synchronized statement from with in PyObjC? I haven't been Here's the
> use case I have in mind: I have an NSObject subclass created in
> python. I would like to be able to synchronize access to a block from
> within python like
> self._mutex_.lock()
> try:
>    #special code here
> finally:
>   self._mutex_.unlock()
>
> where self._mutex_ is the mutex created for the for the Objective-C
> @synchronized(self) statement. IIRC, this mutex is created only when a
> @synchronized statment is used, so I suppose I need to be able to
> create this mutex from Python as well.
>
> Any pointers appreciated.

That is not possible with the current version of pyobjc.  Trying to  
make this possible is on my todo list, but I haven't found a public   
interface yet that would make it possible to implement this.

Ronald

Re: [Pyobjc-dev] Problem with alias build on Leopard

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

On 6 Nov, 2007, at 15:21, Luc Heinrich wrote:

> On 5 nov. 07, at 15:27, Luc Heinrich wrote:
>
>> So it really seems that *some* alias builds do have a problem.
>
> More data: the problem seems to be related to importing the Quartz
> framework *before* doing an AppHelper.runEventLoop or an
> NSApplication.sharedApplication or any other code which connects to
> the window server, in alias builds *only*.
>
> Seems like a PyObjC/py2app bug to me. No ?

Maybe, maybe not.  This feels like the "feature" that forced us to  
introduce a "pythonw" command: normal command-line utilities aren't  
allowed to make connections to the window server.  It looks like alias  
builds are now not good enough anymore and I don't know if that is  
intended behaviour.

That said, I will try to tweak py2app to make alias builds work again.

Ronald
>
>
> -- 
> Luc Heinrich
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] playing nice with Objective-C @synchronized

[Barry W. <bar...@gm...>]

Is it possible to use the mutex created by the Objective-C
@synchronized statement from with in PyObjC? I haven't been Here's the
use case I have in mind: I have an NSObject subclass created in
python. I would like to be able to synchronize access to a block from
within python like
self._mutex_.lock()
try:
    #special code here
finally:
   self._mutex_.unlock()

where self._mutex_ is the mutex created for the for the Objective-C
@synchronized(self) statement. IIRC, this mutex is created only when a
@synchronized statment is used, so I suppose I need to be able to
create this mutex from Python as well.

Any pointers appreciated.

Barry

Re: [Pyobjc-dev] Problem with alias build on Leopard

[Luc H. <lu...@ho...>]

On 5 nov. 07, at 15:27, Luc Heinrich wrote:

> So it really seems that *some* alias builds do have a problem.

More data: the problem seems to be related to importing the Quartz  
framework *before* doing an AppHelper.runEventLoop or an  
NSApplication.sharedApplication or any other code which connects to  
the window server, in alias builds *only*.

Seems like a PyObjC/py2app bug to me. No ?

-- 
Luc Heinrich

Re: [Pyobjc-dev] Changes to +initialize() / super behavior in PyObjC 2.0?

[James R E. <ea...@ba...>]

On Nov 5, 2007, at 11:31 , Bill Bumgarner wrote:

> On Nov 5, 2007, at 7:34 AM, James R Eagan wrote:
>> It appears that in previous versions of PyObjC, one could refer to a
>> superclass via super within the initialize classmethod, but in PyObjC
>> 2.0, the class does not seem to exist yet (or, at least, the
>> objc.super proxy does not seem to find it).  A simple workaround does
>> exist: instead of using the super machinery, just explicitly refer to
>> the super-class by name, as in older Python versions.
>
> You never need to call super's +initialize;  the runtime will call
> +initialize on each class independently of your code.


Fair enough.  Nonetheless, the bug still exists.  The problem is not  
calling the superclass' initialize method, but using super (and behind- 
the-scenes, objc.super) from within an initialize classmethod.  I've  
shown a contrived standalone example below, but there are also real  
cases when one would want to do this (e.g. calling super(MyPlugin,  
cls).registerBundle() in a Mail plugin).

Cheers!
James

jagaroth:~ $ python
Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> class Test(NSObject):
...     @classmethod
...     def initialize(cls):
...             print u'about to call super'
...             super(Test, cls).class_()
...             print u'did call super. done.'
...
about to call super
2007-11-05 11:40:08.603 Python[2295:613] *** Terminating app due to  
uncaught exception 'OC_PythonException', reason: '<type  
'exceptions.NameError'>: global name 'Test' is not defined'


--
I can't give you a brain, but I can give you a diploma.
               -- The Wizard of Oz

Re: [Pyobjc-dev] Changes to +initialize() / super behavior in PyObjC 2.0?

[Bill B. <bb...@ma...>]

On Nov 5, 2007, at 7:34 AM, James R Eagan wrote:
> It appears that in previous versions of PyObjC, one could refer to a
> superclass via super within the initialize classmethod, but in PyObjC
> 2.0, the class does not seem to exist yet (or, at least, the
> objc.super proxy does not seem to find it).  A simple workaround does
> exist: instead of using the super machinery, just explicitly refer to
> the super-class by name, as in older Python versions.

You never need to call super's +initialize;  the runtime will call  
+initialize on each class independently of your code.

b.bum

Re: [Pyobjc-dev] pyobjc 2.0 has landed in the repository

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

On 4 Nov, 2007, at 20:24, st cnx wrote:

> Hi Ronald,
>
> One trick I need in Find It! Keep It! is the ability to wrap existing
> objective c class methods. To get the objective c selector of the
> original method, I would do the following:
>
> imp = classname.instanceMethodForSelector_("selector:")
> sel = objc.selector(imp, selector = imp.selector, signature =  
> imp.signature)
>
> The second line blows up with the new pyobjc on Leopard. Should I be
> doing something else to achieve this? (I haven't tried poseAsClass_
> for this yet).

What are you trying to accomplish? Method swiffling is often the wrong  
way to accomplish things.

What you seem to be doing is add a method from one class to a  
different class. That's odd at best, and could easily cause severe  
problems.

If you're replacing a method you can store the imp in a global  
variable and call that from your replacement method, without having to  
convert it to a selector object.

Ronald

[Pyobjc-dev] Changes to +initialize() / super behavior in PyObjC 2.0?

[James R E. <ea...@ba...>]

Hi folks,

I spent about ten minutes tracking down this problem with the new  
PyObjC on Leopard.

It appears that in previous versions of PyObjC, one could refer to a  
superclass via super within the initialize classmethod, but in PyObjC  
2.0, the class does not seem to exist yet (or, at least, the  
objc.super proxy does not seem to find it).  A simple workaround does  
exist: instead of using the super machinery, just explicitly refer to  
the super-class by name, as in older Python versions.

Here is a quick demonstration:

---- PyObjC 1.4.1a0 ----
Python 2.4.3 (#1, Apr  7 2006, 10:54:33)
[GCC 4.0.1 (Apple Computer, Inc. build 5250)] in Cocoa Buzz
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> import objc
 >>> objc.__version__
'1.4.1a0'
 >>> class Test(NSObject):
... 		@classmethod
... 		def initialize(cls):
... 			print u'about to call super'
... 			super(Test, cls).initialize()
... 			print u'did call super.  done.'
...
 >>> Test.alloc().init()
about to call super
did call super.  done.
<Test: 0x14b2ca60>
 >>>


---- PyObjC 2.0 ----
jagaroth:~/Desktop $ python
Python 2.5.1 (r251:54863, Oct  5 2007, 21:08:09)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> import objc
 >>> objc.__version__
'2.0'
 >>> class Test(NSObject):
...             @classmethod
...             def initialize(cls):
...                     print u'about to call super'
...                     super(Test, cls).initialize()
...                     print u'did call super.  done.'
...
about to call super
2007-11-05 09:55:17.866 Python[1916:613] *** Terminating app due to  
uncaught exception 'OC_PythonException', reason: '<type  
'exceptions.NameError'>: global name 'Test' is not defined'


--
I keep trying to think, but nothing happens.
                -- Curly, The Three Stooges

Re: [Pyobjc-dev] Problem with alias build on Leopard

[Luc H. <lu...@ho...>]

On 2 nov. 07, at 15:55, Luc Heinrich wrote:

> So as I was saying in the "PyObjC 2" thread, I'm having weird
> problems with my code on Leopard: my application won't launch and
> just dies with the following message
>
> _RegisterApplication(), FAILED TO establish the default connection to
> the WindowServer, _CGSDefaultConnection() is NULL.

Great, it looks like my code is not responsible for this, I have found  
other examples in the wild:

- Open a terminal window and go to /Developer/Examples/Python/PyObjC/ 
Quartz/ImageKit/ImageBrowser
- do a 'python setup.py py2app -A'
- launch the application built in the 'dist' folder and watch it  
infinitely bouncing in the Dock.
- check Console.app for the error message(s)...

If you rebuild the application without the '-A' (i.e. do a normal  
build as opposed to an alias build, it will work as expected).

So it really seems that *some* alias builds do have a problem.

Still no idea ? ;)

-- 
Luc Heinrich

Re: [Pyobjc-dev] pyobjc 2.0 has landed in the repository

[st c. <stc...@gm...>]

Hi Ronald,

One trick I need in Find It! Keep It! is the ability to wrap existing
objective c class methods. To get the objective c selector of the
original method, I would do the following:

imp = classname.instanceMethodForSelector_("selector:")
sel = objc.selector(imp, selector = imp.selector, signature = imp.signature)

The second line blows up with the new pyobjc on Leopard. Should I be
doing something else to achieve this? (I haven't tried poseAsClass_
for this yet).

Thanks,

Sengan

Re: [Pyobjc-dev] Leopard and garbage collection

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

On 3 Nov, 2007, at 22:17, Bill Bumgarner wrote:

> On Nov 3, 2007, at 12:36 PM, Frank Illenberger wrote:
>> Thanks for the clarification.
>> My application is a normal Objective-C NSDocument app that loads
>> additional plug-in bundles containing Python classes which are
>> derived from Objective-C classes. The plug-in classes generate
>> reports on the Objective-C model data in in my application using KV-
>> coding.
>>
>> So, which of the "two kinds of GC" would be needed by my application?
>
> Either one would work, if they existed.   But neither truly do.
>
> Making Python's GC work with Obj-C's GC is considerably easier than
> replacing Python's GC.

This should already work with PyObjC (although the code for that is  
currently untested), but I guess this requires recompilation of Python  
and PyObjC with some magic compiler flags to enable the GC-support in  
GCC (write-barriers and the like).

>
>
>> I think BBum is saying: They're working on making the GC in objc and
>> the GC in python cohabitate.  They're also working on making the GC  
>> in
>> objc *replace* the GC in python so you end up using the same GC for
>> both languages.  The latter is a lot harder than the former (but  
>> worth
>> doing).  You can expect to see the former first as they've already
>> started work on it.
>
> Ronald has already done some cohabitation work.   We [the community]
> should pick up and run with that.
>
> As far as replacing the Python collector is concerned, I'm only saying
> that replacing Python's (or Ruby's) GC with the Objective-C collector
> from Leopard is very very interesting and potentially highly rewarding
> (having a single collector consistently collecting objects across both
> languages would simplify the bridges considerably).

I agree with that, especially when one would basicaly fold PyObjC into  
the Python interpreter. That is, make all Python objects  
CoreFoundation/Cocoa objects as well. My gut feeling is that this is  
very well possible but requires considerable effort.

Ronald


>
>
> b.bum
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Leopard and garbage collection

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

On 1 Nov, 2007, at 9:01, Frank Illenberger wrote:

> Hello all,
>
> I am planning to migrate a Cocoa/PyObjC application to Objective-C 2.0
> with garbage collection but I discovered that GC simly does not work
> with PyObjC. Will GC be supported some day by PyObjC?

Yes and no. I do want PyObjC save to be used in a GC-enabled  
application, and most if not all code for that should be present. As  
Bill notes this support is not tested at the moment.

This does however not mean that Python will suddenly start using  
Objective-C's GC mechanism. While this would be possible, and with a  
proper implementation would allow for usefull new functionality (such  
as dealing cleanly with reference cycles that contain both Python and  
Objective-C objects), this is not a trivial exercise.

Ronald

>
>
> Cheers
>
>  Frank
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev