>> Background:
>>
>> I'm using EOF 4.5, and I wanted to be able to use python to write
>> test scripts, mini programs, and scripts that interacted with both
>> our object model, and shell tools.
>>
>> Every thing works ok, except I had to make some tweaks.
>
> It's great to hear that PyObjC is still useable with EOF, even after
> the extensive changes I made to the bridge over the last year.
Yeah, though EOF doesn't work with 10.2 without some tweaking. :-)
>>
>> import objc
>> import Foundation
>>
>> #VOODOO
>> from Foundation import NSCalendarDate
>> NSCalendarDate.date().description()
>>
>> objc.loadBundle("EOAccess",globals(),bundle_path="/System/Library/
>> Frameworks/EOAccess.framework")
>
> This is odd. I'll try to reproduce this with another framework, I
> don't think we have old WebObjects CD's lying around at the office. I
> noticed you can download a trial version of WebObjects 5.x, but that
> seems to be java based.
Yeah, 5.x is java only.
>
>>
>>
>> 2. EOF does some hackery on the ObjC where objects that haven't yet
>> been fetched from the database have a fake "isa" pointer. When the
>> object gets fetched, the isa pointer get reset to that of the real
>> class.
>>
>> This crashes on the Python side, but it works if you pre resolve
>> the fault on the ObjC side.
>
> That doesn't surprise me. Do you know if there is a way to detect this
> fake isa pointer? Calling [object self] everytime we want to access
> an Objective-C object would be way to expensive, especially if this is
> only needed for WebObjects.
I dunno, [object self] is really fast for any non-EOF object, and its
fast for any EOF object that's been fetched already. So its not that
expensive, and its cheaper then [obj isMemberOfClass: [EOFault class]].
Its only in pythonify_c_value right now, which has to build new objects
some portion of the time so it doesn't seem so bad, since building an
object should take even longer.
>
> I've checked the code and think this may be caused by the call to
> __pyobjc_PythonObject__ (a few lines below the fragment you included
> below). From about line 50 in objc_support.m we define a category on
> NSObject that defines this method. The fake 'isa' obviously doesn't
> point to a subclass of NSObject. Could you try to change 'NSObject' to
> 'Object' in the declaration and definition of that category and check
> if that solves your problem?
Didn't work, then NO objects saw the category. Perhaps you need some
special way to add a category to the root object class?
>
> That probably doesn't help with objects that get invalidated. PyObjC
> doesn't deal gracefully with objects that change their class.
Yeah, it comes back as a "NoneType" object. after invalidation and
throws an error.
probably fixable with another [obj self] call before any method
dispatching if I can find the place to do it.
Ex:
ec=EOEditingContext.new()
print "fetching"
manager=ec.objectMatchingValue_forKey_entityNamed_("pierce","loginName",
"MManager")
#portfolio = manager.valueForKeyPath_("portfolio.self");
portfolio=manager.portfolio()
print portfolio.description()
print portfolio.funds().description()
ec.invalidateObject_(manager)
portfolio=manager.portfolio()
print portfolio.description()
print portfolio.funds().description()
Produces:
fetching
<MPortfolio: 0x6bb750>
(Pierce's Fund for Test Crap, MTaco Picks, Value Fund, Bottom Fund)
Traceback (most recent call last):
File "./pythontest.py", line 37, in ?
print portfolio.description()
AttributeError: 'NoneType' object has no attribute 'description'
Pierce
|