pyobjc-dev — CVS commit notices go here

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

[Pierce T. W. I. <pi...@ma...>]

>> So I removed by [obj self] call from pythonify_c_value, and I used  
>> this instead:
>>
>> 		 
>> objc.classAddMethods(EOFault,[Foundation.NSObject.__pyobjc_PythonObjec 
>> t__])
>>
>> And that worked on single faults, but not array faults.
>
> Are array faults implemented directly via EOFault or is there some  
> other class to stand in for 'em?

  Pretty funny that you're asking ME, but yes, EOFault claims to be the  
object for both faults and containers. that works because EOFault is  
really just a wrapper object around EOFaultHandler or  
EOFArrayFaultHandler

>
>> I also got "None" for object.description() on a single fault. So it  
>> really only partially
>> worked.
>
> Odd.
>
> Posing could completely hose this....   are you doing the  
> classAddMethods() immediately upon loading EOAccess [which defines  
> EOFault, IIRC]?

  It's EOControl actually, but yes.

  Yep. I think the EOFault hackery is too much for pyobjc. For one  
thing, on objC, you can call [obj description] and get [EOFault  
0xASDFASDF], but from pyobjc, you still get a bus error.

  The other issue is possibly that pyobjc seems to be going into the low  
level of Objective-C to find out if methods are implemented and such. I  
would have expected it to be using respondsToSelector and such instead  
of messing with the isa pointer. Given that, it wouldn't surprise me if  
NSProxy and other "interface" objects might have problems.

  Pierce

[Pyobjc-dev] Suggested Documentation change

[Pierce T. W. I. <pi...@ma...>]

Currently:


The basics

The code for loading a framework and exporting its classes is pretty 
simple:


import objc
objc.loadBundle("MyFramework", globals(),
    bundle_path='/path/to/MyFramework.framework')
del objc

If your class library does not require helper functions for some 
methods this is all that is needed.

Don't forget to import the frameworks that are used by your framework 
before calling objc.loadBundle. This is necessary to arrange for the 
helper code for these modules (if there is any) to be loaded.

Change to:

The basics

The code for loading a framework and exporting its classes is pretty 
simple:


import objc
objc.loadBundle("MyFramework", globals(),
    bundle_path='/path/to/MyFramework.framework')
del objc

However, in general, you don't want to use this, because its tedious to 
cut/paste this code everywhere. Instead, you can make this look just 
like a python module as follows:

1. Make a directory called "MyFramework"
2. in this directory create a file named __init__.py
3. Put the code above into that file.

You can now import/load your framework via:

import MyFramework

example=MyFramework.MyObject.alloc().init()

or

from MyFramework import MyObject

example=MyObject.alloc().init()


If your class library does not require helper functions for some 
methods this is all that is needed.

Don't forget to import the frameworks that are used by your framework 
before calling objc.loadBundle. This is necessary to arrange for the 
helper code for these modules (if there is any) to be loaded.

Pierce

P.S.

   I'm not sure about the: "Don't forget to import the frameworks that 
are used by your framework before calling objc.loadBundle." line. I did 
a quick test and found out that the framework loading mechanism seemed 
to be able to figure it out even if I didn't load all the required 
frameworks. It used to be true under Rhapsody, but X seems to have 
fixed this. 

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

[Pierce T. W. I. <pi...@ma...>]

On Monday, August 11, 2003, at 01:19 PM, b.bum wrote:

