Re: [Pyobjc-dev] Some PyObC tweaks for using EOF and custom frameworks

[Ronald O. <ous...@ci...>]

On Saturday, 9 August, 2003, at 07:56, Pierce T. Wetter III wrote:

>
>  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.

>
>  1. I have to touch NSCalendarDate after loading Foundation and before  
> loading any other frameworks via loadBundle. I think this causes  
> +initialize for the various Foundation classes early on, which  
> probably should have been done by the "import Foundation" step  
> originally, but that might be tough. I'm using NSCalendarDate because  
> NSCalendarDate had a +initialize method that was deadlocking, but  
> using it seemed to fix everything.
>
>  Doing this after the loadBundle call caused problems with both  
> Foundation and the loaded frameworks.
>
> i.e I have to do some VOODOO:
>
> 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.

>
>
>  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'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?

That probably doesn't help with objects that get invalidated. PyObjC  
doesn't deal gracefully with objects that change their class.

>
> That is in Python:
>
> mystock= trade.stock()
>
> bus errors, but
>
>  mystock= trade.valueForKeyPath_("stock.self")
>
> works.
>
>  Given this, the fix is easy.
>
>  In objc_support.m:pythonify_c_value we have:
>
> 	case _C_ID:
> 	{
> 		id obj = *(id *) datum;
> 		if (obj == nil) {
>
> Which becomes:
>
> 	case _C_ID:
> 	{
> 		id obj = *(id *) datum;
> 		obj=[obj self];
>
> 		if (obj == nil) {
>
>  This forces the fault to resolve on the Objective-C side before  
> python creates the python object. Then:
>
> mystock= trade.stock()
>
>  Will work. I'm not sure what would happen if an object got  
> invalidated. It seems in that case, you'd want to call [obj self]  
> before doing any method calls on it, but I wasn't sure where to put  
> that.
>
>  Pierce
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct; 
> at.aspnet_072303_01/01
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>