pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Memory Management Problem - Objects being deallocated

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

On 29 Sep, 2009, at 22:09, Lukas Pitschl | Dressy Vagabonds wrote:

> A different question, would it negatively affect to plugin if I used
> retain,
> wherever the original objective-c code uses it?

That should work if you call release or autorelease as well,
and if you ignore that some ObjC methods (such as +alloc
and -copy) return an object with a +1 retainCount because
PyObjC automaticly compensates for that.

That is, the following code is invalid in PyObjC, but the corresponding
ObjC code is correct:

    a = NSArray.alloc().init()
    a.release()
    a = None

As James noted manually managing the retaincount shouldn't be
necessary in most code, except that some ObjC APIs use ObjC-style
weak references and you must ensure that objects you pass to those
APIs stay alive.

The most visible of those are notification centers and objects returned
by the outlineview dataprovider protocol.

Ronald
>
> Lukas
>
>
> Am 29.09.2009 um 19:28 schrieb James R Eagan:
>
>> Hi Lukas,
>>
>> Most likely PyObjC is doing the right thing, just not what you
>> expect.  I suppose it depends on your definition of the right thing,
>> though.  It's hard to say what's happening based on what you've
>> given, but it sounds like you might have a case of unretained
>> delegates.
>>
>> PyObjC will hold an ObjC reference (i.e. retain) any objects on its
>> side of the bridge.  Remember that for some Cocoa delegates and data
>> providers, you are expected to retain a copy of the data source
>> (e.g. NSTableView dataSource).  If you don't make sure you keep a
>> python reference to that object, then PyObjC will no longer keep the
>> ObjC reference, and the object will be released.  So the first place
>> I'd look is to make sure you're keeping a python reference to all
>> your dataSource's and other appropriate delegates (the Cocoa
>> documentation is your friend here).
>>
>> Good luck!
>> James
>>
>> On 29 sept. 2009, at 18:34, Lukas Pitschl | Dressy Vagabonds wrote:
>>
>>> At the moment I'm re-implementing the GPGMail Plugin in PyObjC and I
>>> noticed
>>> that sometimes the Mail.app crashes because PyObjC is accessing
>>> memory
>>> that
>>> is no longer allocated.
>>>
>>> As the documentation mentions memory management should be left to
>>> PyObjC
>>> I wonder how this can happen.
>>>
>>> Should i use retain on the object? Any suggestions how to find the
>>> objects that are causing the problem
>>> or debug this situation further?
>>>
>>> Greets
>>>
>>> Lukas
>>>
>>> ------------------------------------------------------------------------------
>>> Come build with us! The BlackBerry® Developer Conference in SF,
>>> CA
>>> is the only developer event you need to attend this year. Jumpstart
>>> your
>>> developing skills, take BlackBerry mobile applications to market
>>> and stay
>>> ahead of the curve. Join us from November 9-12, 2009. Register
>>> now!
>>> http://p.sf.net/sfu/devconf
>>> _______________________________________________
>>> Pyobjc-dev mailing list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Memory Management Problem - Objects being deallocated

[Lukas P. | D. V. <lu...@dr...>]

A different question, would it negatively affect to plugin if I used  
retain,
wherever the original objective-c code uses it?

Lukas


Am 29.09.2009 um 19:28 schrieb James R Eagan:

> Hi Lukas,
>
> Most likely PyObjC is doing the right thing, just not what you  
> expect.  I suppose it depends on your definition of the right thing,  
> though.  It's hard to say what's happening based on what you've  
> given, but it sounds like you might have a case of unretained  
> delegates.
>
> PyObjC will hold an ObjC reference (i.e. retain) any objects on its  
> side of the bridge.  Remember that for some Cocoa delegates and data  
> providers, you are expected to retain a copy of the data source  
> (e.g. NSTableView dataSource).  If you don't make sure you keep a  
> python reference to that object, then PyObjC will no longer keep the  
> ObjC reference, and the object will be released.  So the first place  
> I'd look is to make sure you're keeping a python reference to all  
> your dataSource's and other appropriate delegates (the Cocoa  
> documentation is your friend here).
>
> Good luck!
> James
>
> On 29 sept. 2009, at 18:34, Lukas Pitschl | Dressy Vagabonds wrote:
>
>> At the moment I'm re-implementing the GPGMail Plugin in PyObjC and I
>> noticed
>> that sometimes the Mail.app crashes because PyObjC is accessing  
>> memory
>> that
>> is no longer allocated.
>>
>> As the documentation mentions memory management should be left to  
>> PyObjC
>> I wonder how this can happen.
>>
>> Should i use retain on the object? Any suggestions how to find the
>> objects that are causing the problem
>> or debug this situation further?
>>
>> Greets
>>
>> Lukas
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF,  
>> CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market  
>> and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register  
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Memory Management Problem - Objects being deallocated

