PyObjC

On Monday, September 23, 2002, at 08:02 AM, Ronald Oussoren wrote:
> I just noticed that I sent my reply just to Bill:
>
> On Monday, Sep 23, 2002, at 08:40 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>
>> I wouldn't mind pushing out a new snapshot. IMHO it should be marked 
>> experimental, mostly because of a memory leak whose source I've as of 
>> yet have been unable to locate.
>>
>> BTW. Does Fink install a Python framework? PyObjC probably won't be 
>> very usefull unless Python is installed as a framework. But then 
>> again, maybe a normal Unix install works just as well, as long as GUI 
>> scripts are packaged inside '.app' directories.

Fink installs the "normal" python build.  However, pyobjc is 
*extremely* useful without the framework.  Namely, it can be used to do 
very powerful command line scripting -- automating various tasks on the 
system.  There are a number of powerful ObjC APIs that have nothing to 
do with the GUI -- Address Book and NetInfo, for example.

In any case, even for building apps, the non-framework build is still 
very useful.  In particular, embedding the interpreter works quite 
nicely for adding scripting to "traditional" Cocoa apps.

I'll have a look at the memory looks as time permits...

BTW: The fix you [Ronald] mentioned for compiling pyobjc w/Python 2.2 
worked except that it seems the precompiler has gone into an infinite 
loop while compiling-- it has been using 70% of the CPU for over 10 
minutes!

gcc -DNDEBUG -O3 -Wall -Wstrict-prototypes -I/sw/include/python2.2 -c 
Modules/objc/register.m -o 
build/temp.darwin-6.1-PowerMacintosh-2.2/register.o -g -O0 
-DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX

Maybe I'll let it run -- that is one BIG file...   maybe I need to 
regenerate it for 2.2 vs. 2.3??

b.bum

On Monday, Sep 23, 2002, at 16:52 Europe/Amsterdam, Bill Bumgarner 
wrote:
> I'll whip up a Fink package that install python 2.3 alpha and work 
> with that... not a problem and likely easier than trying to backport.
You might want to do a 'cvs update' of PyObjC before you start hacking. 
I've just checked in a number of changes, including a fix for the 
memory leak I mentioned before (I've stared at the buggy part of the 
code at least 10 times and somehow missed the (pretty silly) bug every 
time :-().

I also included yet another example application that I wrote for a 
PyObjC demo at a meeting of Dutch Mac programmers: iClass; a class 
browser for Cocoa. In just 250 lines of code...

>
> Though, I will try the fix you mention as it would be nice to have the 
> pyobjc module work against the current production version of Python, 
> if at all possible.
Let me know about the results. I'm curious if this is possible at al.

Ronald

>
> BTW: The fix you [Ronald] mentioned for compiling pyobjc w/Python 2.2 
> worked except that it seems the precompiler has gone into an infinite 
> loop while compiling-- it has been using 70% of the CPU for over 10 
> minutes!
>
> gcc -DNDEBUG -O3 -Wall -Wstrict-prototypes -I/sw/include/python2.2 -c 
> Modules/objc/register.m -o 
> build/temp.darwin-6.1-PowerMacintosh-2.2/register.o -g -O0 
> -DOBJC_PARANOIA_MODE -DPyOBJC_UNIQUE_PROXY -DMACOSX
>
> Maybe I'll let it run -- that is one BIG file...   maybe I need to 
> regenerate it for 2.2 vs. 2.3??
>
It is not the precompiler, it is the compiler itself. The source file 
is way too big, I've replaced it with a smaller version in my last 
checkin. The file contains a lot of functions that can be used in the 
method table of an Objective-C class and the forward the call to python.

I hope to find a better way to do this in the future, maybe using 
libffi.

Ronald

I committed changes that allow pyobjc to build with non-framework 
installs and to build against Python 2.2.1 (the latest version 
available via Fink).

It works fine;  the most intrusive change was the presence of PyBool -- 
a new type as of 2.3.   I changed PyBool_Check to a non-operation and 
changed PyBool_FromLong() to be PyInt_FromLong().   This should be 
relatively equivalent at runtime.

The ObjC interface seems to work fine, but the Cocoa based stuff is 
broken -- I'm not sure if this is related to 2.2, to non-Framework 
builds, or just the state of the current development.

In any case -- Ronald, I must extend a HUGE note of gratitude for all 
of your work on this.  It is excellent!!!

Also -- I believe that we can make standalone scripts work fine even if 
they launch UI sessions.  I built a little app called PythonLauncher 
that can be used to springboard the launching of a script that uses the 
UI.  It provides a full blown "bundle" environment, as required by the 
X environment, but allows multiple copies to be launched.  I'll have to 
hack on it....

Comment:   Foundation should not really be a part of Cocoa.  I.e. I 
should be able to do "from Foundation import NSString" -- not "from 
Cocoa.Foundation import NSString".   There are platforms upon which 
Foundation exists, but Cocoa might not -- this is especially true as 
support for GnuStep is reintroduced (or, likely, rewritten).

b.bum