pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Is there still life in this project? [n/t]

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

On Fri, 6 Jul 2001, Jonathan Wight wrote:

> Subject says it all...

 I believe so, but on my part, the summer has been full of
house remodeling, vacation, and now that I'm back, catching
up on the stuff I get paid to do!


-- Steve Majewski

[Pyobjc-dev] Is there still life in this project? [n/t]

[Jonathan W. <jwi...@ma...>]

Subject says it all...

Re: Reflection [Pyobjc-dev] Altered classes

[Bob S. <bob...@ma...>]

on 5/11/01 5:50 PM, Steven D. Majewski wrote:
> The pyobjc runtime doesn't keep a list of methods, but, after
> unmangling the python name to objc, it tests that the object
> respondsToSelector:

  <...>

> 
> I posted some notions earlier about adding more reflective abilities
> to pyobjc.
> 

Not sure how useful a comment this is, but you might want to take a look at
Joy http://www.aaa-plus.com/

You can examine classes and instances and see what their methods are, and
what the arguments and return values are.

Bob

[Pyobjc-dev] just getting started (was: Further evidence of the need to start over)

[Bob S. <bob...@ma...>]

on 5/11/01 2:50 PM, Bill Bumgarner wrote:

> On a related note, I have a couple of frameworks that bind the python
> interpreter into a Cocoa/Objc/WebObjects app such that you have a Python
> Interpreter ObjC object that you can toss arbitrary bits o' python code
> at.... including "import pyobjc".

Wow! that sounds great!

On to other matters. Not that I'll be a big help to you guys in this
project, but I wanted to get started, so I downloaded the current
distribution (2.1) and tried to install it. Unfortunately I obviously am not
doing it correctly, so I am hoping someone can suggest where my problem is.

Here is the tail of the make output:

/usr/include/objc/Object.h:160: illegal method definition, found `@end'
/usr/include/objc/Object.h:163: illegal method definition, missing `{' after
`)'
/usr/include/objc/Object.h:164: undefined type, found `Object'
/usr/include/objc/Object.h:165: undefined type, found `Object'
/usr/include/objc/Object.h:166: undefined type, found `Object'
/usr/include/objc/Object.h:167: undefined type, found `Object'
Python/dynload_next.c:30: header file 'mach-o/rld.h' not found
Python/dynload_next.c:51: undefined type, found `NXStream'
cpp-precomp: warning: errors during smart preprocessing, retrying in basic
mode
make: *** [Python/dynload_next.o] Error 1


I looked in the configure.log file, and see a lot of "failed program"
entries, but I don't know what is important and what isn't :(

Can anyone suggest what foolish thing I am doing (or not doing?)

thanks,

Bob

Re: [Pyobjc-dev] Altered classes

[Deirdre S. M. <de...@de...>]

>The original method was something like "loadNibNamed:owner:" -- i.e. 
>it takes two arguments and has two :'s.   The Python mangled version 
>is "loadNibNamed_owner_", as a result.

Doh! Of course.

>There is a lot more that goes on ApplicationMain and in the startup 
>of the application than you might otherwise expect given evidence at 
>runtime.   In particular, there is all kinds of binding to the 
>Finder and the WindowServer, etc...

I knew it. Voodoo. :)

>I know why the Application delegate stuff isn't working and how to fix it.

Neat. :)

>I'll try to do so on the train home tonight and commit the code 
>tonight/tomorrow.   It ain't pretty but, thankfully, I solved the 
>problem before.   (If interested, see the mssh project-- 
>http://www.codefab.com/pub/unsupported.  While there, see 
>NoisyAppKit-- it spews everything that happens at app launch on mach 
>ports...).

-- 
_Deirdre     Stash-o-Matic: http://weirdre.com      http://deirdre.net
Macintosh Developer (seeking work): Will work for Cocoa
"I love deadlines. I like the whooshing sound they make as they fly by."
                                                          - Douglas Adams

[Pyobjc-dev] Fwd: A bit more progress (MacOS X)

[Deirdre S. M. <de...@de...>]

This is really Jython, but on the off chance it might shed some 
light, I'm also posting it here.

>Based on some of the stuff that Steven Majewski did, trying to 
>create a Cocoa app that loads a nib from Jython. When running, I get 
>the following errors:
>
>% jython CurrencyConverter.jy
>(
>     NSBundle </System/Library/Frameworks/Foundation.framework> (loaded),
>     NSBundle </usr/lib> (loaded),
>     NSBundle </System/Library/Frameworks/JavaVM.framework> (loaded),
>     NSBundle </usr/lib/java> (loaded)
>)
>./build/CurrencyConverter2.app
>May 11 21:35:32 java[1110] Unknown class `ConverterController' in 
>nib file, using `NSObject' instead.
>May 11 21:35:32 java[1110] Unknown class `Converter' in nib file, 
>using `NSObject' instead.
>May 11 21:35:32 java[1110] Could not connect the action convert: to 
>target of class NSObject
>
>So...why doesn't it know about the classes?
>
>
>#!/usr/bin/env jython
>
>from com.apple.cocoa.foundation import *
>from com.apple.cocoa.application import *
>
>MyApp = None
>_pools = []
>
>tpath = './TempConverter/build/TempConverter.app'
>cpath = './build/CurrencyConverter2.app'
>
>class Converter(NSObject):
>	def convert(amount, rate):
>		return (amount * rate)
>
>class ConverterController(NSObject):
>	def __init__():
>		self.converter = Converter()
>		self.dollarField = NSTextField()
>		self.rateField = NSTextField()
>		self.totalField = NSTextField()
>
>	def convert(sender):
>		rate = self.rateField.floatValue();
>		amount = self.dollarField.floatValue();
>		total = converter.convert(amount, rate);
>        
>		self.totalField.setFloatValue(total);
>
>
>def xxx():
>         print NSBundle.allFrameworks()
>
>def Pool():
>         global _pools
>         tmp = NSAutoreleasePool.push()
>         _pools.append(tmp)
>         return tmp
>
>def App():
>         global MyApp
>         MyApp = NSApplication.sharedApplication()
>         return MyApp
>
>def Bundle( path=cpath ):
>	print path
>         return NSBundle.bundleWithPath( path )
>
>
>xxx()
>pool = Pool()
>myapp = App()
>bndl = Bundle()
>nib = NSApplication.loadNibFromBundle( bndl, 'MainMenu', myapp )
>if __name__ == '__main__' : myapp.run()