[James R E. <Jam...@lr...>]

Hi Lukas,

Most likely PyObjC is doing the right thing, just not what you  
expect.  I suppose it depends on your definition of the right thing,  
though.  It's hard to say what's happening based on what you've given,  
but it sounds like you might have a case of unretained delegates.

PyObjC will hold an ObjC reference (i.e. retain) any objects on its  
side of the bridge.  Remember that for some Cocoa delegates and data  
providers, you are expected to retain a copy of the data source (e.g.  
NSTableView dataSource).  If you don't make sure you keep a python  
reference to that object, then PyObjC will no longer keep the ObjC  
reference, and the object will be released.  So the first place I'd  
look is to make sure you're keeping a python reference to all your  
dataSource's and other appropriate delegates (the Cocoa documentation  
is your friend here).

Good luck!
James

On 29 sept. 2009, at 18:34, Lukas Pitschl | Dressy Vagabonds wrote:

> At the moment I'm re-implementing the GPGMail Plugin in PyObjC and I
> noticed
> that sometimes the Mail.app crashes because PyObjC is accessing memory
> that
> is no longer allocated.
>
> As the documentation mentions memory management should be left to  
> PyObjC
> I wonder how this can happen.
>
> Should i use retain on the object? Any suggestions how to find the
> objects that are causing the problem
> or debug this situation further?
>
> Greets
>
> Lukas
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Memory Management Problem - Objects being deallocated

[Lukas P. | D. V. <lu...@dr...>]

At the moment I'm re-implementing the GPGMail Plugin in PyObjC and I  
noticed
that sometimes the Mail.app crashes because PyObjC is accessing memory  
that
is no longer allocated.

As the documentation mentions memory management should be left to PyObjC
I wonder how this can happen.

Should i use retain on the object? Any suggestions how to find the  
objects that are causing the problem
or debug this situation further?

Greets

Lukas

Re: [Pyobjc-dev] Exception when trying to use datetime object in NSArrayController

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

On 29 Sep, 2009, at 3:14, Erik Wickstrom wrote:

> I'm having some trouble passing a Python datetime.datetime.now()
> object to an NSArrayController.  I keep getting this error:
>
> (ValueError: NSInvalidArgumentException - *** -[NSDate
> initWithTimeIntervalSinceReferenceDate:]: method only defined for
> abstract class.  Define -[OC_PythonDate
> initWithTimeIntervalSinceReferenceDate:]!)  -- I though pyobjc could
> convert this type.  Any ideas?
>
> class DTController(NSObject):
>    arrayController = objc.IBOutlet()
>    data = []
>
>    def awakeFromNib(self):
>        print "testing 123"
>        self.data.append({'date': datetime.datetime.now(),
>                     'comments': 'testing 123',})
>        self.arrayController.rearrangeObjects()
>
> Any idea what I'm doing wrong?

It seems to work for me, could you please tell more about your  
environment:

* Which version of OSX?
* Are you using /usr/bin/python or a custom install?
* Which version of PyObjC are you using (python -c 'import objc; print  
objc.__version__')

BTW. The script I tested with is:

# begin of file
from Cocoa import *
import datetime

a = NSMutableArray.array()
c = NSArrayController.alloc().initWithContent_(a)

a.addObject_(datetime.datetime.now())
print a

c.rearrangeObjects()

# end of file

Could you create a small standalone program what demonstrates the  
problem? A GUI tool would be fine.

Ronald
>
> Thanks!
> Erik
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Exception when trying to use datetime object in NSArrayController

[Erik W. <er...@er...>]

I'm having some trouble passing a Python datetime.datetime.now()
object to an NSArrayController.  I keep getting this error:

(ValueError: NSInvalidArgumentException - *** -[NSDate
initWithTimeIntervalSinceReferenceDate:]: method only defined for
abstract class.  Define -[OC_PythonDate
initWithTimeIntervalSinceReferenceDate:]!)  -- I though pyobjc could
convert this type.  Any ideas?

class DTController(NSObject):
    arrayController = objc.IBOutlet()
    data = []

    def awakeFromNib(self):
        print "testing 123"
        self.data.append({'date': datetime.datetime.now(),
                     'comments': 'testing 123',})
        self.arrayController.rearrangeObjects()

Any idea what I'm doing wrong?

Thanks!
Erik

Re: [Pyobjc-dev] Exceptions on calling super

[Dirk S. <dir...@ma...>]

More news from the working around front:

Apparently something in BridgeSupport changed in Snow Leopard, with  
the effect that you can no longer call unbound instance methods by  
passing in the instance as the first variable:

on Leopard:

> >>> NSObject.init()
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: Missing argument: self


on Snow Leopard:

> >>> NSObject.init(someInstance)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: Need 0 arguments, got 1

Calling these the other way around works.

So quick heads up to anyone following this thread: My workaround was  
flawed.  Installing pyobjc from trunk on Python 2.6.2 now, as "import  
objc" seems to work on that. (no _PyType_Modified errors)

- Dirk

On Sep 21, 2009, at 12:46 PM, Dirk Stoop wrote:

> On Sep 17, 2009, at 5:39 PM, Dirk Stoop wrote:
>
>> We're targetting Leopard and are currently still running on PyObjC
>> 2.2b6 (because getting later releases to actually build the app on
>> Leopard has proven to be quite hard, and we're on a tight schedule, I
>> haven't upgraded to something newer yet).
>
> Oops, that should've been 2.2b2.
>
> I just tried to install the latest and greatest from trunk on Leopard,
> so I can benefit from Ronald's latest fixes, but I'm getting errors on
> an unfound symbol, called: _PyType_Modified whenever I try to import
> objc.
>
> Ronald responded to someone with the same or a similar issue over here
> a little while ago:
>
>> http://www.gossamer-threads.com/lists/python/bugs/771198?do=post_view_flat#771198
>
> Does anyone know what specific issues there might be with a Python
> installation that result in this "_PyType_Modified" to not be defined?
> -- I'm using a custom installed Python 2.5.4 on Leopard, because the  
> standard installation has issues with building for PPC and Intel.
>
> Thanks in advance,
> - Dirk
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] PyObjcC class method swizzling

[Lukas P. | D. V. <lu...@dr...>]

Just for information: I've now decided to change strategy and  
implement the
class method swizzling in Objective-C. That works like a charm.

I'm still interested though in any solutions to this problems, since I  
don't want
to load many objective-c frameworks into my plugin.

Thx for the help everyone

Lukas

Am 21.09.2009 um 02:20 schrieb Lukas Pitschl | Dressy Vagabonds:

> Of course you'd use a decorator, the problem is that PyObjC doesn't
> like it if you combine @classmethod and @swizzle (dealing with the
> swizzle).
> I still haven't found out why that is, but it simply won't work
>
>
> Am 21.09.2009 um 01:57 schrieb Aahz:
>
>> On Mon, Sep 21, 2009, Lukas Pitschl | Dressy Vagabonds wrote:
>>>
>>> That might be same, don't really know those terms.  The important
>>> thing is that they do the same thing being, replacing the original
>>> implementation with a custom one and preserve the original one to
>>> call
>>> it in the custom one.
>>>
>>> Any idea Aahz on how to do that?
>>
>> That's basically what decorators do, here are a couple of hits from
>> Googling "python decorator tutorial":
>>
>> http://www.artima.com/weblogs/viewpost.jsp?thread=240808
>> http://uswaretech.com/blog/2009/06/understanding-decorators/
>> -- 
>> Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/
>>
>> "I won't accept a model of the universe in which free will,  
>> omniscient
>> gods, and atheism are simultaneously true."  --M
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF,  
>> CA
>> is the only developer event you need to attend this year. Jumpstart
>> your
>> developing skills, take BlackBerry mobile applications to market and
>> stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Exceptions on calling super

[Dirk S. <dir...@ma...>]

On Sep 17, 2009, at 5:39 PM, Dirk Stoop wrote:

> We're targetting Leopard and are currently still running on PyObjC
> 2.2b6 (because getting later releases to actually build the app on
> Leopard has proven to be quite hard, and we're on a tight schedule, I
> haven't upgraded to something newer yet).

Oops, that should've been 2.2b2.

I just tried to install the latest and greatest from trunk on Leopard,  
so I can benefit from Ronald's latest fixes, but I'm getting errors on  
an unfound symbol, called: _PyType_Modified whenever I try to import  
objc.

Ronald responded to someone with the same or a similar issue over here  
a little while ago:

> http://www.gossamer-threads.com/lists/python/bugs/771198?do=post_view_flat#771198

Does anyone know what specific issues there might be with a Python  
installation that result in this "_PyType_Modified" to not be defined?  
-- I'm using a custom installed Python 2.5.4 on Leopard, because the  
standard installation has issues with building for PPC and Intel.

Thanks in advance,
- Dirk

[Pyobjc-dev] Initial memory usage

[Arif A. <ari...@gm...>]

Hi all,
I've recently started developing PyObjC apps and my app memory usage shot
off to 75MB. So I created a small Hello World app with just one NSWindow and
the initial memory was 36MB. I'd assume this would be expected since the
entire Python interpreter is running within the app it might take that much.
So is it safe to assume that all PyObjC apps need a minimum of 30+M to work?

Versions:
Mac OS X 10.5.8

>>> print objc.__version__
2.2b2

Thanks,
Arif Amirani

Blog: http://blog.tripmeter.in

Re: [Pyobjc-dev] PyObjcC class method swizzling

[Lukas P. | D. V. <lu...@dr...>]

Of course you'd use a decorator, the problem is that PyObjC doesn't
like it if you combine @classmethod and @swizzle (dealing with the  
swizzle).
I still haven't found out why that is, but it simply won't work


Am 21.09.2009 um 01:57 schrieb Aahz:

> On Mon, Sep 21, 2009, Lukas Pitschl | Dressy Vagabonds wrote:
>>
>> That might be same, don't really know those terms.  The important
>> thing is that they do the same thing being, replacing the original
>> implementation with a custom one and preserve the original one to  
>> call
>> it in the custom one.
>>
>> Any idea Aahz on how to do that?
>
> That's basically what decorators do, here are a couple of hits from
> Googling "python decorator tutorial":
>
> http://www.artima.com/weblogs/viewpost.jsp?thread=240808
> http://uswaretech.com/blog/2009/06/understanding-decorators/
> -- 
> Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/
>
> "I won't accept a model of the universe in which free will, omniscient
> gods, and atheism are simultaneously true."  --M
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] PyObjcC class method swizzling

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

On Mon, Sep 21, 2009, Lukas Pitschl | Dressy Vagabonds wrote:
>
> That might be same, don't really know those terms.  The important
> thing is that they do the same thing being, replacing the original
> implementation with a custom one and preserve the original one to call
> it in the custom one.
>
> Any idea Aahz on how to do that?

That's basically what decorators do, here are a couple of hits from
Googling "python decorator tutorial":

http://www.artima.com/weblogs/viewpost.jsp?thread=240808
http://uswaretech.com/blog/2009/06/understanding-decorators/
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"I won't accept a model of the universe in which free will, omniscient
gods, and atheism are simultaneously true."  --M

Re: [Pyobjc-dev] PyObjcC class method swizzling

[Lukas P. | D. V. <lu...@dr...>]

That might be same, don't really know those terms.
The important thing is that they do the same thing being,
replacing the original implementation with a custom one
and preserve the original one to call it in the custom one.

Any idea Aahz on how to do that?

@ James: Thanks, I'll try that immediately!

Lukas

Am 20.09.2009 um 19:14 schrieb Aahz:

> On Sun, Sep 20, 2009, Lukas Pitschl | Dressy Vagabonds wrote:
>>
>> Instance method or class method swizzling is basically the idea of
>> replacing an existing class/instance method implementation with your
>> own implementation, however differently from using categories, since
>> the original implementation should be preserved to later use it in
>> your own implementation of the mehtod.
>
> How is this different from proxying or monkey-patching?
> --  
> Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/
>
> "I won't accept a model of the universe in which free will, omniscient
> gods, and atheism are simultaneously true."  --M
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] PyObjcC class method swizzling

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

