pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Doc, it hurts when I say +isKindOfClass...

[Bill B. <bb...@co...>]

Actually, all of those classes should be-- for all intents and 
purposes-- totally hidden from the pyobjc module from the ObjC side.  
They are all internal classes that are designed to support things like 
distributed objects [distant object, protocol checker (sort of), 
nsproxy], effeciency hacks [nsmutablestring proxy], or debuggin 
[nszombie].

In any case, they mostly stand in-- or act as proxies-- to other 
instances.  For example, an NSProxy is used to represent an object that 
actually resides in a different runtime.  The NSProxy speaks across an 
NSConnection instance such that any method invocation against NSProxy is 
passed across the wire and executed in the foreign runtime.  Very 
cool.   At runtime, it also menas that an NSProxy instance may very well 
exist, but is nearly indistinguishable from the object it is proxying.

NSProxy is a root class;  hence, doesn't inherit from NSObject and 
doesn't implement any of the standard methods.

b.bum


On Friday, April 6, 2001, at 01:09 AM, Steven D. Majewski wrote:

>
>
> In the following code, the classes in skiplist will all
> generate objective-c runtime exceptions if they are touched:
>
> ----
> from pyobjc import runtime,lookup_class
>
> _Pool = runtime.NSAutoreleasePool()
>
> skiplist = [ 'NSConcreteProtocolChecker', 'NSDistantObject',
>         'NSInvocationBuilder', 'NSMutableStringProxy', 
> 'NSProtocolChecker'
> ,
>         'NSProxy' , '_NSZombie' ]
>
> for x in runtime.__objc_classes__:
>         if x not in skiplist:
>                 print x
>                 print lookup_class(x)
> ----
>
>
> All of the exceptions happens in ObjCObject_new().
>
>
> #   NSConcreteProtocolChecker
> #   NSDistantObject
> #   NSMutableStringProxy
> #   NSProtocolChecker
> #   NSProxy
> # Apr 05 23:54:51 python[2259] *** Uncaught exception:
> <NSInvalidArgumentException> *** -[NSProxy forwardInvocation:] called!
> #
> # caused by: [obj isKindOfClass: [NSAutoreleasePool class]]
> #
> #
> #   NSInvocationBuilder
> # Apr 05 23:54:41 python[2256] *** Uncaught exception:
> <NSInvalidArgumentException> target does not implement method
> #
> # caused by: [obj respondsToSelector:@selector (count)]
> #
> #
> #   _NSZombie           Bus error
>  (seems to be somewhere close to the one above)
>
> I'm quite willing to believe that whatever "_NSZombie" is, it
> probably shouln't be touched. Most likely all of the classes
> with a leading underscore in their names are not meant to be
> exposed and should be removed from the Python-Objc runtime.
>
> NSInvocationBuilder is undocumented (not even in the header
> files) and I'm even unable to see it in the Class Introspector.
>
> All of the first bunch, except for NSProxy are all subclasses of 
> NSProxy.
> NSProxy is another root class that is independent of NSObject.
> Looking at NSProxy with the Class Introspector, I can see that indeed,
> there is no class method for isKindOfClass: as there is in NSObject.
> ( NSObject has both a Class and an Instance isKindOfClass: )
>
>
> I was looking at this problem too see if it was related to some of
> the delegation bugs I've run into, but I'm now pretty convinced they
> are probably unrelated. I'm not sure if there is any likey case in
> which those classes would need to be called from Python -- perhaps
> they should all be removed from the runtime.
>
> For now, I'm going to leave them alone with just this warning:
>  don't try to access any of those classes from python.
>
> Does anyone know:
> Is there a reason that +[NSProxy isKindOfClass:] is not implemented
> or is it just an oversight (bug) ?
>
> -- Steve Majewski
>
>
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> http://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Time for a release ?

[Steven D. M. <sd...@mi...>]

Bill -- I submitted that patch to add ".m" files to python, and
I got a note it was accepted.

With your changes to use distutils, it ought to build and install
out of the box on OSX with Python2.1 once it is released.
( Which will probably be soon. )