-- 
_Deirdre     Stash-o-Matic: http://weirdre.com      http://deirdre.net
Macintosh Developer (seeking work): Will work for Cocoa
"I love deadlines. I like the whooshing sound they make as they fly by."
                                                          - Douglas Adams

Re: [Pyobjc-dev] Altered classes

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

On Fri, 11 May 2001, Bill Bumgarner wrote:

> There is a lot more that goes on ApplicationMain and in the startup of
> the application than you might otherwise expect given evidence at
> runtime.   In particular, there is all kinds of binding to the Finder
> and the WindowServer, etc...

The objc runtime has been released as part of Darwin.
It's a pity they don't release the code for ApplicationMain too.
It's obvious that LOTS more is going on than what's documented.
(And it looks like it's going to be quite a while before Apple
 fills some of the holes and "To Be Determined"'s in the docs!
 That's the main thing I like about open source -- even more than
 the price. In my VMS days, DEC gave us a microfiche of the VMS
 sources  -- very unlikely that I was going to type it all in and
 steal their code -- but it was nice to know that it was POSSIBLE,
 even if difficult to find an answer!)

> I know why the Application delegate stuff isn't working and how to fix
> it.  I'll try to do so on the train home tonight and commit the code
> tonight/tomorrow.   It ain't pretty but, thankfully, I solved the
> problem before.   (If interested, see the mssh project--
> http://www.codefab.com/pub/unsupported.  While there, see NoisyAppKit--
> it spews everything that happens at app launch on mach ports...).

This is good news. But I'll probably still try building a debuggable
objc-runtime from Darwin sources -- it still may come in handy to be
able to step across the bridge in debugging!


-- Steve Majewski

[Pyobjc-dev] Nib loading [was: Altered classes]

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