On Sun, Sep 20, 2009, Lukas Pitschl | Dressy Vagabonds wrote:
>
> Instance method or class method swizzling is basically the idea of
> replacing an existing class/instance method implementation with your
> own implementation, however differently from using categories, since
> the original implementation should be preserved to later use it in
> your own implementation of the mehtod.

How is this different from proxying or monkey-patching?
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"I won't accept a model of the universe in which free will, omniscient
gods, and atheism are simultaneously true."  --M

Re: [Pyobjc-dev] PyObjcC class method swizzling

[James R E. <Jam...@lr...>]

Hi Lukas,

Here's a copy of the method i use.  I haven't tried swizzling any  
classmethods, so it may or may not work for your purposes.  One  
problem I've had in particular with PyObjC decorators is that  
Objective-C and consequently PyObjC don't like *args and **kwargs- 
style parameters very well.  My workaround is to inspect the decorated  
method and return the appropriate version from a lookup table.  This  
works in most reasonable cases, but it not as clean as I'd like (If  
anyone else has a better suggestion, I'd love to hear it!).

Anyways, here's my swizzle decorator :

# Replacement wrapper lambdas depending on the number of parameters  
required.  Support up to 8
# parameters, including self.  This is necessary to suppress a PyObjC  
DeprecationWarning about
# Not all Objective-C arguments being present in the Python argument  
list (collapsed as *args).
__swizzleIMPMap = {0: lambda f: lambda: f(),
                    1: lambda f: lambda self: f(self),
                    2: lambda f: lambda self, a: f(self, a),
                    3: lambda f: lambda self, a, b: f(self, a, b),
                    4: lambda f: lambda self, a, b, c: f(self, a, b, c),
                    5: lambda f: lambda self, a, b, c, d: f(self, a,  
b, c, d),
                    6: lambda f: lambda self, a, b, c, d, e: f(self,  
a, b, c, d, e),
                    7: lambda f: lambda self, a, b, c, d, e, g: f 
(self, a, b, c, d, e, g),
                    8: lambda f: lambda self, a, b, c, d, e, g, h: f 
(self, a, b, c, d, e, g, h),
                   }