I think it's probably time for us to put out a release.

I changed the #ifdefs, which, because I originally didn't know
how to test for OSX, were a hack that probably broke the build
for other platforms.

Now:
  In ObjC.h, MACOSX is defined if defined(__APPLE__) && defined(__MACH__)

  #ifdef MACOSX is used elsewhere.

I did it that way because I think the __APPLE__ & __MACH__ trick is
a little too tricky -- I would rather eventually change it so that
setup adds a -D line with system name.

I tried to make it #define DARWIN at first, but the compiler
complained about it. Somewhere there is a precompiled header
that uses DARWIN, but I didn't want to rely on it being defined
elsewhere until I can find it.

I'll probably try to see if I can shake out any more bugs, and
then make a tar file and put it on sourceforge as a release.

-- Steve Majewski

[Pyobjc-dev] Doc, it hurts when I say +isKindOfClass...

[Steven D. M. <sd...@mi...>]

In the following code, the classes in skiplist will all
generate objective-c runtime exceptions if they are touched:

----
from pyobjc import runtime,lookup_class

_Pool = runtime.NSAutoreleasePool()

skiplist = [ 'NSConcreteProtocolChecker', 'NSDistantObject',
        'NSInvocationBuilder', 'NSMutableStringProxy', 'NSProtocolChecker'
,
        'NSProxy' , '_NSZombie' ]

for x in runtime.__objc_classes__:
        if x not in skiplist:
                print x
                print lookup_class(x)
----


All of the exceptions happens in ObjCObject_new().


#   NSConcreteProtocolChecker
#   NSDistantObject
#   NSMutableStringProxy
#   NSProtocolChecker
#   NSProxy
# Apr 05 23:54:51 python[2259] *** Uncaught exception:
<NSInvalidArgumentException> *** -[NSProxy forwardInvocation:] called!
#
# caused by: [obj isKindOfClass: [NSAutoreleasePool class]]
#
#
#   NSInvocationBuilder
# Apr 05 23:54:41 python[2256] *** Uncaught exception:
<NSInvalidArgumentException> target does not implement method
#
# caused by: [obj respondsToSelector:@selector (count)]
#
#
#   _NSZombie           Bus error
 (seems to be somewhere close to the one above)

I'm quite willing to believe that whatever "_NSZombie" is, it
probably shouln't be touched. Most likely all of the classes
with a leading underscore in their names are not meant to be
exposed and should be removed from the Python-Objc runtime.

NSInvocationBuilder is undocumented (not even in the header
files) and I'm even unable to see it in the Class Introspector.

All of the first bunch, except for NSProxy are all subclasses of NSProxy.
NSProxy is another root class that is independent of NSObject.
Looking at NSProxy with the Class Introspector, I can see that indeed,
there is no class method for isKindOfClass: as there is in NSObject.
( NSObject has both a Class and an Instance isKindOfClass: )


I was looking at this problem too see if it was related to some of
the delegation bugs I've run into, but I'm now pretty convinced they
are probably unrelated. I'm not sure if there is any likey case in
which those classes would need to be called from Python -- perhaps
they should all be removed from the runtime.

For now, I'm going to leave them alone with just this warning:
 don't try to access any of those classes from python.

Does anyone know:
Is there a reason that +[NSProxy isKindOfClass:] is not implemented
or is it just an oversight (bug) ?

-- Steve Majewski

Re: [Pyobjc-dev] modified pyobjc module

[Bill B. <bb...@co...>]

Yeah-- you need to add '.m' to the list of extensions in unixcompiler.py in  
distutils.

I'll submit a patch to sourceforge shortly unless someone beats me to it.

From: "Steven D. Majewski" <sd...@mi...>
Date: 2001-03-30 18:02:46 -0500
To: Bill Bumgarner <bb...@co...>
Subject: Re: [Pyobjc-dev] modified pyobjc module
cc: pyo...@li...
In-Reply-To: <0GA...@mt...>
List-Id: python<->ObjC module dev discussion <pyobjc-dev.lists.sourceforge.net> 
List-Post: <mailto:pyo...@li...>
X-BeenThere: pyo...@li...
List-Unsubscribe:
<http://lists.sourceforge.net/lists/listinfo/pyobjc-dev>,<mailto:pyo...@li...?subject=unsubscribe>  

