pyobjc-dev

Re: [Pyobjc-dev] PyObjC & Fink

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

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

W.r.t. the memory leak... If you start the TableModel example and click 
inside the tableview the process will grow. It seems to grow unbounded. 
The CurrencyConverter doesn't have this problem.

Sadly enough I've encountered another problem while debugging this: If 
I try to use MallocDebug my program crashes as soon as the code tries 
to call a method in a PyObjC created class. It crashes somewhere in the 
middle of the objective-C runtime, which is compiled without debug 
information :-(. I've managed to create a standalone Objective-C 
program that features the same problem. This code is based on an 
example in the Objective-C reference from Apple. Any ideas on what 
might be wrong?

BTW. The easiest way to reproduce the problems with the attached code 
is to build it, run 'gdb class-test' and then the following commands 
from inside gdb:
	set start-with-shell 0
	set env DYLD_INSERT_LIBRARIES /usr/lib/libMallocDebug.A.dylib
	set env DYLD_FORCE_FLAT_NAMESPACE 1
	run


Ronald

Re: [Pyobjc-dev] PyObjC & Fink

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

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

[Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds

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

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

Re: [Pyobjc-dev] PyObjC & Fink

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

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

Re: [Pyobjc-dev] PyObjC & Fink

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

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