def swizzleMethod(old):
     def swizzleWithNewMethod_(f):
         cls = old.definingClass
         oldSelectorName = old.__name__.replace("_", ":")
         oldIMP = cls.instanceMethodForSelector_(oldSelectorName)
         newSelectorName = f.__name__.replace("_", ":")

         argc = len(inspect.getargspec(f)[0])
         newSEL = objc.selector(f, selector=newSelectorName,  
signature=old.signature)
         #oldSEL = objc.selector(lambda self, *args: oldIMP(self,  
*args), selector=newSelectorName, signature=old.signature)
         oldSEL = objc.selector(__swizzleIMPMap[argc](oldIMP),  
selector=newSelectorName, signature=old.signature)

         # Swap the two methods
         objc.classAddMethod(cls, newSelectorName, oldSEL)
         objc.classAddMethod(cls, oldSelectorName, newSEL)
         #NSLog(u"Swizzled %s.%s <-> %s" % (cls.__name__,  
oldSelectorName, newSelectorName))

         return f

     return swizzleWithNewMethod_


Use it like this:

@swizzle(NSPreferences.sharedPreferences)  # Note: this hasn't been  
tested with classmethods!
def sharedPreferences(self):
	# ...
	self.sharedPreferences() # Calls the original method
	# ...

Cheers!
James

Le 19 sept. 2009 à 14:02, Lukas Pitschl | Dressy Vagabonds a écrit :

> Hi everyone!
>
> I've just recently started to explore the power of PyObjC by rewriting
> the GPGMail plugin and I'm more than impressed.
> A big compliment to the developers!
>
> Unfortunately at the moment I'm stuck with class method swizzling.
> I've found a very nice decorator which can be used
> to swizzle instance methods:
>
> def swizzle(*args):
>     cls, SEL = args
>     def decorator(func):
>         oldIMP      = cls.instanceMethodForSelector_(SEL)
>         def wrapper(self, *args, **kwargs):
>             return func(self, oldIMP, *args, **kwargs)
>         newMethod   = objc.selector(wrapper,
>                                     selector  = oldIMP.selector,
>                                     signature = oldIMP.signature)
>         objc.classAddMethod(cls, SEL, newMethod)
>         return wrapper
>     return decorator
>
> My poor attempt to convert this into a decorator which swizzles class
> methods looks like the one below, but unfortunately doesn't
> work.
>
> def swizzleClassMethod(*args):
>     cls, SEL = args
>     def decorator(func):
>         oldIMP      = cls.methodForSelector_(SEL)
>         def wrapper(klass, *args, **kwargs):
>             return func(klass, oldIMP, *args, **kwargs)
>         newMethod   = objc.selector(wrapper,
>                                     selector  = oldIMP.selector,
>                                     signature = oldIMP.signature)
>         objc.classAddMethod(cls, SEL, newMethod)
>         return wrapper
>     return decorator
>
> I'd really appreciate it, if someone could help me to find out how to
> do this.
> What I wanna do with that is replacing the + sharedPreferences class
> method of the NSPreferences class
> with my own implementation and call the original method from within
> there.
>
> Please anyone point me into the right direction, so I can finally
> finish the GPGMail plugin.
>
> Thanks in advance
>
> Lukas
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] PyObjcC class method swizzling

