pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?

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

Hi Ronald,

A sample app that demonstrates the isolated issue is attached.  See  
the README.txt in the archive for a quick overview.

Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?

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

On Jun 23, 2009, at 10:55 AM, Ronald Oussoren wrote:

> Could you create a small application that demonstrates the problem?
> That would make testing on my side a lot easier.
>
> Ronald
>

I'll put something together later today and post it here.

Thanks :)

- Dirk

Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?

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

Dirk,

On 23 Jun, 2009, at 10:32, Dirk Stoop wrote:

> Hi Ronald,
>
> I use objc.IBOutlet() all over the place, so I've tried a couple of  
> things.

I just thought of an easier way to do this: before importing any  
PyObjC classes do: import objc; objc.IBOutlet = objc.ivar. I wonder  
why I didn't think of that earlier :-(

>
> Short summary is: It definitely changes behavior, but it doesn't  
> solve the problem.
>
> I've tried the following things:
>
> 1. Add an objc.ivar() definition (with the same name) after an  
> outlet definition to a top-level object that has an init method  
> implemented in Python.
> 2. Add an objc.ivar() definition (with the same name) after an  
> outlet definition to a top-level object that's a vanilla Cocoa class.
> 3. Add an objc.ivar() definition (again, the same name) after an  
> outlet definition to a non-top-level object that's implemented with  
> Python, but doesn't override the designated initializer.

Could you create a small application that demonstrates the problem?  
That would make testing on my side a lot easier.

Ronald

Re: [Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

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

On 23 Jun, 2009, at 10:48, Orestis Markou wrote:

> On 23 Jun 2009, at 11:36, Ronald Oussoren wrote:
>
>>
>> On 23 Jun, 2009, at 10:18, Brendan Simon (eTRIX) wrote:
>>
>>> Brendan Simon (eTRIX) wrote:
>>>> If IOKit support was added to PyObjC that would be really really
>>>> useful :)
>>> Errrr, as previously stated, IOKit is written in C so PyObjC is not
>>> relevant.  Sorry -- my bad.
>>
>> That's not quite true: IOKit seems to expose an CoreFoundation based
>> API, which is PyObjC territory.  It's rather unlikely that I'll get
>> around to adding IOKit support anytime soon though because I don't  
>> use
>> IOKit myself and adding support will be a lot of work.
>
> Is there a way to make ctypes and CF play together? I think that if
> this gets added to PyObjC then people needing to access low-level
> stuff from Python could do it themselves (for the bits they need).
> That's probably smaller in focus and more enabling than wrapping a C
> based framework that only a few people will use.

Accessing bit of CF from ctypes is not very hard (there is some code  
in Python2.6's urllib that does this). Making that interact properly  
with PyObjC is harder, and not something I've time to work on at the  
moment.

Ronald

Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?

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

On 23 Jun, 2009, at 10:32, Dirk Stoop wrote:

> Hi Ronald,
>
> I use objc.IBOutlet() all over the place, so I've tried a couple of
> things.
>
> Short summary is: It definitely changes behavior, but it doesn't solve
> the problem.

That's rather annoying.

BTW. The document that describes how outlets are managed: <http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/MemoryMgmt.pdf 
 >.

The document is rather vague on what happens when you don't have  
getter/setter methods (which you won't have when using
objc.IBOutlet()).  I'm pretty use an older document said that the NIB- 
loader will then set the instance variable without adjusting
reference counts.

I have to do some thinking on how to properly fix this, my best guess  
right now is to automaticly generate accessor methods for outlets in  
the ObjC class to ensure that the NIB loader will use a clearly  
defined mechanism to set references. The annoying bit is making sure  
that those accessor methods don't leak into the Python side, that  
would break a lot of existing code.

Ronald

Re: [Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

[Orestis M. <or...@or...>]

On 23 Jun 2009, at 11:36, Ronald Oussoren wrote:

>
> On 23 Jun, 2009, at 10:18, Brendan Simon (eTRIX) wrote:
>
>> Brendan Simon (eTRIX) wrote:
>>> If IOKit support was added to PyObjC that would be really really
>>> useful :)
>> Errrr, as previously stated, IOKit is written in C so PyObjC is not
>> relevant.  Sorry -- my bad.
>
> That's not quite true: IOKit seems to expose an CoreFoundation based
> API, which is PyObjC territory.  It's rather unlikely that I'll get
> around to adding IOKit support anytime soon though because I don't use
> IOKit myself and adding support will be a lot of work.

Is there a way to make ctypes and CF play together? I think that if  
this gets added to PyObjC then people needing to access low-level  
stuff from Python could do it themselves (for the bits they need).  
That's probably smaller in focus and more enabling than wrapping a C  
based framework that only a few people will use.

Re: [Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

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

On 23 Jun, 2009, at 10:18, Brendan Simon (eTRIX) wrote:

> Brendan Simon (eTRIX) wrote:
>> If IOKit support was added to PyObjC that would be really really  
>> useful :)
> Errrr, as previously stated, IOKit is written in C so PyObjC is not
> relevant.  Sorry -- my bad.

That's not quite true: IOKit seems to expose an CoreFoundation based  
API, which is PyObjC territory.  It's rather unlikely that I'll get  
around to adding IOKit support anytime soon though because I don't use  
IOKit myself and adding support will be a lot of work.

Ronald

>
>
> < 
> Brendan_Simon 
> .vcf 
> > 
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge  
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of  
> unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?

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

Hi Ronald,

I use objc.IBOutlet() all over the place, so I've tried a couple of  
things.

Short summary is: It definitely changes behavior, but it doesn't solve  
the problem.

I've tried the following things:

1. Add an objc.ivar() definition (with the same name) after an outlet  
definition to a top-level object that has an init method implemented  
in Python.
2. Add an objc.ivar() definition (with the same name) after an outlet  
definition to a top-level object that's a vanilla Cocoa class.
3. Add an objc.ivar() definition (again, the same name) after an  
outlet definition to a non-top-level object that's implemented with  
Python, but doesn't override the designated initializer.

The results are:

1. The object is now released properly without using my hacky  
workaround.
2. The object is over-released and the app crashes.
3. The object's dealloc method is called twice (I'm logging something  
in an overridden dealloc method in that class), but the app does not  
crash.

So, sadly, I'm afraid that objc.IBOutlet's special casing of memory  
management is still needed.

--

Aside from this, the bigger problem remains:

I don't necessarily have outlets to all top-level objects in all of my  
ViewController and WindowController classes. I have just re-affirmed  
that the same issue (top-level object not being released by view/ 
windowController if the object has been initialized through an init  
method implemented in python) happens with top-level objects that  
don't have an outlet connected to them.