[ Jon Harald also asked me directly about Nibs.
  You might want to subscribe to the pyobjc-dev mailing list
  at sourceforge, where we're discussion some of these problems.
  The short answer is that pyobjc isn't quite ready for prime-time
  AppKit apps yet -- there are a couple of important features that either
  don't work correctly, or we haven't figured out how to get them to
  work. We're also considering writing off this version as an experiment
  (it's pretty ancient both in it's objc and it's python features) and
  starting over with a better design. You're not going to get a useful
  AppKit GUI app writting this path, but you're likely to learn quite
  a bit about objective-C and Python internals and runtime if you
  stick around.  ]


Here is the **Jython** version of a program which sort-of-works:
It is able to load the nib file from the Temperature Converter
java tutorial  or the Currency Converter  objective-c tutorial.
( With a few less errors/warnings written to the terminal running
  the Java app I believe. )

It loads and instatiates the window from the Nib file, and all
of the default behaviour, but none of the special behavior works.
(i.e. You can move the window around, enter text, tab to next
field, but clicking convert button for example, does nothing.)

----
from com.apple.cocoa.foundation import *
from com.apple.cocoa.application import *

MyApp = None
_pools = []

tpath = './TempConverter/build/TempConverter.app'
cpath = './CurrencyConverter/build/CurrencyConverter.app'

def xxx():
        print NSBundle.allFrameworks()

def Pool():
        global _pools
        tmp = NSAutoreleasePool.push()
        _pools.append(tmp)
        return tmp

def App():
        global MyApp
        MyApp = NSApplication.sharedApplication()
        return MyApp

def Bundle( path=cpath ):
        return NSBundle.bundleWithPath( path )


xxx()
pool = Pool()
myapp = App()
bndl = Bundle()
nib = NSApplication.loadNibFromBundle( bndl, 'MainMenu', myapp )
if __name__ == '__main__' : myapp.run()

----

Note that the Java AppKit API has
  NSApplication.loadNibFromBundle( bundle, name, owner )

The bundle is created with a path, and the Nib is inside that bundle.

In objective C, the equivalent methods are NSBundle additions, not
NSApplication methods. ( Java doesn't have categories -- I assume
that is one of the reasons for the change. Objective-C can load
additional methods for an already defined class, and AppKit adds
several methods to several existing Foundation classess. ):


+ loadNibFile:externalNameTable:withZone:
+ loadNibNamed:owner:
- loadNibFile:externalNameTable:withZone:

(That's NSBundle.loadNibFile_externalNameTable_withZone_() in Python.)

+loadNibNamed:owner:  just expects a nib file name, not a full path.
It looks in the mainBundle, which for my python turns out to be
"/usr/local/bin" . So that one doesn't work.

For the others: I think I've tried both the class and instance methods.
Neither works -- I get a number back which I haven't been able to
interpret as any meaningful error code.

The class method takes a complete pathname -- the instance method,
I think, wants only a name and has a default search path.

I've been passing an empty dictionary. ( Maybe this has to be
filled for it to work -- I was hoping, as with the Jython code,
to get at least partial results without it.)

I've been getting the zone from the zone method of my NSApp instance.

I'm not absolutely positive I've tried all the possible likely
legal combinations.

BTW: A lot of the other docs on Nib loading are missing ("To Be
Determined" )

I'm not at all experienced in doing this from objective-C --
I think I ought to give it a try that way and make sure that
I can figure out the correct combination without the worry
of the python-objc bridge getting in the way. Then, translate
that working code to Python.


This is not "official" work (although, if it could be made to
work, I could more easily justify the time  -- it's a chicken
and egg management problem! ;-) -- so it's fighting for my
limited spare time and intermittently hacking on it hasn't
made for sustained progress!


-- Steve Majewski

Reflection [Pyobjc-dev] Altered classes

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

On Fri, 11 May 2001, Deirdre Saoirse Moen wrote:

> Furthermore, I can't seem to get it to want to list all of NSBundle's
> methods, so I'm not sure I'm asking for the right thing.

dir(runtime.NSBundle) only shows:
	['Class', 'isClass', 'isInstance']

it doesn't show the class methods as it would for a Python Class.

The pyobjc runtime doesn't keep a list of methods, but, after
unmangling the python name to objc, it tests that the object
respondsToSelector:

Deirdre -- you might want to look at the section on proxies in
the objective-C PDF book in the Mac Developer docs to get an
idea about what's going on in the bridge and why.

I posted some notions earlier about adding more reflective abilities
to pyobjc.

www.neodata-inc.com has a class introspector app which I also
built as a pyobjc loadable bundle, so you can get info about
a classes methods. But this is something, which if there is a
grand rewrite, ought to be builtin to the runtime, so they
give the same sort of reflection info that Python classes give.


-- Steve Majewski

Re: [Pyobjc-dev] Altered classes

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

On Fri, 11 May 2001, Bill Bumgarner wrote:

> Has anyone tried creating a Python object and setting it as NSApp's
> delegate, then seeing if you could grab notifications??

Yes. I haven't been able to get them to work.

I had a variant of HelloWorld -- actually based on LBW (LittleButtonMouse)
but creating a Python class instance to register as a delegate.
Registering the delegate seems to work but it never gets called.

After this discussion of name mangling, I was just wondering if I
misnamed the methods in Python:  "applicationShouldTerminate_" , etc.

I tried a simpler program using my own defined notifications and
posting it myself so I had more control over what was going on --
it gets a bus error after posting the notification.

I tried running it under gdb to see if I could find what was wrong --
my conclusion from that is that I'm going to have to build an
objc-runtime from Darwin sources with debugger info and sources
online so that I can step thru the objc-runtime code -- which is
where things seem to go wrong. ( Not that it's the objc-runtime --
I'm pretty sure the problem is pyobjc-runtime, but to find that bug I
think I  need to back up from the error in the objc-runtime.   )


-- Steve Majewski
( getting more and more sold on the rewrite idea! )

Re: [Pyobjc-dev] Further evidence of the need to start over (fwd)

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

[ Trying one more time to get this sent from the right machine so
  the mailing-list manager program will accept it! <groan> ]


---------- Forwarded message ----------
Date: Fri, 11 May 2001 19:52:38 -0400 (EDT)
From: Steven D. Majewski <sd...@Vi...>
To: Bill Bumgarner <bb...@CO...>
Cc: Yves Starreveld <yst...@uw...>, pyo...@li...
Subject: Re: [Pyobjc-dev] Further evidence of the need to start over
Resent-Date: Fri, 11 May 2001 19:58:53 -0400 (EDT)
Resent-From: "Steven D. Majewski" <sd...@Vi...>
Resent-To: sd...@mi...
Resent-Subject: Re: [Pyobjc-dev] Further evidence of the need to start over



On Fri, 11 May 2001, Bill Bumgarner wrote:

> OK-- I "fixed" the problem with forwardInvocation: being invoked on
> NSProxy.   Was a matter of not passing -forwardInvocation: off to super
> in OC_PythonObject.m.
>
> It seems to kind of fix the problem.  However, after a couple of runs of
> HelloWorld.py, I'm no longer able to execute that script due to a Window
> Manager issue-- either with the original version or new version of
> OC_PythonObject.m.

I did this at one time in one of my experimental versions -- I had thought
I posted something about it, but it was probably before you started
up this list -- it may have been in one of my summaries to pythonmac-sig
-- or maybe I'm just imagining it!


I know I took it out before merging my changes into CVS.
I recall running some experiments with and without that patch --
I should still have some notes.

> As such, I really think we need to do two things:
>
> 	- rewrite the PyObjC bridge entirely and aim it *only* at solving
> the Foundation and below problem (while removing cruft from almost 8
> years ago, at this point)
>

I caught up with reading some threads on python-dev about plans to
fix the class-instance/builtin-object split in Python, and was
reading up on the metaclass hack and Jim Fultons extension classes.

[ See: <http://www.python.org/doc/essays/metaclasses/>  or
  look in the Demo subdirectory of your python source distribution. ]

The class/object split is one of the things that needs to be fixed
in a rewrite: Objective-C classes are Python objects but not
Python classes, so you can't extend an objective-C class directly.

The Python BOOST C++ library uses the metaclass hack to make C++
classes extensible in Python.


-- Steve Majewski


[ PS. I *am* going to answer some of Deidre's other questions --
  I've been out of the office a bit lately -- trying to get my
  other car to pass inspection, and selling off a big chunk of
  of my library -- but in between that I've been trying to see
  if I could find a way around some of the problems. ]

[Pyobjc-dev] Further evidence of the need to start over

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

OK-- I "fixed" the problem with forwardInvocation: being invoked on 
NSProxy.   Was a matter of not passing -forwardInvocation: off to super 
in OC_PythonObject.m.

It seems to kind of fix the problem.  However, after a couple of runs of 
HelloWorld.py, I'm no longer able to execute that script due to a Window 
Manager issue-- either with the original version or new version of 
OC_PythonObject.m.

As such, I really think we need to do two things:

	- rewrite the PyObjC bridge entirely and aim it *only* at solving 
the Foundation and below problem (while removing cruft from almost 8 
years ago, at this point)

	- write a new module that leverages pyobjc and adds the necessary 
support for dealing with AppKit based scripting.   In particular, I'm 
thinking of putting together a python module (via distutils) that 
contains an application wrapper with all the appropriate glue.  Invoking 
a script that wants to use the appkit would import this module and call 
into it with a reference back to the object that wants to be the app 
delegate.  The module would then launch in the same fashion as any 
normal AppKit project, but would look to the python world for all app 
related constructs.

Hmmm... gotta give this thought.

On a related note, I have a couple of frameworks that bind the python 
interpreter into a Cocoa/Objc/WebObjects app such that you have a Python 
Interpreter ObjC object that you can toss arbitrary bits o' python code 
at.... including "import pyobjc".

b.bum

Re: [Pyobjc-dev] Altered classes

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

The original method was something like "loadNibNamed:owner:" -- i.e. it 
takes two arguments and has two :'s.   The Python mangled version is 
"loadNibNamed_owner_", as a result.

There is a lot more that goes on ApplicationMain and in the startup of 
the application than you might otherwise expect given evidence at 
runtime.   In particular, there is all kinds of binding to the Finder 
and the WindowServer, etc...

I know why the Application delegate stuff isn't working and how to fix 
it.  I'll try to do so on the train home tonight and commit the code 
tonight/tomorrow.   It ain't pretty but, thankfully, I solved the 
problem before.   (If interested, see the mssh project-- 
http://www.codefab.com/pub/unsupported.  While there, see NoisyAppKit-- 
it spews everything that happens at app launch on mach ports...).

b.bum


On Friday, May 11, 2001, at 04:12 PM, Deirdre Saoirse Moen wrote:

>> Basically, pyobjc mangles the ObjC selector names by substituting _ 
>> for each : (because : is reserved in python).
>
> I guess what I don't understand is why the *trailing* underscore. I did 
> understand the underscore bit though.
>
>> As well, there will be a certain line beyond which we really, really, 
>> really need to have the Main Event Loop running to do anything from 
>> Python to the Appkit...
>
> Understandable. In looking through AppKit, it seems that it loads all 
> the stuff prior to the main loop, but I could be wrong. Basically I was 
> trying it before running the app, but maybe that's the wrong approach.
>
> If you look at the Main file from an existing PB project, this is what 
> it looks like these days:
>
> #import <Cocoa/Cocoa.h>
>
> int main(int argc, const char *argv[])
> {
>     return NSApplicationMain(argc, argv);
> }
>
> Maybe the Nib loading problem is from trying to use something other 
> than that specific function?
>
> Unfortunately, in the example below, it doesn't exist:
>
> import pyobjc
> import sys
>
> rt = pyobjc.runtime
>
> def main():
>
>     pool = rt.NSAutoreleasePool()
>     # Load Application Framework:
>     foundationKit = rt.NSBundle.bundleWithPath_(
>         '/System/Library/Frameworks/Foundation.framework').load()
>     appKit = rt.NSBundle.bundleWithPath_(
>         '/System/Library/Frameworks/AppKit.framework').load()
>
>     Doc = rt.NSDocument.alloc()
>     Nib = rt.NSBundle.loadNibNamed_owner_("MainMenu.nib", Doc)
> #    print Nib
>
>     return rt.NSApplicationMain(len(sys.argv), sys.argv)
>
> if __name__ == '__main__' :
>     main()
>
>
>> Has anyone tried creating a Python object and setting it as NSApp's 
>> delegate, then seeing if you could grab notifications??
>
> Since people have tried this, I'd be interested in what *everyone* has 
> tried, what did work and what didn't. I can make a coherent document 
> out of it and then maybe that will open the door for other "bang and 
> slash" people to try and figure out stuff. Then it won't be so lonely 
> here. :)
>
> -- _Deirdre     Stash-o-Matic: http://weirdre.com      
> http://deirdre.net
> Macintosh Developer (seeking work): Will work for Cocoa
> "I love deadlines. I like the whooshing sound they make as they fly by."
>                                                          - Douglas Adams

Re: [Pyobjc-dev] Altered classes

[Deirdre S. M. <de...@de...>]

>Basically, pyobjc mangles the ObjC selector names by substituting _ 
>for each : (because : is reserved in python).

I guess what I don't understand is why the *trailing* underscore. I 
did understand the underscore bit though.

>The second problem sounds more like an Appkit initialization 
>problem-- did you have a look at Steve's AppKit example?   Make sure 
>something like that works first, then try loading the NIB.  If the 
>NIB loading is still broken, then we have an additional 
>initialization phase at the AppKit level we haven't taken care of 
>yet.

Yes, I've been working from that example and modifying it.

>As well, there will be a certain line beyond which we really, 
>really, really need to have the Main Event Loop running to do 
>anything from Python to the Appkit...

Understandable. In looking through AppKit, it seems that it loads all 
the stuff prior to the main loop, but I could be wrong. Basically I 
was trying it before running the app, but maybe that's the wrong 
approach.

If you look at the Main file from an existing PB project, this is 
what it looks like these days:

#import <Cocoa/Cocoa.h>

int main(int argc, const char *argv[])
{
     return NSApplicationMain(argc, argv);
}

Maybe the Nib loading problem is from trying to use something other 
than that specific function?

Unfortunately, in the example below, it doesn't exist:

import pyobjc
import sys

rt = pyobjc.runtime

def main():

     pool = rt.NSAutoreleasePool()
     # Load Application Framework:
     foundationKit = rt.NSBundle.bundleWithPath_(
         '/System/Library/Frameworks/Foundation.framework').load()
     appKit = rt.NSBundle.bundleWithPath_(
         '/System/Library/Frameworks/AppKit.framework').load()

     Doc = rt.NSDocument.alloc()
     Nib = rt.NSBundle.loadNibNamed_owner_("MainMenu.nib", Doc)
#    print Nib

     return rt.NSApplicationMain(len(sys.argv), sys.argv)

if __name__ == '__main__' :
     main()


>Has anyone tried creating a Python object and setting it as NSApp's 
>delegate, then seeing if you could grab notifications??

Since people have tried this, I'd be interested in what *everyone* 
has tried, what did work and what didn't. I can make a coherent 
document out of it and then maybe that will open the door for other 
"bang and slash" people to try and figure out stuff. Then it won't be 
so lonely here. :)