List-Help: <mailto:pyo...@li...?subject=help>
X-Mailman-Version: 2.0.3
List-Archive: <http://lists.sourceforge.net/archives//pyobjc-dev/>
List-Subscribe:
<http://lists.sourceforge.net/lists/listinfo/pyobjc-dev>,<mailto:pyo...@li...?subject=subscribe>  

MMDF-Warning: Parse error in original version of preceding line at mail.virginia.edu 

On Sat, 17 Mar 2001, Bill Bumgarner wrote:

> I moved the module over to using the distutils form of build system.  It
> is much easier to maintain, has a better chance of portability and gives
> us the ability to build source and binary distribution archives
> trivially.


Bill -- when I do a "python setup.py build" with this new setup, I get:


running build
running build_ext
building 'pyobjc' extension
Traceback (most recent call last):
  File "setup.py", line 23, in ?
    ext_modules = [Extension("pyobjc", sourceFiles)],
  File "/usr/local/lib/python2.1/distutils/core.py", line 157, in setup
    raise SystemExit, "error: " + str(msg)
SystemExit: error: unknown file type '.m' (from 'OC_PythonBundle.m')


-- Steve Majewski



_______________________________________________
Pyobjc-dev mailing list
Pyo...@li...
http://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] modified pyobjc module

[Steven D. M. <sd...@mi...>]

On Sat, 17 Mar 2001, Bill Bumgarner wrote:

> I moved the module over to using the distutils form of build system.  It
> is much easier to maintain, has a better chance of portability and gives
> us the ability to build source and binary distribution archives
> trivially.


Bill -- when I do a "python setup.py build" with this new setup, I get:


running build
running build_ext
building 'pyobjc' extension
Traceback (most recent call last):
  File "setup.py", line 23, in ?
    ext_modules = [Extension("pyobjc", sourceFiles)],
  File "/usr/local/lib/python2.1/distutils/core.py", line 157, in setup
    raise SystemExit, "error: " + str(msg)
SystemExit: error: unknown file type '.m' (from 'OC_PythonBundle.m')


-- Steve Majewski

[Pyobjc-dev] modified pyobjc module

[Bill B. <bb...@co...>]

I moved the module over to using the distutils form of build system.  It
is much easier to maintain, has a better chance of portability and gives
us the ability to build source and binary distribution archives
trivially.

b.bum

[Pyobjc-dev] Cocoa from CPython+PyObjC vs. Jython

[Steven D. M. <sd...@mi...>]

---------- Forwarded message ----------
Date: Wed, 28 Feb 2001 11:38:18 -0500 (EST)
From: Steven D. Majewski <sd...@vi...>
To: Finn Bock <bc...@wo...>
Cc: jyt...@li..., pyt...@py...
Subject: Re: [Jython-users] Re: [Pythonmac-SIG] Cocoa from Jython on MacOSX
Resent-Date: Wed, 28 Feb 2001 11:39:50 -0500 (EST)
Resent-From: "Steven D. Majewski" <sd...@vi...>
Resent-To: sd...@mi...
Resent-Subject: Re: [Jython-users] Re: [Pythonmac-SIG] Cocoa from Jython on
 MacOSX


-- cut the irrelevant stuff about Jython+Java --


I was able to get a slightly modified version of one of my PyObjC
AppKit  test programs to work in Jython. The main difference is
that the CPython <-> Objective-C bridge does a different name
mangling than the Java bridge does. PyObjC tries to pythonify
the objective-C method names -- for example

the objective-c statement:

 [ win initWithContentRect:rect styleMask:mask  backing:YES defer:NO ];

actually uses the message selector:

  initWithContentRect:style:Mask:backing:defer:

which gets name mangled by PyObjC to:

  win.initWithContentRect_styleMask_backing_defer_ (frame, mask, YES, NO )