[Lukas P. | D. V. <lu...@dr...>]

Oh, right, that's a good idea.

Instance method or class method swizzling is basically the idea of  
replacing an existing
class/instance method implementation with your own implementation,  
however differently
from using categories, since the original implementation should be  
preserved
to later use it in your own implementation of the mehtod.

This allows you to add additional functionality to the original method  
implementation,
in my case for example to add a preferences pane to Mail.app which is  
otherwise not possible.

I hope this explains a little better what i'm looking for.

Thx for in advance for any help

Lukas


Am 20.09.2009 um 16:38 schrieb Aahz:

> On Sat, Sep 19, 2009, Lukas Pitschl | Dressy Vagabonds wrote:
>>
>> Unfortunately at the moment I'm stuck with class method swizzling.
>> I've found a very nice decorator which can be used to swizzle  
>> instance
>> methods:
>
> Could you please explain what "swizzling" is?  I've never heard the  
> term
> before, and I haven't, it's likely other people haven't, either --  
> more
> efficient for you to explain than force everyone to JFGI.
> -- 
> Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/
>
> "I won't accept a model of the universe in which free will, omniscient
> gods, and atheism are simultaneously true."  --M
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] PyObjcC class method swizzling

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

On Sat, Sep 19, 2009, Lukas Pitschl | Dressy Vagabonds wrote:
>
> Unfortunately at the moment I'm stuck with class method swizzling.
> I've found a very nice decorator which can be used to swizzle instance
> methods:

Could you please explain what "swizzling" is?  I've never heard the term
before, and I haven't, it's likely other people haven't, either -- more
efficient for you to explain than force everyone to JFGI.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"I won't accept a model of the universe in which free will, omniscient
gods, and atheism are simultaneously true."  --M

Re: [Pyobjc-dev] Exceptions on calling super

[Dirk S. <dir...@ma...>]

>> We recently moved our app from PyObjC 1.4 to 2.2 and now get a lot of
>> exceptions like this:
>>
>> TypeError??: super(type, obj): obj must be an instance or subtype of
>> type
>>
>> These happen in any Python subclass of a Cocoa superclass, but only
>> occasionally.  I'm not completely clear how to reproduce the issue,
>> but it only happens when we override an initializer and have a call  
>> to:
>>
>> super(classNameOfOurSubClass, self).init() # or any other  
>> initializer.
>>
>> Does anyone have a clue what might be going on?
>
> That message pretty clearly means that a classic class is getting
> injected somehow.  Consider this::
>
>    class C:
>        def foo(self):
>            super(C, self)
>
>    C().foo()
>
> Which version of Python?


Thanks for your reply :)

We're using Python 2.5.4 and we don't have classic classes anywhere in  
our app.

The error message I get from the example you wrote is also different  
from the one we're getting..

TypeError: super() argument 1 must be type, not classobj

The one I get seems to explicitely state that the second argument is  
not the type or a subtype of the first argument, yet the one I get  
when I run your example just tells me that the second type can't be  
'the' old-style classobj.

To get our app to stop crashing on this, I'll replace e.g.

class SFWindow(NSWindow):
     def initWithContentRect_styleMask_backing_defer_(self,  
contentRect, styleMask, backing, defer):
         self = super(SFWindow,  
self).initWithContentRect_styleMask_backing_defer_(contentRect,  
styleMask, backing, defer)
         if self:
             pass # do stuff
         return self

with:

class SFWindow(NSWindow):
     def initWithContentRect_styleMask_backing_defer_(self,  
contentRect, styleMask, backing, defer):
         self =  
NSWindow.initWithContentRect_styleMask_backing_defer_(self,  
contentRect, styleMask, backing, defer)
         if self:
             pass # do stuff
         return self
	