-- 
_Deirdre     Stash-o-Matic: http://weirdre.com      http://deirdre.net
Macintosh Developer (seeking work): Will work for Cocoa
"I love deadlines. I like the whooshing sound they make as they fly by."
                                                          - Douglas Adams

Re: [Pyobjc-dev] Altered classes

[Yves S. <yst...@uw...>]

Hi,

Have tried that. Doesn't work. Traced it down to the mangling from objc 
back to python but couldn't make further progress with it.

Yves

> Has anyone tried creating a Python object and setting it as NSApp's 
> delegate, then seeing if you could grab notifications??

Re: [Pyobjc-dev] Altered classes

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

Basically, pyobjc mangles the ObjC selector names by substituting _ for 
each : (because : is reserved in python).

The second problem sounds more like an Appkit initialization problem-- 
did you have a look at Steve's AppKit example?   Make sure something 
like that works first, then try loading the NIB.  If the NIB loading is 
still broken, then we have an additional initialization phase at the 
AppKit level we haven't taken care of yet.

As well, there will be a certain line beyond which we really, really, 
really need to have the Main Event Loop running to do anything from 
Python to the Appkit...

Has anyone tried creating a Python object and setting it as NSApp's 
delegate, then seeing if you could grab notifications??

b.bum


On Friday, May 11, 2001, at 12:26 PM, Deirdre Saoirse Moen wrote:

>> Deirdre,
>>
>> 	Quick question;  shouldn't "loadNibNamed_owner" be 
>> "loadNibNamed_owner_" in this context?
>
> I must confess - I don't understand the distinction and I could have 
> sworn that I'd tried it both ways, but it DOES work. ::sigh:: Meaning 
> that it doesn't give an error, not necessarily that it does what it's 
> supposed to.
>
> I *used* to be awake when I was coding at 2 a.m., but I must be getting 
> old. :)
>
> I *am* getting an error, upon subsequent launches, of:
> kCGSErrorNoneAvailable : CGSOrderFrontConditionally: Process not found
>
> ...and the Window that was defined in code is inactive (it shows, but 
> doesn't accept clicks or anything). Meaning I'm going to have to log 
> out or something to clean it up. Ugh.
>
> -- _Deirdre     Stash-o-Matic: http://weirdre.com      
> http://deirdre.net
> Macintosh Developer (seeking work): Will work for Cocoa
> "I love deadlines. I like the whooshing sound they make as they fly by."
>                                                          - Douglas Adams
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> http://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Altered classes

[Deirdre S. M. <de...@de...>]

>Deirdre,
>
>	Quick question;  shouldn't "loadNibNamed_owner" be 
>"loadNibNamed_owner_" in this context?

I must confess - I don't understand the distinction and I could have 
sworn that I'd tried it both ways, but it DOES work. ::sigh:: Meaning 
that it doesn't give an error, not necessarily that it does what it's 
supposed to.

I *used* to be awake when I was coding at 2 a.m., but I must be getting old. :)

I *am* getting an error, upon subsequent launches, of:
kCGSErrorNoneAvailable : CGSOrderFrontConditionally: Process not found