but Jython gets to use the Java bridge's use of Java overloading of
different polymorphic versions of the same method name (so there are
a couple of different initWithContentRect 's with different numbers
of args. ).

In Jython:

  win.initWithContentRect( frame, mask, YES, NO )


( I don't know yet what happens when there are are two objective-c
  methods with the same number but different args. )

I think there was some discussion on the old pyobjc-sig mailing list
on whether or not to attempt this sort of overloading or to keep the
more explicit name transformation. We may wish to revisit this
decision -- it would be nice to have the same Cocoa bindings for Jython
and CPython+PyObjC.


-- Steve Majewski

[Pyobjc-dev] CVS and SSH now working (at least for me!)

[Steven D. M. <sd...@mi...>]

*Finally* ssh and cvs access is working for me.

Maybe it was the sourceforge staff returning from LinuxWorld,
or maybe it was that I changed my password ONE-MORE-TIME just
in case it had fallen thru the cracks.

Can someone else verify that they can ssh or cvs (authenticated,
not anonymous, which has been working all along) so that I
know it's not just me.

If it's finally working, maybe we can get something off the
ground here!

-- Steve Majewski

[Pyobjc-dev] pyobjc.sourceforge.net

[Steven D. M. <sd...@mi...>]

[Trying this again from the right machine.]

Although nothing has changed in the cvs repository or the pyobjc
web pages at sourceforge, there *HAS* been some work going on.

If you look at some of the discussion forums, you will see that
an awful lot of folks are having trouble with ssh & cvs since
the recent move and upgrades at SourceForge.

On comp.lang.python on Wed, 24 Jan 2001, Tim Peters wrote:

> > Does anyone know what going on at SourceForge ?
>
> According to http://sourceforge.net/ today,
>
>     Hosted Projects:   14,366
>     Registered Users: 110,619
>
> I guess that if we dug deep enough, that would pretty much explain
> everything <0.3 wink>.
>
> growing-pains-ly y'rs  - tim
>

The problem seems to be with a backlog of new projects which all
require some manual setup or intervention.

I figure we can give it another week or so, to see if they get it
together, before we take up discussion of looking for another site
to host development.

BTW: The Python 2.1a1 distribution seems to have all of the patches
to build on Mac OSX with objc support. However, they changed some
of the setup and module building to use disutils, and a couple of
new things broke. Most of these are being patched for the next
release. pyobjc *ALMOST* builds "out of the box" for the new python2.1a1:
The lib/python2.1/config/makesetup script has changed from using $(CCC)
to $(CXX), and the default for that is "g++" , so if it's not set to
"c++" it won't work on OSX. ( I'm not sure that I'ld call that a bug,
and we're probably going to have to update the setup to disutils
anyway, so we might as well fix it there. )


BTW2: Actually, the old build of ObjC.so still worked with 2.1a1,
but I wanted to test that it would build with the new distribution.

-- Steve Majewski

[Pyobjc-dev] [super forwardInvocation:invocation];

[Steven D. M. <sd...@mi...>]

OC_PythonObject's forwardInvocation, at the end calls:

	[super forwardInvocation:invocation];

However, it's superclass is NSProxy, which is an abstract class
that doesn't implement forwardInvocation: , so you get an error,
for example, when I try to set my application's  delegate to a
python class instance:


    NSApp.setDelegate_( Delegate() )
ObjC.error: *** -[NSProxy forwardInvocation:] called!


If you comment out the super forwardInvocation, you loose that
error message.

Deletages still don't work, BTW, but I think it may be that the
proxy object doesn't implement the methods (applicationWillBecomeActive,
for example) -- the python object does. The doc's state that if the
delegate implements the method, it will be called at the appropriate
time. It doesn't state how that is determined, but since the proxy
object itself doesn't implement those methods, I'm guessing it's
looking directly at the proxy class.

We probably need to add stub implementations of those methods to the
proxy object.

-- Steve Majewski <sd...@Vi...>

[Pyobjc-dev] todo (feel free to add items)

[Steven D. M. <sd...@mi...>]

ToDo's:

[1] make a todo list.

[2] Get a snapshot of Python2.0 with the objc patches online
    as well as a pyobjc snapshot on sourceforge.

[3] documentation, documentation, documentation...

[4] examples, examples, examples...

[5] Fix NSProxy/OC_PythonObject problems.

[6] start a module of useful utility and wrapper functions, for example:

rt = ObjC.runtime       # abbreviations
def LoadBundle( path ):
        Bundle = rt.NSBundle
        bundle = Bundle.bundleWithPath_( path )
        bundle.load()
        return bundle

used as:
AppKit = LoadBundle( '/System/Library/Frameworks/AppKit.framework')


( maybe also a more abbreviated NSAutoreleasePool creation -- it
  would be handy for interactive use . What else? )



-- Steve Majewski <sd...@Vi...>

[Pyobjc-dev] pyobjc introspection

[Steven D. M. <sd...@mi...>]

There's been a discussion thread on mac...@om... on
how to get all of the methods of a class. ( I'ld like to give
pyobjc classes the same sort of introspection capabilities that
normal python objects have. )

I got some objc code from Pierre Thibault (on that list) that
implements some introspection classes for obj-c. ( It doesn't
seem to get all of the methods from all of the categories -- which
is part of the ongoing discussion in that thread. )

 If he publicly releases that code, I'll make the framework and