for now.  I'm not planning on changing the superclasses of any of  
these classes anyway, so the extra burden of maintaining this code is  
well worth getting rid of these occasional crashes.

Still very weird that this happens, I've tried to isolate the issue to  
a particular situation, but all my efforts so far have failed and I  
don't have time now to do more research.  I'll post again here if/when  
I've figured out the exact regression of this problem.

- Dirk

[Pyobjc-dev] PyObjcC class method swizzling

[Lukas P. | D. V. <lu...@dr...>]

Hi everyone!

I've just recently started to explore the power of PyObjC by rewriting  
the GPGMail plugin and I'm more than impressed.
A big compliment to the developers!

Unfortunately at the moment I'm stuck with class method swizzling.  
I've found a very nice decorator which can be used
to swizzle instance methods:

def swizzle(*args):
     cls, SEL = args
     def decorator(func):
         oldIMP      = cls.instanceMethodForSelector_(SEL)
         def wrapper(self, *args, **kwargs):
             return func(self, oldIMP, *args, **kwargs)
         newMethod   = objc.selector(wrapper,
                                     selector  = oldIMP.selector,
                                     signature = oldIMP.signature)
         objc.classAddMethod(cls, SEL, newMethod)
         return wrapper
     return decorator

My poor attempt to convert this into a decorator which swizzles class  
methods looks like the one below, but unfortunately doesn't
work.

def swizzleClassMethod(*args):
     cls, SEL = args
     def decorator(func):
         oldIMP      = cls.methodForSelector_(SEL)
         def wrapper(klass, *args, **kwargs):
             return func(klass, oldIMP, *args, **kwargs)
         newMethod   = objc.selector(wrapper,
                                     selector  = oldIMP.selector,
                                     signature = oldIMP.signature)
         objc.classAddMethod(cls, SEL, newMethod)
         return wrapper
     return decorator

I'd really appreciate it, if someone could help me to find out how to  
do this.
What I wanna do with that is replacing the + sharedPreferences class  
method of the NSPreferences class
with my own implementation and call the original method from within  
there.

Please anyone point me into the right direction, so I can finally  
finish the GPGMail plugin.

Thanks in advance

Lukas 

Re: [Pyobjc-dev] Exceptions on calling super

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

On Thu, Sep 17, 2009, Dirk Stoop wrote:
> 
> We recently moved our app from PyObjC 1.4 to 2.2 and now get a lot of  
> exceptions like this:
> 
> TypeError??: super(type, obj): obj must be an instance or subtype of  
> type
> 
> These happen in any Python subclass of a Cocoa superclass, but only  
> occasionally.  I'm not completely clear how to reproduce the issue,  
> but it only happens when we override an initializer and have a call to:
> 
> super(classNameOfOurSubClass, self).init() # or any other initializer.
> 
> Does anyone have a clue what might be going on?

That message pretty clearly means that a classic class is getting
injected somehow.  Consider this::

    class C:
        def foo(self):
            super(C, self)

    C().foo()

Which version of Python?
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"I won't accept a model of the universe in which free will, omniscient
gods, and atheism are simultaneously true."  --M

[Pyobjc-dev] Exceptions on calling super

[Dirk S. <dir...@me...>]

Hi all,

We recently moved our app from PyObjC 1.4 to 2.2 and now get a lot of  
exceptions like this:

TypeError??: super(type, obj): obj must be an instance or subtype of  
type

These happen in any Python subclass of a Cocoa superclass, but only  
occasionally.  I'm not completely clear how to reproduce the issue,  
but it only happens when we override an initializer and have a call to:

super(classNameOfOurSubClass, self).init() # or any other initializer.

Does anyone have a clue what might be going on?

We're targetting Leopard and are currently still running on PyObjC  
2.2b6 (because getting later releases to actually build the app on  
Leopard has proven to be quite hard, and we're on a tight schedule, I  
haven't upgraded to something newer yet).

Thanks in advance!
- Dirk Stoop

Sofa

Re: [Pyobjc-dev] Snow Leopard Support

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

On 10 Sep, 2009, at 4:42, Sanford Barton wrote:

> Thank you for this, worked for me.  Is there any chance your or
> someone can do the same for the File Templates?

It is not necessary to create a zipfile, use "Connect to Server..." in  
the Finder to connect to "<http://svn.red-bean.com/pyobjc/trunk/pyobjc/pyobjc-xcode/ 
 >". You can then copy the templates using the Finder.

Ronald


>
> Thanks,
> Bart
>
>> Here's what I did:
>>
>> 1) Copy all the Python templates from an installation of the previous
>> Xcode to a folder "PythonApplications"
>> 2) zip up this folder
>> 3) Copy this to "~/Library/Application
>> Support/Developer/Shared/Xcode/Project Templates" and unzip
>>
>> Here's my zip file so you can skip steps 1&2: http://bit.ly/150NUx
>>
>> It works for me, let us know how it goes.
>>
>> Cheers,.Mani
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Snow Leopard Support