Because to top-level objects that aren't connected to outlets are also  
not released properly (if their non-native init's have been called) I  
think that the issue doesn't have much to do with the implementation  
of objc.IBOutlet.

I'm guessing that NSViewController's and NSWindowController's internal  
dealloc methods call something akin to:

> [_topLevelObjects makeObjectsPerformSelector:@selector(release)];


And for some mysterious reason, this doesn't have the expected effect  
on objects that have been initialized in Python.  I am concerned that,  
without seeing what actually happens in NSView/WindowController, we  
can't do very much to fix this.

- Dirk

On Jun 20, 2009, at 6:39 PM, Ronald Oussoren wrote:

> Dirk,
>
> Do you have an 'outlet = objc.IBOutlet()' in your class definition? If
> so, could you test if the issue goes away if you do the following:
>
>    class MyClass (NSObject):
>        outlet = objc.IBOutlet()
>        outlet = objc.ivar()
>
> That is, duplicate all IBOutlet definitions with an objc.ivar
> definition in the same class definition below the IBOutlet  
> definitions.
>
> Objc.IBOutlet definitions are treated rather specially by PyObjC and I
> fairly recently read something about outlet handling on iPhone as
> compared to regular MacOSX that made me wonder if the way PyObjC
> handles outlets is correct.
>
> If the above hack fixes the memory leak you're seeing I'm going to
> write a unittest that displays the same behaviour and fix the issue
> (that last bit should be easy and would remove some code, which is
> always a good thing).
>
> Ronald
>
> On 19 Jun, 2009, at 13:53, Dirk Stoop wrote:
>
>> For anyone else who might be running into this top-level objects
>> thing, here's a workaround.
>>
>> I don't recommend anyone to put this to use in any production code,
>> but at least it's right now allowing me to go hunting for leaks
>> relatively reliably before this bug is fixed, or someone convinces
>> me it's not a bug. ;)
>>
>> ----------
>>
>> # my 'global' to switch this all off when the issue's been fixed
>>
>> CH_WORKAROUND_NON_NATIVE_INIT_TLOBJECTS = True
>>
>> ----------
>>
>> # in my viewController, identically also in my windowController
>>
>> class MyViewController(NSViewController):
>>   def dealloc(self):
>>       if not hasattr(self,
>> '_chWindowControllerRemoveObservationsCalled'):
>>           raise RuntimeError, 'Call to super(%s,
>> self).removeObservations() is MISSING in %s\'s removeObservations
>> implementation' % (self.className(), self.className())
>>
>>       if CH_WORKAROUND_NON_NATIVE_INIT_TLOBJECTS:
>>           topLevelObjects = objc.getInstanceVariable(self,
>> '_topLevelObjects')
>>           objectsToRelease = CHNonNativeInitializedObjectsInList_
>> (topLevelObjects)
>>           if len(objectsToRelease):
>>               NSLog(u'\tThe following objects with non-native init
>> methods will be released:')
>>           for o in objectsToRelease:
>>               NSLog(u'\t\t%s' % o)
>>               o.release()
>>
>>       super(MyViewController, self).dealloc()
>>
>> ----------
>>
>> # the method that filters the set of objects
>>
>> def CHNonNativeInitializedObjectsInList_(listOfObjects):
>>   """
>>   Iterates through the supplied listOfObjects, and returns the
>> subset of those
>>   that have an 'init*' method that's implemented in Python.
>>   """
>>   nonNativeInitObjects = []
>>
>>   for someObject in listOfObjects:
>>       hasNativeInit = True
>>       allAttributes = (a for a in dir(someObject) if a.startswith
>> ('init'))
>>       for attributeName in allAttributes:
>>           exec("method = someObject.%s" % attributeName)
>>           if hasattr(method, 'callable'):
>>               hasNativeInit = False
>>               break
>>       if not hasNativeInit:
>>           nonNativeInitObjects.append(someObject)
>>
>>   return nonNativeInitObjects
>>
>> ----------
>>
>> Once more, this is prone to breakage,
>> 1. since we're accessing the private ivar '_topLevelObjects', which
>> might be renamed at any time, although I doubt it will; hard to come
>> up with a better name for that needed private ivar..
>> 2. And of course, checking the entire dir(someObject) to look for
>> any attribute that starts with 'init' is pretty ridiculous too.
>>
>> But at least, I'm able to continue my hunt for memory leaks now,
>> plus I have a boolean that I can throw out the window when this
>> isn't needed anymore.
>>
>> Cheers,
>> - Dirk
>>
>>
>>
>> On Jun 19, 2009, at 12:06 PM, Dirk Stoop wrote:
>>
>>> Hi Ronald,
>>>
>>> Thanks for the clarification. :)
>>>
>>> I found another weird memory management quirk that might be related.
>>>
>>> Summary:
>>> Objects that implement the designated initializer are not
>>> automatically released as top-level objects in nibs owned by view-
>>> and
>>> windowcontrollers.
>>>
>>> Example:
>>> I have the following two classes:
>>>
>>> ----------------
>>> class SFTestViewVanilla(NSView):
>>>
>>>   def dealloc(self):
>>>       NSLog(u'yay, dealloc in %s' % self)
>>>       super(SFTestViewVanilla, self).dealloc()
>>>
>>> class SFTestViewWithInit(NSView):
>>>
>>>   def initWithFrame_(self, frame):
>>>       NSLog(u'initWithFrame_ called in %s' % self)
>>>       self = super(SFTestViewWithInit, self).initWithFrame_(frame)
>>>       if self:
>>>           pass
>>>       return self
>>>
>>>   def dealloc(self):
>>>       NSLog(u'yay, dealloc in %s' % self)
>>>       super(SFTestViewWithInit, self).dealloc()
>>> ----------------
>>>
>>> Instances of each of these have been put as top-level objects in a
>>> nib
>>> file that's owned by an NSViewController subclass.  Actually, to be
>>> entire correct, I dragged in 'custom views' and set the class of one
>>> of them to SFTestViewVanilla, and another one to SFTestViewWithInit.
>>> So those custom view placeholders are replaced with my custom
>>> subclasses when the nib is loaded, causing initWithFrame: to be
>>> called
>>> on both of them.
>>>
>>> When the CHViewController is released, the SFTestViewVanilla  
>>> instance
>>> is deallocced and produces a log entry, the SFTestViewWithInit
>>> instance however, is not being deallocced.  The only difference
>>> between both is the implementation of them pasted above.
>>>
>>> More Testing:
>>> I've also tried not assigning to self in SFTestViewWithInit's
>>> initWithFrame: implementation but that makes no difference  
>>> whatsover.
>>>
>>> As a next step of figuring stuff out: If I set up outlets to each,
>>> and
>>> check their retainCount in awakeFromNib, they both start out with a
>>> retainCount of 1.
>>>
>>> Initially I suspected that there's something weird going on with
>>> NSViewController's memory management of its top-level objects, if
>>> those objects are implemented in Python.  This weirdness however  
>>> only
>>> happens with objects that implement the designated initializer.   
>>> Next
>>> I've added these same views as top-level objects in a different nib
>>> that's owned by an NSWindowController subclass, where they exhibit
>>> the
>>> exact same behavior.  In both cases there are no outlets to the  
>>> views
>>> (just added those at some point to look at retainCounts for
>>> additional
>>> clues) and the views aren't part of any view hierarchy.
>>>
>>> The same seems to happen with other objects that have their own  
>>> init,
>>> like my NSArrayController subclass and other things that don't
>>> inherit
>>> from NSView. (I have not isolated that behavior yet, but from my
>>> app's
>>> code I suspect this is going on)
>>>
>>> Right now, I'm special casing every viewController's and
>>> windowController's dealloc to manually release these views, but I
>>> completely fail to understand why something is going haywire with  
>>> the
>>> 'automatic' releasing of top-level objects that NSViewController and
>>> NSWindowController are supposed to do..  This seems to be a bug,  
>>> that
>>> I'd rather fix in one spot than work around everywhere.
>>>
>>> I'd love to look into this and fix it myself, write a regression
>>> test,
>>> and submit a patch.  Could you help me out with some pointers on
>>> where
>>> to start looking in the PyObjC source?
>>>
>>> Thanks!
>>> - Dirk
>>>
>>> PS: I'm using pyobjc_core-2.2b2-py2.5, installed from a
>>> downloaded .tar from pypi.python.org, because installing from trunk
>>> didn't work out on my machine (10.5.7)
>>>
>>> On Jun 19, 2009, at 10:47 AM, Ronald Oussoren wrote:
>>>
>>>>
>>>> On 18 Jun, 2009, at 22:47, Orestis Markou wrote:
>>>>
>>>>> Hi Ronald,
>>>>>
>>>>> does that stand for other arbitrary class methods, like
>>>>> CALayer.layer
>>>>> () as well? Is there a way to inform PyObjC of constructor class
>>>>> methods? Or should we change our code to use alloc().init()
>>>>> instead?
>>>>
>>>> No. The only class methods that behave like  alloc are alloc itself
>>>> and anything that starts with 'new'. Regular class methods return
>>>> autoreleased objects.
>>>>
>>>> The behaviour of method names that start with 'new' is newish, the
>>>> last time I check (which was a couple of years ago), only +alloc
>>>> returned a retained value.
>>>>
>>>> Ronald
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>>> Check out the new simplified licensing option that enables  
>>>> unlimited
>>>> royalty-free distribution of the report engine for externally  
>>>> facing
>>>> server and web deployment.
>>>> http://p.sf.net/sfu/businessobjects
>>>> _______________________________________________
>>>> Pyobjc-dev mailing list
>>>> Pyo...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> Check out the new simplified licensing option that enables unlimited
>>> royalty-free distribution of the report engine for externally facing
>>> server and web deployment.
>>> http://p.sf.net/sfu/businessobjects
>>> _______________________________________________
>>> Pyobjc-dev mailing list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>
>
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge  
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of  
> unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