...and the Window that was defined in code is inactive (it shows, but 
doesn't accept clicks or anything). Meaning I'm going to have to log 
out or something to clean it up. Ugh.

-- 
_Deirdre     Stash-o-Matic: http://weirdre.com      http://deirdre.net
Macintosh Developer (seeking work): Will work for Cocoa
"I love deadlines. I like the whooshing sound they make as they fly by."
                                                          - Douglas Adams

Re: [Pyobjc-dev] Altered classes

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

Deirdre,

	Quick question;  shouldn't "loadNibNamed_owner" be 
"loadNibNamed_owner_" in this context?

	b.bum


On Friday, May 11, 2001, at 04:10 AM, Deirdre Saoirse Moen wrote:

> I'm not sure I'm going about the hack, slash and burn right, but it 
> sure seems that ObjC classes that are defined in one framework and 
> altered in another do not correctly have their methods updated.
>
> An example: In the Foundation framework, NSBundle is defined and, given 
> Steven's example, those known methods of NSBundle seem to work.
>
> In the AppKit framework, NSBundle is extended to add several methods, 
> which don't seem to work. An example:
>
>     Nib = rt.NSBundle.loadNibNamed_owner("MainMenu.nib", Doc)
>
> ...doesn't work, but...
>
>     foundationKit = rt.NSBundle.bundleWithPath_(
>         '/System/Library/Frameworks/Foundation.framework').load()
>
> ...does.
>
> Furthermore, I can't seem to get it to want to list all of NSBundle's 
> methods, so I'm not sure I'm asking for the right thing.
>
> Any help in reducing the pain of beating my head against the wall will 
> of course reduce the amount of codeine this process is consuming. :)
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> http://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Altered classes

[Deirdre S. M. <de...@de...>]

I'm not sure I'm going about the hack, slash and burn right, but it 
sure seems that ObjC classes that are defined in one framework and 
altered in another do not correctly have their methods updated.

An example: In the Foundation framework, NSBundle is defined and, 
given Steven's example, those known methods of NSBundle seem to work.

In the AppKit framework, NSBundle is extended to add several methods, 
which don't seem to work. An example:

     Nib = rt.NSBundle.loadNibNamed_owner("MainMenu.nib", Doc)

...doesn't work, but...

     foundationKit = rt.NSBundle.bundleWithPath_(
         '/System/Library/Frameworks/Foundation.framework').load()

...does.

Furthermore, I can't seem to get it to want to list all of NSBundle's 
methods, so I'm not sure I'm asking for the right thing.

Any help in reducing the pain of beating my head against the wall 
will of course reduce the amount of codeine this process is 
consuming. :) 

Re: [Pyobjc-dev] Confused on syntax

[Deirdre S. M. <de...@de...>]

At 2:42 PM -0400 4/27/01, Steven D. Majewski wrote:
>[2]
>  I haven't yet been able to load and reanimate an IB Nib file
>from Python. I think this is a much easier problem than [1]
>above. I'll try to post what I've tried and what didn't work
>in case anyone else wants to give it a try.

Steven, I never did see these concepts, can you post them? ::whimper:: :)
-- 
_Deirdre     Stash-o-Matic: http://weirdre.com      http://deirdre.net
Macintosh Developer (seeking work): Will work for Cocoa
"I love deadlines. I like the whooshing sound they make as they fly by."
                                                          - Douglas Adams

Re: [Pyobjc-dev] Confused on syntax

[Deirdre S. M. <de...@de...>]

>That won't work for the same reason you can't directly
>subclass Python lists or dictionaries. They are objects,
>but not classes. Look in you're Python lib for UserDict.py
>and UserList.py -- which are examples of class wrappers
>around a non-class object. You would need to do something
>similar for Cocoa classes -- which are not Python classes.


Yeah, figured that out from your prior email. Rats. So much for cheap 
and easy. :)

>  We're going to look for a general solution to this problem:
>Jim Fulton and Don Beaudry both (I think) did some work on
>"extension classes" and other ways around this problem in
>Python -- and I think Python is moving towards a more
>general solution eventually.
>  We might try fixing it without waiting for Python 2.X to
>fix the problem (looking at those previous attempts).
>  We might be able to add more introspection to the bridge
>to make it easier to automatically generate, or make a
>generic one-size-fits-all class wrapper.

It seems to me that somehow it could be done if one really compiled 
python with ObjC (this is intuition) and tweaked the process of 
building a bit. Failing that, the generic wrapper sounds like a good 
approach.


>  I haven't yet been able to load and reanimate an IB Nib file
>from Python. I think this is a much easier problem than [1]
>above. I'll try to post what I've tried and what didn't work
>in case anyone else wants to give it a try.


Please -- it's a dull afternoon. :)


-- 
--
_Deirdre     Stash-o-Matic: http://weirdre.com      http://deirdre.net
"I love deadlines. I like the whooshing sound they make as they fly by."
                                                          - Douglas Adams

Re: [Pyobjc-dev] A pathetic plea for understanding (MacOS X)

[Deirdre S. M. <de...@de...>]

>  > The catch: I have a lot of python experience, but not a lot mixing it
>>  with other languages. Even looking through the archives, it's not
>  > clear to me what is done and what might need to be done.