my python wrapper code available. In any case, I'ld like to see
some similar functionality built into pyobjc. ( I'm used to using
dir() and __doc__ to figure out how to use python modules -- it
was a bit confusing to find that all pyobjc classes seem to have
the same three attributes: ['Class', 'isClass', 'isInstance'], and
nothing else. ( The runtime checks that the class responds to the
selector you give it, but it can't tell you all of the selectors. )

-- Steve Majewski <sd...@Vi...>

Re: [Pyobjc-dev] working code examples ?

[Steven D. M. <sd...@mi...>]

On Wed, 20 Dec 2000, Steven D. Majewski wrote:

> On Wed, 20 Dec 2000, Bill Bumgarner wrote:
>
> > Do you have the code you are testing with so far?
>
> I am doing the setTarget: setAction: calls.
>  I'm not using IB, but maybe I still need to define a delegate --
> the error I'm getting is:
>
>   Error 1011 in _sendFinishLaunchingNotification
>


I've cleaned up the code a bit. (Enclosed Below).

If run normally from python, it displays the window, but doesn't respond
to a button down, prints the above error message, and gets stuck in the
run loop so I have to kill the process from another terminal window.

However, I've discovered that if I run it from python under gdb, it
works properly: I can grab and move the window and on button down,
it exits the run-loop and gives me a python prompt!

Any clues ???


% gdb python
(gdb) run
...
>>> import LBW
>>> LBW.run()


-- Steve Majewski


#!/usr/local/bin/python
#
# Heavily modified following an example by Lele Gaifax
# that no longer works under OSX.
# This seems to work under 'gdb python', but not without the debugger. (?)
#
# -- Steve Majewski <sd...@Vi...>
#

from time import sleep

def run():
    import ObjC

    rt = ObjC.runtime

    POOL = rt.NSAutoreleasePool
    p = POOL()

    rt.NSBundle.bundleWithPath_( '/System/Library/Frameworks/AppKit.framework' ).load()

    NSApp = rt.NSApplication.sharedApplication()

    win = rt.NSWindow.alloc()
    frame = ((200.0, 300.0), (250.0, 100.0))
    win.initWithContentRect_styleMask_backing_defer_ (frame, 15, 2, 0)
    win.setTitle_ ('Little.Button.Window')
    win.setLevel_ (3)			# floating window

    but = rt.NSButton.alloc().initWithFrame_ (((10.0, 10.0), (80.0, 80.0)))
    win.contentView().addSubview_ (but)

    but.setBezelStyle_( 4 )
    but.setTarget_ (NSApp)
    but.setAction_ ('stop:')
    but.setEnabled_ ( 1 )

    win.display()
#    win.makeKeyAndOrderFront_ (NSApp)	## This doesn't seem to  work
    win.orderFrontRegardless()		## but this one does

    for i in range(5):		## testing: change button hilight display
       but.highlight_( i % 2 )
       win.display()
       sleep(1)

    NSApp.run()



if __name__ == '__main__' : run()

Re: [Pyobjc-dev] working code examples ?

[Steven D. M. <sd...@mi...>]

On Wed, 20 Dec 2000, Bill Bumgarner wrote:

> Do you have the code you are testing with so far?

It's pretty chopped up at the moment -- which is why I was
asking if anyone had a better sample.  I've got sections that
weren't working commented out, but I need to retest some of that
code with the new build. I've started -- which is why I added the
note about loading the AppKit bundle -- my old version had that
linked in. etc. etc.


> You need to star the Application's event loop before you can really
> do anything like handling button presses.    After creating your
> button, call the -setTarget: and -setAction: methods appropriately to
> set up the target/action for when the button is pressed.
>
> Alternatively, loading a main NIB file as created by
> InterfaceBuilder would set up all the target/action stuff correclty
> for a main menu,  etc... just make your python object the delegate of
> the Application object to allow your custom python code to handle
> the various events passing down the responder chain.
>

I am doing the setTarget: setAction: calls.
 I'm not using IB, but maybe I still need to define a delegate --
the error I'm getting is:

  Error 1011 in _sendFinishLaunchingNotification


-- Steve Majewski

Re: [Pyobjc-dev] working code examples ?

[Bill B. <bb...@co...>]

Do you have the code you are testing with so far?

You need to star the Application's event loop before you can really  
do anything like handling button presses.    After creating your  
button, call the -setTarget: and -setAction: methods appropriately to  
set up the target/action for when the button is pressed.

Alternatively, loading a main NIB file as created by  
InterfaceBuilder would set up all the target/action stuff correclty  
for a main menu,  etc... just make your python object the delegate of  
the Application object to allow your custom python code to handle  
the various events passing down the responder chain.

b.bum

From: "Steven D. Majewski" <sd...@mi...>
Date: 2000-12-20 17:38:08 -0500
To: pyo...@li...
Subject: [Pyobjc-dev] working code examples ?
List-Id: python<->ObjC module dev discussion
<pyobjc-dev.lists.sourceforge.net>
MMDF-Warning: Parse error in original version of preceding line at
mail.virginia.edu
List-Post: <mailto:pyo...@li...>
X-BeenThere: pyo...@li...
List-Unsubscribe:
<http://lists.sourceforge.net/mailman/listinfo/pyobjc-dev>,<mailto:pyo...@li...?subject=unsubscribe>  

List-Help:
<mailto:pyo...@li...?subject=help>
X-Mailman-Version: 2.0
List-Archive: <http://lists.sourceforge.net/archives//pyobjc-dev/>
List-Subscribe:
<http://lists.sourceforge.net/mailman/listinfo/pyobjc-dev>,<mailto:pyo...@li...?subject=subscribe>  




BTW: Does anyone have any examples of code that actually works
under Mac OSX ?

I can get a window with a button to pop up (starting from some
example code from one of the older snapshots on codefab.com --
LBW.py  -- "little button window"  ) but none of the "application"
stuff works -- i.e. I can't get it to quit from the button.

BTW: a few notes for those trying to get started:


    import ObjC

    rt = ObjC.runtime

# You need to create an autorelease pool to avoid all of those annoying 
#  'no pool -- just leaking' warning messages:

    POOL = rt.NSAutoreleasePool
    p = POOL()

# and if you want to access AppKit classes from the runtime,
# you have to load that bundle:

rt.NSBundle.bundleWithPath_('/System/Library/Frameworks/AppKit.framework').load()  




... and if you're testing out some code and actually want to see what 
happens to your window while you're in the python interpreter in a
terminal.app window, you can make your AppKit window a floating window 
with setLevel:

    win.setLevel_ (3)


-- Steve Majewski <sd...@Vi...>



_______________________________________________
Pyobjc-dev mailing list
Pyo...@li...
http://lists.sourceforge.net/mailman/listinfo/pyobjc-dev

[Pyobjc-dev] working code examples ?

[Steven D. M. <sd...@mi...>]

BTW: Does anyone have any examples of code that actually works
under Mac OSX ?

I can get a window with a button to pop up (starting from some
example code from one of the older snapshots on codefab.com --
LBW.py  -- "little button window"  ) but none of the "application"
stuff works -- i.e. I can't get it to quit from the button.

BTW: a few notes for those trying to get started:


    import ObjC

    rt = ObjC.runtime

# You need to create an autorelease pool to avoid all of those annoying
#  'no pool -- just leaking' warning messages:

    POOL = rt.NSAutoreleasePool
    p = POOL()

# and if you want to access AppKit classes from the runtime,
# you have to load that bundle:
    rt.NSBundle.bundleWithPath_('/System/Library/Frameworks/AppKit.framework').load()



... and if you're testing out some code and actually want to see what
happens to your window while you're in the python interpreter in a
terminal.app window, you can make your AppKit window a floating window
with setLevel:

    win.setLevel_ (3)


-- Steve Majewski <sd...@Vi...>

[Pyobjc-dev] OC_PythonObject broken

[Steven D. M. <sd...@mi...>]

 It looks like the mailings list is working -- with some delay --
as long as I post from the machine I'm subscribed under.
( and since my mac gets a random address & number depending on
where I hook it up to the network, I can't mail from there. )

 Although I'm one of the project admins, I'm pretty new to both
objective-c and the pyobjc module, but since a lot of the revived
interest has been sparked by Mac-OSX, I'm sure there are others
out there trying to learn their way around the code.

 It looks like OC_PythonObject is broken.

 OC_PythonObject is the bridge between python objects and objective-c
objects that implements the NSProxy abstract class and redirects
method calls to it's python methods. ( For example, this would be how you
would subclass NSApplication in Python to make an AppKit application.)

There are a number of things in PyObjC.runtime that you can't touch:
ObjC.lookup_class( 'OC_PythonObject' ) for example, dies with:

Dec 19 18:19:37 python[435] *** Uncaught exception:
<NSInvalidArgumentException> *** -[NSProxy forwardInvocation:] called!


This appears to be the line that crashes:

  if (obj && ([obj isKindOfClass: [NSAutoreleasePool class]] == NO) )


OC_PythonObject's have define an instance method

 - (void)forwardInvocation:(NSInvocation *)anInvocation;

to do this forwarding, but there's no class method, so isKindOfClass:
on the class object causes the crash.

I did a quick patch to try to follow this further:

PythonObject.m
246,253d245
< + (void)forwardInvocation:(NSInvocation *)anInvocation;
< {
<   printf( "%s\n" , [[anInvocation description] cString] );
<   [anInvocation setTarget: [NSObject class]];
<   [anInvocation invoke];
<   return;
< }
<

with that, I can access ObjC.runtime.OC_PythonObject without
crashing.  However, accessing it's method dies:

>>> rt.OC_PythonObject.newWithObject_
Dec 20 15:53:57 python[407] *** Uncaught exception:
<NSInvalidArgumentException> *** -[NSProxy methodSignatureForSelector:]
called!

This was actually pretty expected, as forwardInvocation and
methodSignatureForSelector are documented as the two methods you
MUST override in a concrete NSProxy class.


A few other objects in the runtime will cause a crash. I made a little
script to iterate thru the __objc_classes__ and added them to a skiplist
until I could get thru the whole runtime. They are:

SkipList = ('NSProxy', 'NSConcreteProtocolChecker', 'NSDistantObject',
        'NSInvocationBuilder', 'NSMutableStringProxy' , 'NSProtocolChecker' ,
        '_NSZombie' )


-- Steve Majewski <sd...@Vi...>

[Pyobjc-dev] Testing: pyobjc-dev@lists.sourceforge.net

[Steven D. M. <sd...@mi...>]

My first message (send from MacOSX) didn't seem to work.
I'm trying again from the account I'm subscribed under.

-- Steve M.