(((Disclaimer: I'm cross-posting this to the pyobjc-dev list and the pythonmac-sig list.  Normally, I wouldn't do such a thing because I know how annoying that can be.  In this case, it seems at least OK.  I had asked some questions about this problem on the pyobjc-dev list a couple of months ago and then switched to pestering the pythonmac-sig list about it due to the higher traffic there.  Thanks to everyone (Bob!) who offered suggestions.)))

Well, I think I've figured out some part of my little NSZombie problem.

Bind an NSPopubButton (contents) to a Python List object that is an attribute of a python class placed in an NSArray controlled by an NSArrayController and the OC_PythonArray object from PyObjC corresponding to the Python List gets freed too early. (There's a mouthful... Confusing enough?) Wrap that Python List object in an NSArray.alloc().initWithArray_copyItems_([u'the', u'list'], objc.NO) and (I guess) the NSArray...init... adds one more -retain than does OC_PythonArray and the binding doesn't break.

http://jonathansaggau.com/breakPyObjC.tar.gz is the simplest example of the bug I can muster. Set BREAKME = True in testObj.py. Run the app in the debugger (breakpoint is set on -[NSZombie retain] and NSZombie is enabled already in the project) and you'll see what happens when you hit the plus button twice. Set BREAKME = False, rebuild, and everybody is happy.

I'm always nervous to call things like this a bug because maybe I'm not *supposed* to be able to do what I'm trying to do in the way that I'm trying to do it, but this one looks like a bug to me.

What did I learn from this:

1. Try to use cocoa objects instead of python objects in code that uses bindings; pay special attention to collections (lists, etc.). At least this *seems* safer because a python object being referenced from cocoa is probably more likely to cause problems than a cocoa object controlled from python. (?) Then again, it's pretty stupid to generalize from one experience...
2. GDB is very useful for debugging pyobjc.
3. There are a lot of nice pyobjc debugging features, but you have to turn them on (See my example project referenced above).

Things I want to know:

1. Is there a way, when one gets the memory address of a pyobjc proxy object (Like OC_PythonArray) from gdb to figure out which python object it's proxying?

2.  Is there a way to get the python object from a memory address?

3. Is there a reliable way to get (in gdb or pdb) the "Python List Object at 0x03423blahblahblah information from the python object being proxied?

4. Can I compile pyobjc with debugging symbols? GDB without them hurts my brain.

Cheers,

Jonathan Saggau

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to