>The best thing for now is probably to look at and try the HelloWorld
>program I posted a while back, and look at the apple docs for the
>Cocoa classes used. If there's anything you don't understand about it,
>ask and I'll try to explain. ( I probably should do a version of the
>same program in objective C for comparison, and maybe annotate the
>example a bit more. )

So far, so good. I think I'm starting in a different direction than 
you did, which is fine.

Actually, I think I may take a stab at writing the ObjC version of 
the HelloWorld -- that would probably help a lot (I'm not working 
right now, and I want to get a job as a Mac developer again, and 
without strong OS X skills, my options in the valley are Somewhat 
Limited one might say -- so this really IS "Professional Development" 
time for me).

>  > To put it simply, I want to build Cocoa projects and code them in
>>  Python. I'm learning ObjC (I learned it a few years ago but not
>>  enough to get fully over the learning curve) and I don't know Java.
>
>Hehe! ;-)  That's sort of what I was hoping for when I got involved.
>
>The truth is that it's not really much of a shortcut right now --
>you have to be able to understand enough objective-c to read and
>understand the apple Foundation and AppKit docs.

Well, it helps that I understand class libraries and how they work 
generally, having worked with several (PowerPlant being the one I'm 
best at).

>One the bright side, if you already know C, you can .literally. learn
>objective-C in a day. ( Learning the whole class library is another
>matter! )  And I've been learning lots about the objc runtime by
>hacking on PyObjC. ( If you don't know C, I'm afraid that's not a
>very bright side! )

I've spent 13 years as a MacOS developer (mostly in C) and the last 3 
years mostly on Linux, but now that OS X is shipping, I've wanted to 
spend more time developing for it. So I should be OK.

>  > This means I'll want to subclass Cocoa classes in Python -- how close
>  > is this project to allowing me to do that? Is there some kind of
>>  guide for how I'd do it either in Jython OR PyObjC? (Ultimately, I'd
>>  like to try it both ways -- and I'd be more than happy to put up a
>>  page detailing what has to be done).
>
>You can't subclass Cocoa classes in Python -- objective C classes
>are Python objects but not Python classes.  This is the notorious
>class/object barrier in Python, and why you need wrapper classes
>around dicts and lists and can't directly subclass them.

Aha! Well, this probably dashes my immediate hopes for the currency 
converter project. I think I probably could do that in Jython without 
too much pain (worth a stab anyway).

My understanding of Python internals is limited, in part because I've 
never mixed it with other languages and never really needed to know 
about the issues of language mixing.

>  You could do the same thing: write a Python wrapper around an
>objective C class and subclass that. I'm not sure how I could write
>a universal wrapper for all objective-C classes without adding
>more introspection capabilities (which is something that's planned,
>but not built in -- it can be done with the Neo class inspector --
>I'll have to put up some updated instructions on how to get and use
>that from Python  -- you can grab the standalone app at:
><http://www.neodata-inc.com/Eng/Self_Introspector.html> )

I'd thought it would need wrappering, but was so encouraged to see 
some of the stuff you did in HelloWorld and didn't think of a 
possible downside. I'll claim fatigue: I was playing from 8 in the 
morning until 2 a.m. on various projects yesterday.

>I would have to say it's not ready for prime time yet.
>I don't think you could write a whole non-toy Cocoa app with
>Python at present. I haven't been able to get delegate objects
>working properly -- which, in the absence of direct subclassing
>is probably a requirement. I think I'm going to have to build
>an objc-runtime lib from Darwin sources with debugging info,
>because I haven't been able to locate the problem with gdb.
>
>I have high hopes for it eventually -- some Apple folks on
>other mainling lists have indicated an interest on their part
>in opening up ProjectBuilder/InterfaceBuilder to support other
>languages,  but I haven't yet figured out how to reanimate a
>IB Nib  file from Python yet.

In your other mail, you mentioned that you'd had a stab at it. I'd be 
willing to attempt to browbeat it.

And if Apple would ever call back about that position, I did apply to 
be on the ProjectBuilder team (they've called about other open 
positions, but not about one in that group). Bah. :)

http://private.apple.com/cgi-bin/t3.cgi/tafs/extShowDescription.taf?_req=1539189

>There's a lot of stuff I haven't explored fully yet: for example,
>you can load your own objective-C classes as easily as you can
>load the AppKit classes. (I've done this with the NeoData class
>inspector) and I can say there's a lot less "impedence difference"
>between Python and objective-C than between Python and C -- it
>makes mixed language programming much easier. I haven't explored
>the notion of doing most of a application framework in objective-C
>and scripting/customizing  it from Python, but this would
>probably work right now. ( Although getting the delegates working
>would make it better. )

Interesting. I was thinking Obj-C, due to its dynamic (smalltalkish) 
nature would make it a better fit.

>I would have to admit that right now, PyObjC is mostly for the
>adventurous hacker -- but I would sure like to get a few more
>adventurous souls to take a hack at it!

Well, I'll keep stabbing away and asking questions.


-- 
--
_Deirdre     Stash-o-Matic: http://weirdre.com      http://deirdre.net
"I love deadlines. I like the whooshing sound they make as they fly by."
                                                          - Douglas Adams

Re: [Pyobjc-dev] Confused on syntax

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

[ I know our mails have crossed, and I addressed some of this
  in the earlier, longer message, but to distill the problems
  down more concisely: ]


> class ConverterController(pyobjc.runtime.NSObject):