[Brendan S. (eTRIX) <Bre...@eT...>]

Brendan Simon (eTRIX) wrote:
> If IOKit support was added to PyObjC that would be really really useful :)
Errrr, as previously stated, IOKit is written in C so PyObjC is not
relevant.  Sorry -- my bad.

Re: [Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

[Brendan S. (eTRIX) <Bre...@eT...>]

Ronald Oussoren wrote:
> 
> On 23 Jun, 2009, at 3:23, Brendan Simon (eTRIX) wrote:
>> I had a quick look at ctypes and not sure if it can be used to access
>> ObjC variables, functions, etc.  I'm not sure if there is a way to build
>> a C (or C++) wrapper around the ObjC code and then use ctypes.  I
>> presume it's possible but it's getting complicated :(
> 
> Neither wrapping using ctypes nor wrapping using PyObjC will be easy. 
> You access functionality of "objects" from IOKit using function pointers
> in the "object" struct. That should be easy enough to write in ctypes,
> but PyObjC has no real support for that. On the other hand, PyObjC has
> support for CFString and other CoreFoundation types while ctypes hasn't.
> 
> BTW.  IOKit is not an Objective-C based framework, but is a plain C
> framework that makes use of CoreFoundation.


Thanks Ronald.

I've had a look at libusb-1.0.2 it is written in C and makes IOKit calls :)

PyUSB (0.x) uses ctypes to interface to libusb-0.1.12. PyUSB has just
started a new 1.0 branch to use libusb-1.x.y, and as such there is no
release yet.

So it seems that the best solution for me is to take the libusb code,
and either extend/modify it to provide the info I need.
I can use PyUSB or my own ctype interface to get a python interface.

So I think I will skip the PyObjC exercise for now, although I really
like the project.  If IOKit support was added to PyObjC that would be
really really useful :)

Thanks for everyone's help,
Brendan.

Re: [Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

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

On 23 Jun, 2009, at 3:23, Brendan Simon (eTRIX) wrote:
>
>
> I have made the assumption that anybody using PyObjC is probably
> familiar with Objective C and therefore familiar with OS X libraries  
> (as
> that's the most prevalent ObjC platform) -- possibly an optimistic
> assumption ???

I'd also expect that most members of this list are familiar with OSX  
libraries, but not with all libraries.  The IO Registry is a rather  
low-level library and I'd guess that most developers don't have to use  
it.    The set of libraries on OSX, or any modern platform, is rather  
huge and I'd expect that most developers have a superficial knowledge  
of what's available and more detailed knowledge of what they actually  
expect to use (I know that IOKit exists if I ever need to do low-level  
hardware access, but as I haven't needed that functionality  that's  
about it).

>
> I had a quick look at ctypes and not sure if it can be used to access
> ObjC variables, functions, etc.  I'm not sure if there is a way to  
> build
> a C (or C++) wrapper around the ObjC code and then use ctypes.  I
> presume it's possible but it's getting complicated :(

Neither wrapping using ctypes nor wrapping using PyObjC will be easy.   
You access functionality of "objects" from IOKit using function  
pointers in the "object" struct. That should be easy enough to write  
in ctypes, but PyObjC has no real support for that. On the other hand,  
PyObjC has support for CFString and other CoreFoundation types while  
ctypes hasn't.

BTW.  IOKit is not an Objective-C based framework, but is a plain C  
framework that makes use of CoreFoundation.

Ronald

Re: [Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

[Brendan S. (eTRIX) <Bre...@eT...>]

Hi Orestis,

Thanks for your response.

I believe that GetLocationID() -- from the IOUSBLib -- is what I need.
It simply takes a usb device handle and returns a unique integer which
represents the location of the usb device on the usb busses.

I beleive that GetLocationID() interrogates the IO Registry to obtain
and/or calculate the information.

I have made the assumption that anybody using PyObjC is probably
familiar with Objective C and therefore familiar with OS X libraries (as
that's the most prevalent ObjC platform) -- possibly an optimistic
assumption ???

I had a quick look at ctypes and not sure if it can be used to access
ObjC variables, functions, etc.  I'm not sure if there is a way to build
a C (or C++) wrapper around the ObjC code and then use ctypes.  I
presume it's possible but it's getting complicated :(

What's involved in loading 'the framework' ??
I don't mind loading the framework if it's not overly complicated and
there is not a big penalty (eg. too slow).

I think the USB stuff is part of the IOKit framework.

I've found this:
http://pyobjc.sourceforge.net/documentation/pyobjc-core/wrapping.html

The section 'the basics' seems to imply that I just need to have a file
called 'Myframework.py' and that's it (if no wrappers are required)
HUH ???
How does that work ???  Surely there must be some python or PyObjC code
to write ???

Again, thanks for any assistance,
Regards, Brendan.



Orestis Markou wrote:
> Hi Brendan,
> 
> I would advise that you first confirm (by reading the apple docs or by
> asking at the appropriate apple list) that GetLocationID does indeed do
> what you want it to. The I/O Kit documentation should point you to the
> right direction.
> 
> You are unlikely to receive answers about such esoteric stuff on this
> list, unless you strike gold and one of the members of the audience has
> experience with the inner workings of Mac OS X usb libs.
> 
> If you do find out that GetLocationID does what you want, you'd need to
> load the framework it's part of in PyObjC, as it's not already there. If
> that turns out to be too much of a bother (I think it might be), you can
> always try using ctypes, but I think you can't mix ctypes and PyObjC
> values together (in case you want to embed your code in a PyObjC app).
> 
> I *think* the above are accurate, but I'd love to be corrected if anyone
> has more accurate information.
> 
> Orestis
> -- 


> On 23 Jun 2009, at 00:25, Brendan Simon (eTRIX) wrote:
> 
>> I'm new to PyObjC (and Object C in general).
>>
>> I have a python application that accesses a USB device, and I want to
>> display the LocationID (like System Profiler and ioreg does).
>>
>> The LocationID seems to be OS X specific and not part of the standard
>> USB protocol and thus not part of PyUSB.
>>
>> So assuming OS X does not provide a python interface to IOUSBLib (please
>> let me know if it does), then I have to find a way to access it from
>> Python.  It would seem that PyObjC would be an appropriate method --
>> yes/no ???
>>
>> The header file IOUSBLib.h contains the function GetLocationID.
>>
>>    IOReturn (*GetLocationID)(void *self, UInt32 *locationID);
>>
>> Am I able to wrap this one function (or is it a method ?) easily with
>> PyObjC ??
>>
>> If it is easy, could someone provide some skeleton code for me to
>> work/play with.
>> If not so easy, could someone outline things that need to done and point
>> me to some appropriate doucmentation.
>>
>> Many thanks, Brendan (pyobjc newbie) :)

Re: [Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

[Brendan S. (eTRIX) <Bre...@eT...>]

Hi Orestis,

Thanks for your response.

I believe that GetLocationID() -- from the IOUSBLib -- is what I need.
It simply takes a usb device handle and returns a unique integer which
represents the location of the usb device on the usb busses.

I beleive that GetLocationID() interrogates the IO Registry to obtain
and/or calculate the information.

I have made the assumption that anybody using PyObjC is probably
familiar with Objective C and therefore familiar with OS X libraries (as
that's the most prevalent ObjC platform) -- possibly an optimistic
assumption ???

I had a quick look at ctypes and not sure if it can be used to access
ObjC variables, functions, etc.  I'm not sure if there is a way to build
a C (or C++) wrapper around the ObjC code and then use ctypes.  I
presume it's possible but it's getting complicated :(

What's involved in loading 'the framework' ??
I don't mind loading the framework if it's not overly complicated and
there is not a big penalty (eg. too slow).

I think the USB stuff is part of the IOKit framework.

I've found this:
http://pyobjc.sourceforge.net/documentation/pyobjc-core/wrapping.html

The section 'the basics' seems to imply that I just need to have a file
called 'Myframework.py' and that's it (if no wrappers are required)
HUH ???
How does that work ???  Surely there must be some python or PyObjC code
to write ???

Again, thanks for any assistance,
Regards, Brendan.



Orestis Markou wrote:
> Hi Brendan,
> 
> I would advise that you first confirm (by reading the apple docs or by
> asking at the appropriate apple list) that GetLocationID does indeed do
> what you want it to. The I/O Kit documentation should point you to the
> right direction.
> 
> You are unlikely to receive answers about such esoteric stuff on this
> list, unless you strike gold and one of the members of the audience has
> experience with the inner workings of Mac OS X usb libs.
> 
> If you do find out that GetLocationID does what you want, you'd need to
> load the framework it's part of in PyObjC, as it's not already there. If
> that turns out to be too much of a bother (I think it might be), you can
> always try using ctypes, but I think you can't mix ctypes and PyObjC
> values together (in case you want to embed your code in a PyObjC app).
> 
> I *think* the above are accurate, but I'd love to be corrected if anyone
> has more accurate information.
> 
> Orestis
> -- 


> On 23 Jun 2009, at 00:25, Brendan Simon (eTRIX) wrote:
> 
>> I'm new to PyObjC (and Object C in general).
>>
>> I have a python application that accesses a USB device, and I want to
>> display the LocationID (like System Profiler and ioreg does).
>>
>> The LocationID seems to be OS X specific and not part of the standard
>> USB protocol and thus not part of PyUSB.
>>
>> So assuming OS X does not provide a python interface to IOUSBLib (please
>> let me know if it does), then I have to find a way to access it from
>> Python.  It would seem that PyObjC would be an appropriate method --
>> yes/no ???
>>
>> The header file IOUSBLib.h contains the function GetLocationID.
>>
>>    IOReturn (*GetLocationID)(void *self, UInt32 *locationID);
>>
>> Am I able to wrap this one function (or is it a method ?) easily with
>> PyObjC ??
>>
>> If it is easy, could someone provide some skeleton code for me to
>> work/play with.
>> If not so easy, could someone outline things that need to done and point
>> me to some appropriate doucmentation.
>>
>> Many thanks, Brendan (pyobjc newbie) :)

Re: [Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

[Orestis M. <or...@or...>]

Hi Brendan,

I would advise that you first confirm (by reading the apple docs or by  
asking at the appropriate apple list) that GetLocationID does indeed  
do what you want it to. The I/O Kit documentation should point you to  
the right direction.

You are unlikely to receive answers about such esoteric stuff on this  
list, unless you strike gold and one of the members of the audience  
has experience with the inner workings of Mac OS X usb libs.

If you do find out that GetLocationID does what you want, you'd need  
to load the framework it's part of in PyObjC, as it's not already  
there. If that turns out to be too much of a bother (I think it might  
be), you can always try using ctypes, but I think you can't mix ctypes  
and PyObjC values together (in case you want to embed your code in a  
PyObjC app).

I *think* the above are accurate, but I'd love to be corrected if  
anyone has more accurate information.

Orestis
--
or...@or...
http://orestis.gr/




On 23 Jun 2009, at 00:25, Brendan Simon (eTRIX) wrote:

> I'm new to PyObjC (and Object C in general).
>
> I have a python application that accesses a USB device, and I want to
> display the LocationID (like System Profiler and ioreg does).
>
> The LocationID seems to be OS X specific and not part of the standard
> USB protocol and thus not part of PyUSB.
>
> So assuming OS X does not provide a python interface to IOUSBLib  
> (please
> let me know if it does), then I have to find a way to access it from
> Python.  It would seem that PyObjC would be an appropriate method --
> yes/no ???
>
> The header file IOUSBLib.h contains the function GetLocationID.
>
>    IOReturn (*GetLocationID)(void *self, UInt32 *locationID);
>
> Am I able to wrap this one function (or is it a method ?) easily with
> PyObjC ??
>
> If it is easy, could someone provide some skeleton code for me to
> work/play with.
> If not so easy, could someone outline things that need to done and  
> point
> me to some appropriate doucmentation.
>
> Many thanks, Brendan (pyobjc newbie) :)
>
> < 
> Brendan_Simon 
> .vcf 
> > 
> ------------------------------------------------------------------------------
> Are you an open source citizen? Join us for the Open Source Bridge  
> conference!
> Portland, OR, June 17-19. Two days of sessions, one day of  
> unconference: $250.
> Need another reason to go? 24-hour hacker lounge. Register today!
> http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Wrapping GetLocationID from IOUSBLib

[Brendan S. (eTRIX) <Bre...@eT...>]

I'm new to PyObjC (and Object C in general).

I have a python application that accesses a USB device, and I want to
display the LocationID (like System Profiler and ioreg does).

The LocationID seems to be OS X specific and not part of the standard
USB protocol and thus not part of PyUSB.

So assuming OS X does not provide a python interface to IOUSBLib (please
let me know if it does), then I have to find a way to access it from
Python.  It would seem that PyObjC would be an appropriate method --
yes/no ???

The header file IOUSBLib.h contains the function GetLocationID.

    IOReturn (*GetLocationID)(void *self, UInt32 *locationID);

Am I able to wrap this one function (or is it a method ?) easily with
PyObjC ??

If it is easy, could someone provide some skeleton code for me to
work/play with.
If not so easy, could someone outline things that need to done and point
me to some appropriate doucmentation.

Many thanks, Brendan (pyobjc newbie) :)

Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?

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

Dirk,

Do you have an 'outlet = objc.IBOutlet()' in your class definition? If  
so, could you test if the issue goes away if you do the following:

    class MyClass (NSObject):
        outlet = objc.IBOutlet()
        outlet = objc.ivar()

That is, duplicate all IBOutlet definitions with an objc.ivar  
definition in the same class definition below the IBOutlet definitions.

Objc.IBOutlet definitions are treated rather specially by PyObjC and I  
fairly recently read something about outlet handling on iPhone as  
compared to regular MacOSX that made me wonder if the way PyObjC  
handles outlets is correct.

If the above hack fixes the memory leak you're seeing I'm going to  
write a unittest that displays the same behaviour and fix the issue  
(that last bit should be easy and would remove some code, which is  
always a good thing).

Ronald

On 19 Jun, 2009, at 13:53, Dirk Stoop wrote:

> For anyone else who might be running into this top-level objects  
> thing, here's a workaround.
>
> I don't recommend anyone to put this to use in any production code,  
> but at least it's right now allowing me to go hunting for leaks  
> relatively reliably before this bug is fixed, or someone convinces  
> me it's not a bug. ;)
>
> ----------
>
> # my 'global' to switch this all off when the issue's been fixed
>
> CH_WORKAROUND_NON_NATIVE_INIT_TLOBJECTS = True
>
> ----------
>
> # in my viewController, identically also in my windowController
>
> class MyViewController(NSViewController):
>    def dealloc(self):
>        if not hasattr(self,  
> '_chWindowControllerRemoveObservationsCalled'):
>            raise RuntimeError, 'Call to super(%s,  
> self).removeObservations() is MISSING in %s\'s removeObservations  
> implementation' % (self.className(), self.className())
>
>        if CH_WORKAROUND_NON_NATIVE_INIT_TLOBJECTS:
>            topLevelObjects = objc.getInstanceVariable(self,  
> '_topLevelObjects')
>            objectsToRelease = CHNonNativeInitializedObjectsInList_ 
> (topLevelObjects)
>            if len(objectsToRelease):
>                NSLog(u'\tThe following objects with non-native init  
> methods will be released:')
>            for o in objectsToRelease:
>                NSLog(u'\t\t%s' % o)
>                o.release()
>
>        super(MyViewController, self).dealloc()
>
> ----------
>
> # the method that filters the set of objects
>
> def CHNonNativeInitializedObjectsInList_(listOfObjects):
>    """
>    Iterates through the supplied listOfObjects, and returns the  
> subset of those
>    that have an 'init*' method that's implemented in Python.
>    """
>    nonNativeInitObjects = []
>
>    for someObject in listOfObjects:
>        hasNativeInit = True
>        allAttributes = (a for a in dir(someObject) if a.startswith 
> ('init'))
>        for attributeName in allAttributes:
>            exec("method = someObject.%s" % attributeName)
>            if hasattr(method, 'callable'):
>                hasNativeInit = False
>                break
>        if not hasNativeInit:
>            nonNativeInitObjects.append(someObject)
>
>    return nonNativeInitObjects
>
> ----------
>
> Once more, this is prone to breakage,
> 1. since we're accessing the private ivar '_topLevelObjects', which  
> might be renamed at any time, although I doubt it will; hard to come  
> up with a better name for that needed private ivar..
> 2. And of course, checking the entire dir(someObject) to look for  
> any attribute that starts with 'init' is pretty ridiculous too.
>
> But at least, I'm able to continue my hunt for memory leaks now,  
> plus I have a boolean that I can throw out the window when this  
> isn't needed anymore.
>
> Cheers,
> - Dirk
>
>
>
> On Jun 19, 2009, at 12:06 PM, Dirk Stoop wrote:
>
>> Hi Ronald,
>>
>> Thanks for the clarification. :)
>>
>> I found another weird memory management quirk that might be related.
>>
>> Summary:
>> Objects that implement the designated initializer are not
>> automatically released as top-level objects in nibs owned by view-  
>> and
>> windowcontrollers.
>>
>> Example:
>> I have the following two classes:
>>
>> ----------------
>> class SFTestViewVanilla(NSView):
>>
>>    def dealloc(self):
>>        NSLog(u'yay, dealloc in %s' % self)
>>        super(SFTestViewVanilla, self).dealloc()
>>
>> class SFTestViewWithInit(NSView):
>>
>>    def initWithFrame_(self, frame):
>>        NSLog(u'initWithFrame_ called in %s' % self)
>>        self = super(SFTestViewWithInit, self).initWithFrame_(frame)
>>        if self:
>>            pass
>>        return self
>>
>>    def dealloc(self):
>>        NSLog(u'yay, dealloc in %s' % self)
>>        super(SFTestViewWithInit, self).dealloc()
>> ----------------
>>
>> Instances of each of these have been put as top-level objects in a  
>> nib
>> file that's owned by an NSViewController subclass.  Actually, to be
>> entire correct, I dragged in 'custom views' and set the class of one
>> of them to SFTestViewVanilla, and another one to SFTestViewWithInit.
>> So those custom view placeholders are replaced with my custom
>> subclasses when the nib is loaded, causing initWithFrame: to be  
>> called
>> on both of them.
>>
>> When the CHViewController is released, the SFTestViewVanilla instance
>> is deallocced and produces a log entry, the SFTestViewWithInit
>> instance however, is not being deallocced.  The only difference
>> between both is the implementation of them pasted above.
>>
>> More Testing:
>> I've also tried not assigning to self in SFTestViewWithInit's
>> initWithFrame: implementation but that makes no difference whatsover.
>>
>> As a next step of figuring stuff out: If I set up outlets to each,  
>> and
>> check their retainCount in awakeFromNib, they both start out with a
>> retainCount of 1.
>>
>> Initially I suspected that there's something weird going on with
>> NSViewController's memory management of its top-level objects, if
>> those objects are implemented in Python.  This weirdness however only
>> happens with objects that implement the designated initializer.  Next
>> I've added these same views as top-level objects in a different nib
>> that's owned by an NSWindowController subclass, where they exhibit  
>> the
>> exact same behavior.  In both cases there are no outlets to the views
>> (just added those at some point to look at retainCounts for  
>> additional
>> clues) and the views aren't part of any view hierarchy.
>>
>> The same seems to happen with other objects that have their own init,
>> like my NSArrayController subclass and other things that don't  
>> inherit
>> from NSView. (I have not isolated that behavior yet, but from my  
>> app's
>> code I suspect this is going on)
>>
>> Right now, I'm special casing every viewController's and
>> windowController's dealloc to manually release these views, but I
>> completely fail to understand why something is going haywire with the
>> 'automatic' releasing of top-level objects that NSViewController and
>> NSWindowController are supposed to do..  This seems to be a bug, that
>> I'd rather fix in one spot than work around everywhere.
>>
>> I'd love to look into this and fix it myself, write a regression  
>> test,
>> and submit a patch.  Could you help me out with some pointers on  
>> where
>> to start looking in the PyObjC source?
>>
>> Thanks!
>> - Dirk
>>
>> PS: I'm using pyobjc_core-2.2b2-py2.5, installed from a
>> downloaded .tar from pypi.python.org, because installing from trunk
>> didn't work out on my machine (10.5.7)
>>
>> On Jun 19, 2009, at 10:47 AM, Ronald Oussoren wrote:
>>
>>>
>>> On 18 Jun, 2009, at 22:47, Orestis Markou wrote:
>>>
>>>> Hi Ronald,
>>>>
>>>> does that stand for other arbitrary class methods, like  
>>>> CALayer.layer
>>>> () as well? Is there a way to inform PyObjC of constructor class
>>>> methods? Or should we change our code to use alloc().init()  
>>>> instead?
>>>
>>> No. The only class methods that behave like  alloc are alloc itself
>>> and anything that starts with 'new'. Regular class methods return
>>> autoreleased objects.
>>>
>>> The behaviour of method names that start with 'new' is newish, the
>>> last time I check (which was a couple of years ago), only +alloc
>>> returned a retained value.
>>>
>>> Ronald
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> Check out the new simplified licensing option that enables unlimited
>>> royalty-free distribution of the report engine for externally facing
>>> server and web deployment.
>>> http://p.sf.net/sfu/businessobjects
>>> _______________________________________________
>>> Pyobjc-dev mailing list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?

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

For anyone else who might be running into this top-level objects  
thing, here's a workaround.

I don't recommend anyone to put this to use in any production code,  
but at least it's right now allowing me to go hunting for leaks  
relatively reliably before this bug is fixed, or someone convinces me  
it's not a bug. ;)

----------

# my 'global' to switch this all off when the issue's been fixed

CH_WORKAROUND_NON_NATIVE_INIT_TLOBJECTS = True

----------

# in my viewController, identically also in my windowController

class MyViewController(NSViewController):
     def dealloc(self):
         if not hasattr(self,  
'_chWindowControllerRemoveObservationsCalled'):
             raise RuntimeError, 'Call to super(%s,  
self).removeObservations() is MISSING in %s\'s removeObservations  
implementation' % (self.className(), self.className())

         if CH_WORKAROUND_NON_NATIVE_INIT_TLOBJECTS:
             topLevelObjects = objc.getInstanceVariable(self,  
'_topLevelObjects')
             objectsToRelease =  
CHNonNativeInitializedObjectsInList_(topLevelObjects)
             if len(objectsToRelease):
                 NSLog(u'\tThe following objects with non-native init  
methods will be released:')
             for o in objectsToRelease:
                 NSLog(u'\t\t%s' % o)
                 o.release()

         super(MyViewController, self).dealloc()

----------

# the method that filters the set of objects

def CHNonNativeInitializedObjectsInList_(listOfObjects):
     """
     Iterates through the supplied listOfObjects, and returns the  
subset of those
     that have an 'init*' method that's implemented in Python.
     """
     nonNativeInitObjects = []

     for someObject in listOfObjects:
         hasNativeInit = True
         allAttributes = (a for a in dir(someObject) if  
a.startswith('init'))
         for attributeName in allAttributes:
             exec("method = someObject.%s" % attributeName)
             if hasattr(method, 'callable'):
                 hasNativeInit = False
                 break
         if not hasNativeInit:
             nonNativeInitObjects.append(someObject)

     return nonNativeInitObjects

----------

Once more, this is prone to breakage,
1. since we're accessing the private ivar '_topLevelObjects', which  
might be renamed at any time, although I doubt it will; hard to come  
up with a better name for that needed private ivar..
2. And of course, checking the entire dir(someObject) to look for any  
attribute that starts with 'init' is pretty ridiculous too.

But at least, I'm able to continue my hunt for memory leaks now, plus  
I have a boolean that I can throw out the window when this isn't  
needed anymore.

Cheers,
- Dirk



On Jun 19, 2009, at 12:06 PM, Dirk Stoop wrote:

> Hi Ronald,
>
> Thanks for the clarification. :)
>
> I found another weird memory management quirk that might be related.
>
> Summary:
> Objects that implement the designated initializer are not
> automatically released as top-level objects in nibs owned by view- and
> windowcontrollers.
>
> Example:
> I have the following two classes:
>
> ----------------
> class SFTestViewVanilla(NSView):
>
>     def dealloc(self):
>         NSLog(u'yay, dealloc in %s' % self)
>         super(SFTestViewVanilla, self).dealloc()
>
> class SFTestViewWithInit(NSView):
>
>     def initWithFrame_(self, frame):
>         NSLog(u'initWithFrame_ called in %s' % self)
>         self = super(SFTestViewWithInit, self).initWithFrame_(frame)
>         if self:
>             pass
>         return self
>
>     def dealloc(self):
>         NSLog(u'yay, dealloc in %s' % self)
>         super(SFTestViewWithInit, self).dealloc()
> ----------------
>
> Instances of each of these have been put as top-level objects in a nib
> file that's owned by an NSViewController subclass.  Actually, to be
> entire correct, I dragged in 'custom views' and set the class of one
> of them to SFTestViewVanilla, and another one to SFTestViewWithInit.
> So those custom view placeholders are replaced with my custom
> subclasses when the nib is loaded, causing initWithFrame: to be called
> on both of them.
>
> When the CHViewController is released, the SFTestViewVanilla instance
> is deallocced and produces a log entry, the SFTestViewWithInit
> instance however, is not being deallocced.  The only difference
> between both is the implementation of them pasted above.
>
> More Testing:
> I've also tried not assigning to self in SFTestViewWithInit's
> initWithFrame: implementation but that makes no difference whatsover.
>
> As a next step of figuring stuff out: If I set up outlets to each, and
> check their retainCount in awakeFromNib, they both start out with a
> retainCount of 1.
>
> Initially I suspected that there's something weird going on with
> NSViewController's memory management of its top-level objects, if
> those objects are implemented in Python.  This weirdness however only
> happens with objects that implement the designated initializer.  Next
> I've added these same views as top-level objects in a different nib
> that's owned by an NSWindowController subclass, where they exhibit the
> exact same behavior.  In both cases there are no outlets to the views
> (just added those at some point to look at retainCounts for additional
> clues) and the views aren't part of any view hierarchy.
>
> The same seems to happen with other objects that have their own init,
> like my NSArrayController subclass and other things that don't inherit
> from NSView. (I have not isolated that behavior yet, but from my app's
> code I suspect this is going on)
>
> Right now, I'm special casing every viewController's and
> windowController's dealloc to manually release these views, but I
> completely fail to understand why something is going haywire with the
> 'automatic' releasing of top-level objects that NSViewController and
> NSWindowController are supposed to do..  This seems to be a bug, that
> I'd rather fix in one spot than work around everywhere.
>
> I'd love to look into this and fix it myself, write a regression test,
> and submit a patch.  Could you help me out with some pointers on where
> to start looking in the PyObjC source?
>
> Thanks!
> - Dirk
>
> PS: I'm using pyobjc_core-2.2b2-py2.5, installed from a
> downloaded .tar from pypi.python.org, because installing from trunk
> didn't work out on my machine (10.5.7)
>
> On Jun 19, 2009, at 10:47 AM, Ronald Oussoren wrote:
>
>>
>> On 18 Jun, 2009, at 22:47, Orestis Markou wrote:
>>
>>> Hi Ronald,
>>>
>>> does that stand for other arbitrary class methods, like  
>>> CALayer.layer
>>> () as well? Is there a way to inform PyObjC of constructor class
>>> methods? Or should we change our code to use alloc().init() instead?
>>
>> No. The only class methods that behave like  alloc are alloc itself
>> and anything that starts with 'new'. Regular class methods return
>> autoreleased objects.
>>
>> The behaviour of method names that start with 'new' is newish, the
>> last time I check (which was a couple of years ago), only +alloc
>> returned a retained value.
>>
>> Ronald
>>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Memory management bug using .new() -- and another one?

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

Hi Ronald,

Thanks for the clarification. :)

I found another weird memory management quirk that might be related.

Summary:
Objects that implement the designated initializer are not  
automatically released as top-level objects in nibs owned by view- and  
windowcontrollers.

Example:
I have the following two classes:

----------------
class SFTestViewVanilla(NSView):

     def dealloc(self):
         NSLog(u'yay, dealloc in %s' % self)
         super(SFTestViewVanilla, self).dealloc()

class SFTestViewWithInit(NSView):

     def initWithFrame_(self, frame):
         NSLog(u'initWithFrame_ called in %s' % self)
         self = super(SFTestViewWithInit, self).initWithFrame_(frame)
         if self:
             pass
         return self

     def dealloc(self):
         NSLog(u'yay, dealloc in %s' % self)
         super(SFTestViewWithInit, self).dealloc()
----------------

Instances of each of these have been put as top-level objects in a nib  
file that's owned by an NSViewController subclass.  Actually, to be  
entire correct, I dragged in 'custom views' and set the class of one  
of them to SFTestViewVanilla, and another one to SFTestViewWithInit.   
So those custom view placeholders are replaced with my custom  
subclasses when the nib is loaded, causing initWithFrame: to be called  
on both of them.

When the CHViewController is released, the SFTestViewVanilla instance  
is deallocced and produces a log entry, the SFTestViewWithInit  
instance however, is not being deallocced.  The only difference  
between both is the implementation of them pasted above.

More Testing:
I've also tried not assigning to self in SFTestViewWithInit's  
initWithFrame: implementation but that makes no difference whatsover.

As a next step of figuring stuff out: If I set up outlets to each, and  
check their retainCount in awakeFromNib, they both start out with a  
retainCount of 1.

Initially I suspected that there's something weird going on with  
NSViewController's memory management of its top-level objects, if  
those objects are implemented in Python.  This weirdness however only  
happens with objects that implement the designated initializer.  Next  
I've added these same views as top-level objects in a different nib  
that's owned by an NSWindowController subclass, where they exhibit the  
exact same behavior.  In both cases there are no outlets to the views  
(just added those at some point to look at retainCounts for additional  
clues) and the views aren't part of any view hierarchy.

The same seems to happen with other objects that have their own init,  
like my NSArrayController subclass and other things that don't inherit  
from NSView. (I have not isolated that behavior yet, but from my app's  
code I suspect this is going on)

Right now, I'm special casing every viewController's and  
windowController's dealloc to manually release these views, but I  
completely fail to understand why something is going haywire with the  
'automatic' releasing of top-level objects that NSViewController and  
NSWindowController are supposed to do..  This seems to be a bug, that  
I'd rather fix in one spot than work around everywhere.

I'd love to look into this and fix it myself, write a regression test,  
and submit a patch.  Could you help me out with some pointers on where  
to start looking in the PyObjC source?

Thanks!
- Dirk

PS: I'm using pyobjc_core-2.2b2-py2.5, installed from a  
downloaded .tar from pypi.python.org, because installing from trunk  
didn't work out on my machine (10.5.7)

On Jun 19, 2009, at 10:47 AM, Ronald Oussoren wrote:

>
> On 18 Jun, 2009, at 22:47, Orestis Markou wrote:
>
>> Hi Ronald,
>>
>> does that stand for other arbitrary class methods, like CALayer.layer
>> () as well? Is there a way to inform PyObjC of constructor class
>> methods? Or should we change our code to use alloc().init() instead?
>
> No. The only class methods that behave like  alloc are alloc itself
> and anything that starts with 'new'. Regular class methods return
> autoreleased objects.
>
> The behaviour of method names that start with 'new' is newish, the
> last time I check (which was a couple of years ago), only +alloc
> returned a retained value.
>
> Ronald
>
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Memory management bug using .new()

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

On 18 Jun, 2009, at 22:47, Orestis Markou wrote:

> Hi Ronald,
>
> does that stand for other arbitrary class methods, like CALayer.layer 
> () as well? Is there a way to inform PyObjC of constructor class  
> methods? Or should we change our code to use alloc().init() instead?

No. The only class methods that behave like  alloc are alloc itself  
and anything that starts with 'new'. Regular class methods return  
autoreleased objects.

The behaviour of method names that start with 'new' is newish, the  
last time I check (which was a couple of years ago), only +alloc  
returned a retained value.

Ronald

Re: [Pyobjc-dev] how to install pyobjc in Linux

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

On 16 Jun, 2009, at 18:48, James R Eagan wrote:

> Hi Matias,
>
> Unfortunately, PyObjC only runs on the Mac.  There was some effort  
> to get PyObjC working in a GNUStep environment, but that seems to  
> have been stalled for quite some time.

All support code for GNUstep was removed during the port to Leopard.   
Nobody is interested enough in GNUstep support to make it happen and  
having a 10% solution gave people the impression that GNUstep support  
was easy to add.

>
> Furthermore, PyObjC does not run on a standard, non-jailbroken  
> iPhone.  (It does run on jailbroken models, however, but again,  
> you'll need a Mac for your development machine.)

Someone did port PyObjC to jail-broken iPhones, but that port is not  
part of the PyObjC repository and I'm not interested in adding it  
because I am not able to test this and would likely break that port  
during the regular development of PyObjC on MacOSX.

Ronald

>
> Cheers!
> James
>
> Le 16 juin 09 à 18:04, Matias Hernandez Arellano a écrit :
>
>> Hi list..
>> first sorry for my english xD..
>>
>> I was trying to install pyobjc in my linux machine to try to build
>> little applications to iphone/ipod touch xD...
>> i get the svn source (a lot of folders of frameworks)
>> but i can't install them, i searching in the list of erros i and i  
>> see
>> errros with gcc, well this erros was for the CF.. i try to install CF
>> but i can't get it.. and without this i cant run pyobjc no?
>>
>> Someone know how i can do this?
>>
>> Thanks in advance
>>
>> -- 
>> Matias Hernández (Msdark)
>> www.msdark.archlinux.cl
>> ArchLinux-CL - WikiAdmin
>> MSN: mat...@gm...
>> Twitter : www.twitter.com/msdark
>> Plurk   : www.plurk.com/msdark
>> Linux User: #445065
>> http://keys.gnupg.net/pks/lookup?op=get&search=0xEA3EEC672189419C
>>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Using kAuthorizationFlagExtendRights

[Philip R. <phi...@ya...>]

I've been hunting for the answer to this for a bit.  The auth  
framework was created for 10.2, is this still the best way to use the  
framework?

Philip

Re: [Pyobjc-dev] Memory management bug using .new()

[Orestis M. <or...@or...>]

Hi Ronald,

does that stand for other arbitrary class methods, like  
CALayer.layer() as well? Is there a way to inform PyObjC of  
constructor class methods? Or should we change our code to use  
alloc().init() instead?

Thanks,
Orestis




On 18 Jun 2009, at 23:41, Ronald Oussoren wrote:

> This is a buglet in pyobjc, it doesn't know +new is like +alloc. The  
> reason for this is historical, once upon a time
> Pyobjc's behaviour was correct but that is no longer true as I  
> recently learned.
>
> This will be fixed in a future release, which will probably be in  
> September.
>
> Ronald
>
>
> On 18 jun 2009, at 21:19, Orestis Markou <or...@or...> wrote:
>
>> That's interesting, we are seeing similar behaviour to other
>> classmethods that do this (eg. CALayer.layer()), but so far I chalked
>> it up to our fault. Perhaps it's the same issue?
>>
>> Orestis
>>
>>
>>
>> On 18 Jun 2009, at 16:54, Dirk Stoop wrote:
>>
>>> Hi all,
>>>
>>> I don't think anyone ever uses this method – NSObject.new() –  
>>> anymore,
>>> but in case someone does: I just ran into a reproducable problem  
>>> with
>>> it.
>>>
>>> When you create a new cocoa object within an instance method of a
>>> Cocoa class implemented in Python, normally that fresh object is
>>> released when the scope dissapears. (that is, when you're not  
>>> storing
>>> a reference to it in an attribute that exists outside of the  
>>> method's
>>> scope).
>>>
>>> e.g.:
>>>
>>> class MyAmazingViewController(NSViewController):
>>>   def animate(self):
>>>       animation = NSViewAnimation.alloc().init()
>>>       # insert code to create an array/list of NSDictionaries
>>> describing the animations
>>>
>>> animation.setViewAnimations_(theAboveMentionedHypotheticalArray)
>>>       animation.setDuration_(5.0)
>>>       animation.setAnimationBlockingMode_(NSAnimationNonblocking)
>>>       animation.startAnimation()
>>>
>>> ( if the spaces got stripped from my example somehow, snippet also
>>> pasted here: http://pastie.org/516369 )
>>>
>>> After control returns from the "animate" method, and after the
>>> animation is done, it is automatically released.
>>>
>>> However if you replace "NSViewAnimation.alloc().init()", with
>>> "NSViewAnimation.new()", the animation is not automatically  
>>> released.
>>> Consequentially, any views or windows included in the dictionaries
>>> that form the viewAnimations array are also retained, causing  
>>> quite a
>>> significant leak.
>>>
>>> Juding from the NSObject class docs, calling "new()" on a class  
>>> should
>>> do exactly the same thing as "alloc().init()", but PyObjC doesn't  
>>> seem
>>> to treat it the same way.
>>>
>>> http://tinyurl.com/nsobject-new
>>>
>>> Can anyone enlighten me whether this is a bug, a feature, or simply
>>> something I'm misunderstanding?
>>>
>>> Thanks!
>>> - Dirk
>>> ------------------------------------------------------------------------------
>>> Crystal Reports - New Free Runtime and 30 Day Trial
>>> Check out the new simplified licensing option that enables unlimited
>>> royalty-free distribution of the report engine for externally facing
>>> server and web deployment.
>>> http://p.sf.net/sfu/businessobjects
>>> _______________________________________________
>>> Pyobjc-dev mailing list
>>> Pyo...@li...
>>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
>> ------------------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Memory management bug using .new()

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

This is a buglet in pyobjc, it doesn't know +new is like +alloc. The  
reason for this is historical, once upon a time
Pyobjc's behaviour was correct but that is no longer true as I  
recently learned.

This will be fixed in a future release, which will probably be in  
September.

Ronald


On 18 jun 2009, at 21:19, Orestis Markou <or...@or...> wrote:

> That's interesting, we are seeing similar behaviour to other
> classmethods that do this (eg. CALayer.layer()), but so far I chalked
> it up to our fault. Perhaps it's the same issue?
>
> Orestis
>
>
>
> On 18 Jun 2009, at 16:54, Dirk Stoop wrote:
>
>> Hi all,
>>
>> I don't think anyone ever uses this method – NSObject.new() –  
>> anymore,
>> but in case someone does: I just ran into a reproducable problem with
>> it.
>>
>> When you create a new cocoa object within an instance method of a
>> Cocoa class implemented in Python, normally that fresh object is
>> released when the scope dissapears. (that is, when you're not storing
>> a reference to it in an attribute that exists outside of the method's
>> scope).
>>
>> e.g.:
>>
>> class MyAmazingViewController(NSViewController):
>>    def animate(self):
>>        animation = NSViewAnimation.alloc().init()
>>        # insert code to create an array/list of NSDictionaries
>> describing the animations
>>
>> animation.setViewAnimations_(theAboveMentionedHypotheticalArray)
>>        animation.setDuration_(5.0)
>>        animation.setAnimationBlockingMode_(NSAnimationNonblocking)
>>        animation.startAnimation()
>>
>> ( if the spaces got stripped from my example somehow, snippet also
>> pasted here: http://pastie.org/516369 )
>>
>> After control returns from the "animate" method, and after the
>> animation is done, it is automatically released.
>>
>> However if you replace "NSViewAnimation.alloc().init()", with
>> "NSViewAnimation.new()", the animation is not automatically released.
>> Consequentially, any views or windows included in the dictionaries
>> that form the viewAnimations array are also retained, causing quite a
>> significant leak.
>>
>> Juding from the NSObject class docs, calling "new()" on a class  
>> should
>> do exactly the same thing as "alloc().init()", but PyObjC doesn't  
>> seem
>> to treat it the same way.
>>
>> http://tinyurl.com/nsobject-new
>>
>> Can anyone enlighten me whether this is a bug, a feature, or simply
>> something I'm misunderstanding?
>>
>> Thanks!
>> - Dirk
>> --- 
>> --- 
>> --- 
>> ---------------------------------------------------------------------
>> Crystal Reports - New Free Runtime and 30 Day Trial
>> Check out the new simplified licensing option that enables unlimited
>> royalty-free distribution of the report engine for externally facing
>> server and web deployment.
>> http://p.sf.net/sfu/businessobjects
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
> --- 
> --- 
> --- 
> ---------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Memory management bug using .new()

[Orestis M. <or...@or...>]

That's interesting, we are seeing similar behaviour to other  
classmethods that do this (eg. CALayer.layer()), but so far I chalked  
it up to our fault. Perhaps it's the same issue?

Orestis



On 18 Jun 2009, at 16:54, Dirk Stoop wrote:

> Hi all,
>
> I don't think anyone ever uses this method – NSObject.new() – anymore,
> but in case someone does: I just ran into a reproducable problem with
> it.
>
> When you create a new cocoa object within an instance method of a
> Cocoa class implemented in Python, normally that fresh object is
> released when the scope dissapears. (that is, when you're not storing
> a reference to it in an attribute that exists outside of the method's
> scope).
>
> e.g.:
>
> class MyAmazingViewController(NSViewController):
>     def animate(self):
>         animation = NSViewAnimation.alloc().init()
>         # insert code to create an array/list of NSDictionaries
> describing the animations
>
> animation.setViewAnimations_(theAboveMentionedHypotheticalArray)
>         animation.setDuration_(5.0)
>         animation.setAnimationBlockingMode_(NSAnimationNonblocking)
>         animation.startAnimation()
>
> ( if the spaces got stripped from my example somehow, snippet also
> pasted here: http://pastie.org/516369 )
>
> After control returns from the "animate" method, and after the
> animation is done, it is automatically released.
>
> However if you replace "NSViewAnimation.alloc().init()", with
> "NSViewAnimation.new()", the animation is not automatically released.
> Consequentially, any views or windows included in the dictionaries
> that form the viewAnimations array are also retained, causing quite a
> significant leak.
>
> Juding from the NSObject class docs, calling "new()" on a class should
> do exactly the same thing as "alloc().init()", but PyObjC doesn't seem
> to treat it the same way.
>
> http://tinyurl.com/nsobject-new
>
> Can anyone enlighten me whether this is a bug, a feature, or simply
> something I'm misunderstanding?
>
> Thanks!
> - Dirk
> ------------------------------------------------------------------------------
> Crystal Reports - New Free Runtime and 30 Day Trial
> Check out the new simplified licensing option that enables unlimited
> royalty-free distribution of the report engine for externally facing
> server and web deployment.
> http://p.sf.net/sfu/businessobjects
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Memory management bug using .new()

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

Hi all,

I don't think anyone ever uses this method – NSObject.new() – anymore,  
but in case someone does: I just ran into a reproducable problem with  
it.

When you create a new cocoa object within an instance method of a  
Cocoa class implemented in Python, normally that fresh object is  
released when the scope dissapears. (that is, when you're not storing  
a reference to it in an attribute that exists outside of the method's  
scope).

e.g.:

class MyAmazingViewController(NSViewController):
     def animate(self):
         animation = NSViewAnimation.alloc().init()
         # insert code to create an array/list of NSDictionaries  
describing the animations
          
animation.setViewAnimations_(theAboveMentionedHypotheticalArray)
         animation.setDuration_(5.0)
         animation.setAnimationBlockingMode_(NSAnimationNonblocking)
         animation.startAnimation()

( if the spaces got stripped from my example somehow, snippet also  
pasted here: http://pastie.org/516369 )

After control returns from the "animate" method, and after the  
animation is done, it is automatically released.

However if you replace "NSViewAnimation.alloc().init()", with  
"NSViewAnimation.new()", the animation is not automatically released.   
Consequentially, any views or windows included in the dictionaries  
that form the viewAnimations array are also retained, causing quite a  
significant leak.

Juding from the NSObject class docs, calling "new()" on a class should  
do exactly the same thing as "alloc().init()", but PyObjC doesn't seem  
to treat it the same way.

http://tinyurl.com/nsobject-new

Can anyone enlighten me whether this is a bug, a feature, or simply  
something I'm misunderstanding?

Thanks!
- Dirk