> On Sunday, August 10, 2003, at 12:07, Ronald Oussoren wrote:
>> If all 'unvalidated' objects are an instance of EOFault we could try  
>> to add a category on that class. That would have to be implemented in  
>> a seperate C module, the code fragment below failed to compile when I  
>> added this to objc_support.m:
>>
>> 	@class EOFault;
>> 	@interface EOFault (PyObjCSupport)
>> 	-(PyObject*)__pyobjc_PythonObject__;
>> 	@end
>
>
> Actually, this could be done from the Python side via the  
> addClassMethod API in the objc module -- or, at the least, that code  
> can be used as a model for implementing this without using a category.  
>  It would allow the method to be added to a class conditioned on  
> whether or not the class exists.
>
> If __pyobjc_PythonObject__ as implemented on NSObject will "just  
> work", then there is no need to provide an alternative implementation:
>
> % python
> Python 2.3b1 (#1, Jul 27 2003, 10:44:20)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1481)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import objc
> >>> from Foundation import *
> >>> x = NSBundle.mainBundle()
> >>> x.description()
> u'NSBundle </usr/bin> (loaded)'
> >>> objc.classAddMethods(NSBundle, [NSObject.description])
> >>> x.description()
> u'<NSBundle: 0x35b120>'

Ok, so I could do:

objc.classAddMethods(EOFault,[NSObject. __pyobjc_PythonObject__])

Testing...

So I removed by [obj self] call from pythonify_c_value, and I used this  
instead:

		 
objc.classAddMethods(EOFault,[Foundation.NSObject.__pyobjc_PythonObject_ 
_])

And that worked on single faults, but not array faults.

I also got "None" for object.description() on a single fault. So it  
really only partially
worked.

Pierce

[Pyobjc-dev] Key/Value Coding

[b.bum <bb...@ma...>]

I committed a new Key/Value coding unit test and a bit of additional 
functionality in the KeyValueCoding module within PyObjCTools.   It 
includes a compiled module.

The unit tests do not pass and are currently, more or less, a feature 
request.

The goal is to make PyObjC's key/value coding support compliant with 
ObjC to the point where Python, ObjC or mixed PyObjC instances can be 
transparently passed into K/V dependent functionality.   We need this 
to fully support the increasing emphasis on Key/Value Coding found 
within Mac OS X.

b.bum

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

[b.bum <bb...@ma...>]

On Sunday, August 10, 2003, at 12:07, Ronald Oussoren wrote:
> If all 'unvalidated' objects are an instance of EOFault we could try 
> to add a category on that class. That would have to be implemented in 
> a seperate C module, the code fragment below failed to compile when I 
> added this to objc_support.m:
>
> 	@class EOFault;
> 	@interface EOFault (PyObjCSupport)
> 	-(PyObject*)__pyobjc_PythonObject__;
> 	@end


Actually, this could be done from the Python side via the 
addClassMethod API in the objc module -- or, at the least, that code 
can be used as a model for implementing this without using a category.  
It would allow the method to be added to a class conditioned on whether 
or not the class exists.

If __pyobjc_PythonObject__ as implemented on NSObject will "just work", 
then there is no need to provide an alternative implementation:

% python
Python 2.3b1 (#1, Jul 27 2003, 10:44:20)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1481)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import objc
 >>> from Foundation import *
 >>> x = NSBundle.mainBundle()
 >>> x.description()
u'NSBundle </usr/bin> (loaded)'
 >>> objc.classAddMethods(NSBundle, [NSObject.description])
 >>> x.description()
u'<NSBundle: 0x35b120>'

Re: [Pyobjc-dev] 1.0 - should we go through the exception messages?

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

On Monday, 11 August, 2003, at 00:08, Jack Jansen wrote:

> Something I just remembered again: some of the exceptions issued by 
> PyObjC
> are obscure to the point of being unintelligible without knowing how 
> things
> works internally.
>
> Should we make a quick pass over them to see which ones need to be
> rephrased?

Good idea.

Ronald

Re: [Pyobjc-dev] another odd problem

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

On Sunday, 10 August, 2003, at 23:25, Jack Jansen wrote:

>
> On zaterdag, aug 9, 2003, at 21:36 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>
>> That was easier than I expected. This is fixed in CVS, as a quick 
>> workaround you can make the mixin-class a new-style class (subclass 
>> from object). I hadn't accounted for old-style classes when searching 
>> for attributes.
>
> Ronald,
> is there a test case for Python's funky MRO multiple inheritance 
> rules? If there isn't then there probably should be one, because fixes 
> like this are prone to break those rules...

Not yet.

This actually brings us closer to the normal python semantics of 
object.__getattribute__. The code for objc_object.__getattribute__ was 
copied from object.__getattribute__ and then I threw out unnecessary 
code before adding our own stuff. The unnecessary code turned out out 
to be necessary after all.

Ronald

Re: [Pyobjc-dev] Refcounting problem - idea?

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

On Sunday, 10 August, 2003, at 23:23, Jack Jansen wrote:

>
> On zaterdag, aug 9, 2003, at 12:14 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>
>>  As Martina already noted, the combobox probably doesn't retain it's 
>> datasource. There's not much we can do about that. Cocoa seems to do 
>> this quite often, probably to avoid reference counting cycles. Let's 
>> hope that Apple adds a real garbage collector in the future.
>
> I was just wondering: are there *any* places where the user is 
> expected to pass a
> wrapped ObjC object to a method call, and have that object be garbage 
> collected
> when the call returns?

NSArray.arrayWithArray_() is a trivial one and there are many others.

Ronald

[Pyobjc-dev] 1.0 - should we go through the exception messages?

[Jack J. <Jac...@cw...>]

Something I just remembered again: some of the exceptions issued by 
PyObjC
are obscure to the point of being unintelligible without knowing how 
things
works internally.

Should we make a quick pass over them to see which ones need to be
rephrased?
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

Re: [Pyobjc-dev] another odd problem

[Jack J. <Jac...@cw...>]

On zaterdag, aug 9, 2003, at 21:36 Europe/Amsterdam, Ronald Oussoren 
wrote:

> That was easier than I expected. This is fixed in CVS, as a quick 
> workaround you can make the mixin-class a new-style class (subclass 
> from object). I hadn't accounted for old-style classes when searching 
> for attributes.

Ronald,
is there a test case for Python's funky MRO multiple inheritance rules? 
If there isn't then there probably should be one, because fixes like 
this are prone to break those rules...
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

[Pyobjc-dev] Refcounting problem - idea?

[Jack J. <Jac...@cw...>]

On zaterdag, aug 9, 2003, at 12:14 Europe/Amsterdam, Ronald Oussoren 
wrote:

>  As Martina already noted, the combobox probably doesn't retain it's 
> datasource. There's not much we can do about that. Cocoa seems to do 
> this quite often, probably to avoid reference counting cycles. Let's 
> hope that Apple adds a real garbage collector in the future.

I was just wondering: are there *any* places where the user is expected 
to pass a
wrapped ObjC object to a method call, and have that object be garbage 
collected
when the call returns?

Because if there aren't any such legal uses (as I expect) then we could 
warn about
this: the wrapper code could check (just before the DECREF) that the 
refcount is 1
*and* the object is a wrapped ObjC object, and in that case print a 
warning.

Down side is that it won't catch everything, of course:
     def awakeFromNib(self):
         tmp = WordTypeManager.alloc().init(self.db)
         self.word_type.setDataSource_(tmp)
will slip through silently.

--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

[Pyobjc-dev] Prerelease files

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

I've uploaded a prerelease tarball and installer for 1.0 to SF. The 
installer diskimage does not yet contain a pretty background image.

http://pyobjc.sf.net/prerelease/pyobjc-1.0rc1.tar.gz
http://pyobjc.sf.net/prerelease/PyObjC-1.0rc1.dmg

Ronald

[Pyobjc-dev] [ pyobjc-Bugs-786357 ] NSFont.fontWithName: matrix:

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

Bugs item #786357, was opened at 2003-08-10 20:35
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=786357&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martina Oefelein (oefe)
Assigned to: Nobody/Anonymous (nobody)
Summary: NSFont.fontWithName: matrix:

Initial Comment:
The second argument to NSFont.fontWithName: matrix: is 
an array of 6 floats. PyObjC 1.0b1 treats is as a single float 
instead.

Python 2.2 (#1, 11/12/02, 23:31:59) 
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import objc, AppKit
>>> objc.__version__
'1.0b1'
>>> AppKit.NSFont.fontWithName_matrix_("Helvetica", (10, 
0, 0, 10, 0, 0))
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError: depythonifying 'float', got 'tuple'


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

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

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

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

On Sunday, 10 August, 2003, at 17:27, Pierce T. Wetter III wrote:

>>>
>>> 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.
>
>  I found one spot:
>
> Changing
>
> #define   PyObjCObject_GetObject(object) 
> (((PyObjCObject*)(object))->objc_object)
>
> to
>
> #define   PyObjCObject_GetObject(object) 
> ([((PyObjCObject*)(object))->objc_object self])
>
> in pyobjc.h seems to do it.
>
>  There are probably better locations though.

That's probably the best location, but I'm not entirely sure that 
everyone access the objc_object field through this macro.

I'll probably add this change (and the change to objc_support.m) to an 
experimental tree to check if this has any negative effects. This may 
end up in the repository, probably as a configuration option.


Ronald

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

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

On Sunday, 10 August, 2003, at 16:34, 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.
>
>  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.
But it is much slower than just using 'object'. I'd prefer to not  
introduce unnecessary method calls.

>  So its not that expensive, and its cheaper then [obj isMemberOfClass:  
> [EOFault class]].

If all 'unvalidated' objects are an instance of EOFault we could try to  
add a category on that class. That would have to be implemented in a  
seperate C module, the code fragment below failed to compile when I  
added this to objc_support.m:

	@class EOFault;
	@interface EOFault (PyObjCSupport)
	-(PyObject*)__pyobjc_PythonObject__;
	@end


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

NSObject doesn't seem to be a subclass of Object, that's why everything  
stopped to work. So much for trying to find a common base class for  
NSObject and 'unvalidated' WebObjects objects.

Ronald

Re: [Pyobjc-dev] Dumb Question about objc.loadBundle

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

On Sunday, 10 August, 2003, at 17:00, Pierce T. Wetter III wrote:

>
>  So I want to use PyObjC in order to create unit tests, simple tools,  
> etc. using our custom framework.
>
>  Given that I'd like to use PyUnit (unittest) for all this, that means  
> I'l be writing lots of little python files that define a unit test  
> class and have:
>
>
>  if __name__ == "__main__":
> 	runTest()
>
>  So the tests can be run individually from the command line, or via a  
> test tool, or various grouping scripts will import other tests and run  
> them a group.
>
>  The gotcha for me is that loadBundle both loads the framework, and  
> exports/imports the symbols. In other words, its a little heavier of  
> an operation then just an import.
>
>  So my dumb question:
>
>  Let's say I have a bunch of test files:
>
>  test1,py, test2,py, test3,py,
>
>  All with:
>
> #!/usr/local/bin/python
> import random
> import objc
> import Foundation
> from Foundation import NSCalendarDate
> NSCalendarDate.distantPast()
>
> objc.loadBundle("EOAccess",  
> globals(),bundle_path='/System/Library/Frameworks/EOAccess.framework')
> objc.loadBundle("EOControl",  
> globals(),bundle_path='/System/Library/Frameworks/ 
> EOControl.framework')
> objc.loadBundle("exim",  
> globals(),bundle_path='/Marketocracy/Frameworks/exim.framework')
> objc.loadBundle("MChannel",  
> globals(),bundle_path='/Marketocracy/Frameworks/MChannel.framework')
> objc.loadBundle("MRPC",  
> globals(),bundle_path='/Marketocracy/Frameworks/MRPC.framework')
> objc.loadBundle("StandardAndPoors",  
> globals(),bundle_path='/Marketocracy/Frameworks/ 
> StandardAndPoors.framework')
> objc.loadBundle("MFoundation",  
> globals(),bundle_path='/Marketocracy/Frameworks/ 
> MFoundation.framework')
> objc.loadBundle("ObjectModel",  
> globals(),bundle_path='/Marketocracy/Frameworks/ 
> ObjectModel.framework')
>
> At the top.

I'd create a seperate python module (or even several modules) that  
perform(s) the calls to loadBundle. That would make it easier to access  
the frameworks from other scripts.

>
> Will the extra "loadBundle" calls cause me problems?

It shouldn't cause problems.

Ronald

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

[Pierce T. W. I. <pi...@ma...>]

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

  I found one spot:

Changing

#define   PyObjCObject_GetObject(object) 
(((PyObjCObject*)(object))->objc_object)

to

#define   PyObjCObject_GetObject(object) 
([((PyObjCObject*)(object))->objc_object self])

in pyobjc.h seems to do it.

  There are probably better locations though.

Pierce

[Pyobjc-dev] Dumb Question about objc.loadBundle

[Pierce T. W. I. <pi...@ma...>]

  So I want to use PyObjC in order to create unit tests, simple tools,  
etc. using our custom framework.

  Given that I'd like to use PyUnit (unittest) for all this, that means  
I'l be writing lots of little python files that define a unit test  
class and have:


  if __name__ == "__main__":
	runTest()

  So the tests can be run individually from the command line, or via a  
test tool, or various grouping scripts will import other tests and run  
them a group.

  The gotcha for me is that loadBundle both loads the framework, and  
exports/imports the symbols. In other words, its a little heavier of an  
operation then just an import.

  So my dumb question:

  Let's say I have a bunch of test files:

  test1,py, test2,py, test3,py,

  All with:

#!/usr/local/bin/python
import random
import objc
import Foundation
from Foundation import NSCalendarDate
NSCalendarDate.distantPast()

objc.loadBundle("EOAccess",  
globals(),bundle_path='/System/Library/Frameworks/EOAccess.framework')
objc.loadBundle("EOControl",  
globals(),bundle_path='/System/Library/Frameworks/EOControl.framework')
objc.loadBundle("exim",  
globals(),bundle_path='/Marketocracy/Frameworks/exim.framework')
objc.loadBundle("MChannel",  
globals(),bundle_path='/Marketocracy/Frameworks/MChannel.framework')
objc.loadBundle("MRPC",  
globals(),bundle_path='/Marketocracy/Frameworks/MRPC.framework')
objc.loadBundle("StandardAndPoors",  
globals(),bundle_path='/Marketocracy/Frameworks/ 
StandardAndPoors.framework')
objc.loadBundle("MFoundation",  
globals(),bundle_path='/Marketocracy/Frameworks/MFoundation.framework')
objc.loadBundle("ObjectModel",  
globals(),bundle_path='/Marketocracy/Frameworks/ObjectModel.framework')

At the top.

Will the extra "loadBundle" calls cause me problems?

Pierce
  

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

[Pierce T. W. I. <pi...@ma...>]

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

This is the sample run from the lock up that happens.

It's not all frameworks that do this, I think they have to have some  
categories on some foundation classes or something. Which makes a  
certain amount of sense, because its related to +initialize. The work  
around might be just to trigger an initialize during the loadBundle  
call via [Class self] on one of the imported classes.

     1000 Thread_0e03
       1000 start
         1000 _start
           1000 Py_Main
             1000 PyRun_SimpleFileExFlags
               1000 run_node
                 1000 PyEval_EvalCode
                   1000 PyEval_EvalCodeEx
                     1000 eval_frame
                       1000 call_function
                         1000 do_call
                           1000 PyObject_Call
                             1000 PyObjCSelector_Required
                               1000 ObjC_FFICaller
                                 1000 ffi_call
                                   1000 ffi_call_DARWIN
                                     1000 +[NSCalendarDate distantPast]
                                       1000 -[NSCalendarDate  
initWithTimeIntervalSinceReferenceDate:]
                                         1000 -[NSCalendarDate  
initWithTimeIntervalSinceReferenceDate:]
                                           1000 objc_msgSend
                                             1000  
_class_lookupMethodAndLoadCache
                                               1000  
_destroyInitializingClassList
                                                 1000  
_destroyInitializingClassList
                                                   1000  
+[NSTimeZone(Extra) initialize]
                                                     1000  
+[NSTimeZone(Extra) initialize]
                                                       1000 objc_msgSend
                                                         1000  
_class_lookupMethodAndLoadCache
                                                           1000  
_destroyInitializingClassList
                                                             1000  
+[NSTimeZone(Extra) initialize]
                                                               1000  
-[NSLock lock]
                                                                 1000  
pthread_mutex_lock
                                                                   1000  
semaphore_wait_trap
                                                                      
1000 semaphore_wait_trap [STACK TOP]

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

[Pierce T. W. I. <pi...@ma...>]

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

Re: [Pyobjc-dev] Errors building standalone with 1.0b1 & MacPython2.3

[Zachery B. <zb...@ur...>]

On Sunday, August 10, 2003, at 02:19 AM, Kevin Marks wrote:

> OK, I installed MacPython OS X 2.3, and now it gets further, but it 
> can't find the Cocoa bits, and the standalone won't run on another 
> Mac. errors:
>
> Do I need to reinstall PyObjC, or is there some PATH stuff I need to 
> do?

Yeah, I think you'll want to re-run the setup.py build and setup.py 
install for each version of python you use (I use Apple's internal, 
Fink's, and the 2.3 framework build, each with their own copy of PyObjC)

Zac

Re: [Pyobjc-dev] Errors building standalone with 1.0b1 & MacPython2.3

[Kevin M. <kev...@ma...>]

On Friday, August 8, 2003, at 01:29  PM, Bob Ippolito wrote:

>
> On Friday, Aug 8, 2003, at 15:51 America/New_York, Kevin Marks wrote:
>
>> When I pass --standalone or --semistandalone to my build instead of 
>> --link using 1.0b1 and Apple Python 2.2 on Jag I get Do I need to 
>> change some install settings, or install Python 2.3 ?
>
> I don't know about your PyObjC installation problem specifically, but 
> modulefinder is a new module that comes with 2.3.  You should install 
> 2.3 anyways.. it's faster, more capable, less buggy, etc.  Especially 
> on the mac.  It's also what will be in Panther.

OK, I installed MacPython OS X 2.3, and now it gets further, but it 
can't find the Cocoa bits, and the standalone won't run on another Mac. 
errors:

Do I need to reinstall PyObjC, or is there some PATH stuff I need to do?

Finding module dependencies
Building 'build/iirc.app'
Copying files
Adding Python modules
Warning: couldn't find the following submodules:
     (Note that these could be false alarms -- it's not always
     possible to distinguish between "from package import submodule"
     and "from package import name")
   ? os.path
Warning: couldn't find the following modules:
   ? AddressBook
   ? AppKit
   ? Foundation
   ? PyObjCTools
Done.

Re: [Pyobjc-dev] another odd problem

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

That was easier than I expected. This is fixed in CVS, as a quick 
workaround you can make the mixin-class a new-style class (subclass 
from object). I hadn't accounted for old-style classes when searching 
for attributes.

Sorry about sending you through the awfull bugtracking interface at SF 
:-(

Ronald

[Pyobjc-dev] [ pyobjc-Bugs-785980 ] Inheriting from NSObject blocks visibility of attributes

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

Bugs item #785980, was opened at 2003-08-09 18:30
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=785980&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Arnold (stevena)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inheriting from NSObject blocks visibility of attributes

Initial Comment:
Classes that inherit from Foundation.NSObject do not 
correctly see methods in superclasses before the one that 
inherited from NSObject.  However, note that dir does show 
the attribute!  Consider the following code snippet:

    import Foundation
    class ListManager:
        def init( self ):
            return self
        def key_for_index( self, index ):
            print "INDEX = ", index
    
    class foo( Foundation.NSObject, ListManager ):
        def init( self ):
            ListManager.init( self )
            return self
    
    i = foo.alloc().init()
    if 'key_for_index' in dir( i ):
        present = "is"
    else:
        present = "is not"
    
    print "dir shows that key_for_index %s an attribute of i" 
% present
    i.key_for_index( 5 )

If you run this code, you get the following:

    >>> print "dir shows that key_for_index %s an attribute 
of i" % present
    dir shows that key_for_index is an attribute of i
    >>> i.key_for_index( 5 )
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    AttributeError: 'foo' object has no attribute 
'key_for_index'


However, if you modify the code to avoid inheriting from 
Foundation.NSObject, you get the expected behavior:

    import Foundation
    class ListManager:
        def init( self ):
            return self
        def key_for_index( self, index ):
            print "INDEX = ", index
    
    class foo( ListManager ):
        def init( self ):
            ListManager.init( self )
            return self
    
    i = foo()
    if 'key_for_index' in dir( i ):
        present = "is"
    else:
        present = "is not"
    
    print "dir shows that key_for_index %s an attribute of i" 
% present
    i.key_for_index( 5 )

The result:

    >>> print "dir shows that key_for_index %s an attribute 
of i" % present
    dir shows that key_for_index is an attribute of i
    >>> i.key_for_index( 5 )
    INDEX =  5


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

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

Re: [Pyobjc-dev] another odd problem

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

On Saturday, 9 August, 2003, at 19:53, Steven D. Arnold wrote:

> Essentially, it seems classes that inherit from Foundation.NSObject do 
> not
> correctly see methods in superclasses before the one that inherited 
> from
> NSObject.  However, note that dir does show the attribute!  Consider 
> the
> following code snippet:
>
>     import Foundation
>     class ListManager:
>         def init( self ):
>             return self
>         def key_for_index( self, index ):
>             print "INDEX = ", index
>
>     class foo( Foundation.NSObject, ListManager ):
>         def init( self ):
>             ListManager.init( self )
>             return self
>
>     i = foo.alloc().init()
>     if 'key_for_index' in dir( i ):
>         present = "is"
>     else:
>         present = "is not"
>
>     print "dir shows that key_for_index %s an attribute of i" % present
>     i.key_for_index( 5 )
>
> If you run this code, you get the following:
>
>>>> print "dir shows that key_for_index %s an attribute of i" % present
>     dir shows that key_for_index is an attribute of i
>>>> i.key_for_index( 5 )
>     Traceback (most recent call last):
>       File "<stdin>", line 1, in ?
>     AttributeError: 'foo' object has no attribute 'key_for_index'
>

That is a bug, I'll look into it. Could you file a bug on SF, just in 
case I forget to fix it :-)

There is one problem with your code: You call the init of only one of 
the superclasses. Because NSObject (obviously) doesn't know about 
Python's multiple inheritance your init should be more like:	

	def init(self):
		self = NSObject.init(self)
		ListManager.init(self)
		return self

Multiple inheritance with Objective-C objects is obviously not used 
very much. And then this bug after I told some people that 
mixin-classes would be a convenient way to add generic implementations 
for protocols (such as NSTableDataSource) to a class :-(

Ronald