[1]
That won't work for the same reason you can't directly
subclass Python lists or dictionaries. They are objects,
but not classes. Look in you're Python lib for UserDict.py
and UserList.py -- which are examples of class wrappers
around a non-class object. You would need to do something
similar for Cocoa classes -- which are not Python classes.

 We're going to look for a general solution to this problem:
Jim Fulton and Don Beaudry both (I think) did some work on
"extension classes" and other ways around this problem in
Python -- and I think Python is moving towards a more
general solution eventually.
 We might try fixing it without waiting for Python 2.X to
fix the problem (looking at those previous attempts).
 We might be able to add more introspection to the bridge
to make it easier to automatically generate, or make a
generic one-size-fits-all class wrapper.


[2]
 I haven't yet been able to load and reanimate an IB Nib file
from Python. I think this is a much easier problem than [1]
above. I'll try to post what I've tried and what didn't work
in case anyone else wants to give it a try.

-- Steve Majewski

Re: [Pyobjc-dev] What did I do wrong?

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

What version of Python are you using ? One of the beta releases?
My patch was accepted into the 2.1 final, so that should work.

My copy of Python2.1/lib/distutils/unixccompiler.py  has a line:

    src_extensions = [".c",".C",".cc",".cxx",".cpp",".m"]

in the beta (and maybe the final candidate) releases, the ".m" is
missing.

-- Steve.

On Fri, 27 Apr 2001, Deirdre Saoirse Moen wrote:

> OK, I figured that out -- now I'm up to the problem Steve had last
> November with not having pyobjc import correctly. I finally just
> chickened out and grabbed his binaries so I could get something done.
>
>
> >% /usr/local/bin/python setup.py install
> >running install
> >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.0/distutils/core.py", line 157, in setup
> >     raise SystemExit, "error: " + str(msg)
> >SystemExit: error: unknown file type '.m' (from 'OC_PythonBundle.m')
>

Re: [Pyobjc-dev] A pathetic plea for understanding (MacOS X)

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

On Thu, 26 Apr 2001, Deirdre Saoirse Moen wrote:

> I heard about this project on the Jython list and, frankly, it seems
> a more straightforward way of handling the problem of making
> ProjectBuilder/InterfaceBuilder projects.
>
> The catch: I have a lot of python experience, but not a lot mixing it
> with other languages. Even looking through the archives, it's not
> clear to me what is done and what might need to be done.


The best thing for now is probably to look at and try the HelloWorld
program I posted a while back, and look at the apple docs for the
Cocoa classes used. If there's anything you don't understand about it,
ask and I'll try to explain. ( I probably should do a version of the
same program in objective C for comparison, and maybe annotate the
example a bit more. )

> To put it simply, I want to build Cocoa projects and code them in
> Python. I'm learning ObjC (I learned it a few years ago but not
> enough to get fully over the learning curve) and I don't know Java.

Hehe! ;-)  That's sort of what I was hoping for when I got involved.

The truth is that it's not really much of a shortcut right now --
you have to be able to understand enough objective-c to read and
understand the apple Foundation and AppKit docs.

One the bright side, if you already know C, you can .literally. learn
objective-C in a day. ( Learning the whole class library is another
matter! )  And I've been learning lots about the objc runtime by
hacking on PyObjC. ( If you don't know C, I'm afraid that's not a
very bright side! )


> This means I'll want to subclass Cocoa classes in Python -- how close
> is this project to allowing me to do that? Is there some kind of
> guide for how I'd do it either in Jython OR PyObjC? (Ultimately, I'd
> like to try it both ways -- and I'd be more than happy to put up a
> page detailing what has to be done).

You can't subclass Cocoa classes in Python -- objective C classes
are Python objects but not Python classes.  This is the notorious
class/object barrier in Python, and why you need wrapper classes
around dicts and lists and can't directly subclass them.
 You could do the same thing: write a Python wrapper around an
objective C class and subclass that. I'm not sure how I could write
a universal wrapper for all objective-C classes without adding
more introspection capabilities (which is something that's planned,
but not built in -- it can be done with the Neo class inspector --
I'll have to put up some updated instructions on how to get and use
that from Python  -- you can grab the standalone app at:
<http://www.neodata-inc.com/Eng/Self_Introspector.html> )

I would have to say it's not ready for prime time yet.
I don't think you could write a whole non-toy Cocoa app with
Python at present. I haven't been able to get delegate objects
working properly -- which, in the absence of direct subclassing
is probably a requirement. I think I'm going to have to build
an objc-runtime lib from Darwin sources with debugging info,
because I haven't been able to locate the problem with gdb.

I have high hopes for it eventually -- some Apple folks on
other mainling lists have indicated an interest on their part
in opening up ProjectBuilder/InterfaceBuilder to support other
languages,  but I haven't yet figured out how to reanimate a
IB Nib  file from Python yet.

There's a lot of stuff I haven't explored fully yet: for example,
you can load your own objective-C classes as easily as you can
load the AppKit classes. (I've done this with the NeoData class
inspector) and I can say there's a lot less "impedence difference"
between Python and objective-C than between Python and C -- it
makes mixed language programming much easier. I haven't explored
the notion of doing most of a application framework in objective-C
and scripting/customizing  it from Python, but this would
probably work right now. ( Although getting the delegates working
would make it better. )

I would have to admit that right now, PyObjC is mostly for the
adventurous hacker -- but I would sure like to get a few more
adventurous souls to take a hack at it!


-- Steve Majewski