[Sanford B. <xc...@gm...>]

Thank you for this, worked for me.  Is there any chance your or
someone can do the same for the File Templates?

Thanks,
Bart

>Here's what I did:
>
>1) Copy all the Python templates from an installation of the previous
>Xcode to a folder "PythonApplications"
>2) zip up this folder
>3) Copy this to "~/Library/Application
>Support/Developer/Shared/Xcode/Project Templates" and unzip
>
>Here's my zip file so you can skip steps 1&2: http://bit.ly/150NUx
>
>It works for me, let us know how it goes.
>
>Cheers,.Mani

[Pyobjc-dev] [ pyobjc-Bugs-2855457 ] Does not easy_install on Snow Leopard

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

Bugs item #2855457, was opened at 2009-09-09 21:58
Message generated for change (Tracker Item Submitted) made by p_arrenbrecht
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=2855457&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: Peter Arrenbrecht (p_arrenbrecht)
Assigned to: Nobody/Anonymous (nobody)
Summary: Does not easy_install on Snow Leopard

Initial Comment:
Installed /Library/Python/2.6/site-packages/pyobjc_framework_ScreenSaver-2.2b2-py2.6-macosx-10.6-universal.egg
Searching for pyobjc-framework-Quartz==2.2b2
Reading http://pypi.python.org/simple/pyobjc-framework-Quartz/
Best match: pyobjc-framework-Quartz 2.2b2
Downloading http://pypi.python.org/packages/source/p/pyobjc-framework-Quartz/pyobjc-framework-Quartz-2.2b2.tar.gz#md5=19fd563656931664acdce8296bd4844f
Processing pyobjc-framework-Quartz-2.2b2.tar.gz
Running pyobjc-framework-Quartz-2.2b2/setup.py -q bdist_egg --dist-dir /tmp/easy_install-jEe32c/pyobjc-framework-Quartz-2.2b2/egg-dist-tmp-ypxR3B
In file included from Modules/_CVPixelBuffer.m:5:
Modules/pyobjc-api.h:27:3: error: #error "Huh? 64-bit but no CFFloat available???"
In file included from //System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Headers/CGGeometry.h:8,
                 from //System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Headers/ATSTypes.h:32,
                 from //System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Headers/ATSLayoutTypes.h:36,
                 from //System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Headers/ATS.h:33,
                 from //System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:26,
                 from //System/Library/Frameworks/CoreVideo.framework/Headers/CVDisplayLink.h:24,
                 from //System/Library/Frameworks/CoreVideo.framework/Headers/CoreVideo.h:24,
                 from Modules/_CVPixelBuffer.m:9:
//System/Library/Frameworks/ApplicationServices.framework/Frameworks/CoreGraphics.framework/Headers/CGBase.h:105: error: conflicting types for 'CGFloat'
Modules/pyobjc-api.h:30: error: previous declaration of 'CGFloat' was here
lipo: can't open input file: /var/tmp//ccRZx2pw.out (No such file or directory)
error: Setup script exited with error: command 'gcc-4.2' failed with exit status 1


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

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

Re: [Pyobjc-dev] pyobjc status w.r.t. SL

[Nathan <nat...@gm...>]

On Tue, Sep 8, 2009 at 1:36 AM, Ronald Oussoren<ron...@ma...> wrote:
> Hi,
>
> I had hoped to finish the next 2.2 beta last weekend, but worked on CPython
> instead because there were some build-related issues with all Python
> versions on Snow Leopard.
>
> I need to finish three tasks before the next release:
> 1) Some of the CoreText testcases cause a hard crash
> 2) The Quartz bindings aren't completely done yet w.r.t SL support
> 3) We need to package the Xcode templates because Xcode no longer ships with
> PyObjC templates
>
> Ronald

Thanks for all your hard work.  :-)

~ Nathan