pyobjc-dev

[Pyobjc-dev] PyObjC & Fink

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

Given that Ronald's work on the module basically supersedes all other 
trees, I believe that we should push out a new snapshot of pyobjc.

In particular, I would like to push out a new version such that a 
source tarball is available somewhere such that a Fink package could be 
built to automatically install the pyobjc module.

I can take care of the Fink package side of things, but need consensus 
on what should be released.

Ronald?

b.bum

[Pyobjc-dev] Snapshots

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

On Monday, Sep 23, 2002, at 00:00 Europe/Amsterdam, Bill Bumgarner 
wrote:
>
> Given that Ronald's work on the module basically supersedes all other 
> trees, I believe that we should push out a new snapshot of pyobjc.

I'm happy enough with the current state of PyObjC create a new snapshot 
and to move the code back to CVS trunk.

I can do the CVS work, but I probably do not have enough privileges to 
actually add an archive to the downloadable files on sourceforge.


On Monday, Sep 23, 2002, at 18:06 Europe/Amsterdam, Bill Bumgarner 
wrote:
> 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).

I agree. The Cocoa prefix might also be confusing for Objective-C 
programmers that want to try out python.

I suppose we should change this before creating a new snapshot. 
Opinions anyone?

Ronald

Re: [Pyobjc-dev] Snapshots

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

If you can do the CVS stuff, I can take care of pushing out a 
downloadable tarball.   From there, it will be easy to add a Fink 
package.   I will also revisit the necessary steps to make a build that 
works with the python shipped with OS X -- it works, I just can't 
remember how I did it. :-)

> I agree. The Cocoa prefix might also be confusing for Objective-C 
> programmers that want to try out python.
>
> I suppose we should change this before creating a new snapshot. 
> Opinions anyone?

Definitely a change to be made before a new snapshot is delivered.  
This will be the first major snapshot that encourages wide spread use 
in-- what?-- 4 or so years.   As such, whatever is pushed out the door 
will become the "standard" for a while.

I believe I also have an alternative way to start up the python 
interpreter that will work with the OS X distributed python.  This will 
have the added advantage of making it possible to build and distribute 
a pure Python Cocoa app that is reasonably sized -- i.e. does not 
contain the entire python distribution in the app wrapper-- and does 
not require anything on the system beyond the BSD package.

As this is just an example, there is no sense in delaying the rest of 
the release for this particular feature.

b.bum

On Monday, October 7, 2002, at 08:12 AM, Ronald Oussoren wrote:

> On Monday, Sep 23, 2002, at 00:00 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>>
>> Given that Ronald's work on the module basically supersedes all other 
>> trees, I believe that we should push out a new snapshot of pyobjc.
>
> I'm happy enough with the current state of PyObjC create a new 
> snapshot and to move the code back to CVS trunk.
>
> I can do the CVS work, but I probably do not have enough privileges to 
> actually add an archive to the downloadable files on sourceforge.
>
>
> On Monday, Sep 23, 2002, at 18:06 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> 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).
>
> I agree. The Cocoa prefix might also be confusing for Objective-C 
> programmers that want to try out python.
>
> I suppose we should change this before creating a new snapshot. 
> Opinions anyone?
>
> Ronald

Re: [Pyobjc-dev] Snapshots

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

On Monday, Oct 7, 2002, at 15:45 Europe/Amsterdam, Bill Bumgarner wrote:

> If you can do the CVS stuff, I can take care of pushing out a 
> downloadable tarball.   From there, it will be easy to add a Fink 
> package.   I will also revisit the necessary steps to make a build 
> that works with the python shipped with OS X -- it works, I just can't 
> remember how I did it. :-)
I'll copy the branch code to the HEAD sometime this week. I'll change 
'Cocoa.Foundation' and 'Cocoa.AppKit' to 'Foundation' and 'AppKit' at 
the same
time.

>> I agree. The Cocoa prefix might also be confusing for Objective-C 
>> programmers that want to try out python.
>>
>> I suppose we should change this before creating a new snapshot. 
>> Opinions anyone?
>
> Definitely a change to be made before a new snapshot is delivered.  
> This will be the first major snapshot that encourages wide spread use 
> in-- what?-- 4 or so years.   As such, whatever is pushed out the door 
> will become the "standard" for a while.
Let's hope not for another 4 year ;-)

> I believe I also have an alternative way to start up the python 
> interpreter that will work with the OS X distributed python.  This 
> will have the added advantage of making it possible to build and 
> distribute a pure Python Cocoa app that is reasonably sized -- i.e. 
> does not contain the entire python distribution in the app wrapper-- 
> and does not require anything on the system beyond the BSD package.
>
> As this is just an example, there is no sense in delaying the rest of 
> the release for this particular feature.

I'm working on some (minor) new features and code cleanup, but those 
can wait until after the release.

Ronald

Re: [Pyobjc-dev] Snapshots

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

On Monday, Oct 7, 2002, at 17:11 Europe/Amsterdam, Ronald Oussoren 
wrote:

> On Monday, Oct 7, 2002, at 15:45 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>
>> If you can do the CVS stuff, I can take care of pushing out a 
>> downloadable tarball.   From there, it will be easy to add a Fink 
>> package.   I will also revisit the necessary steps to make a build 
>> that works with the python shipped with OS X -- it works, I just 
>> can't remember how I did it. :-)
> I'll copy the branch code to the HEAD sometime this week. I'll change 
> 'Cocoa.Foundation' and 'Cocoa.AppKit' to 'Foundation' and 'AppKit' at 
> the same
> time.

The 'subclassing-branch' is now officially closed, the code is now 
available from the HEAD.

I've also added a workaround to setup.py that allows you to build 
pyobjc using Apple's python in Jaguar. However, this doesn't result in 
a fully workable module: the addressbook.py example causes a coredump 
:-(, but some of the other examples do work correctly.

Ronald

Re: [Pyobjc-dev] Snapshots

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

I'm able to cause a bus error from just the objc module.  However, the 
actual ObjC interface side of things seems to work fine -- it seems to 
be some kind of a pure Python related problem....

I.e. this works:

 >>> a = objc.runtime.NSMutableArray.array()
 >>> a.addObject_("foo")
 >>> a.addObject_(1)
 >>> a
<NSCFArray objective-c instance 0x70fe70>
 >>> a.description()
'(foo, 1)'

But a basic help(objc) fails mightily (but works on the fink build 
version of pyobjc):

[bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% gdb /usr/bin/python
GNU gdb 5.1-20020408 (Apple version gdb-231) (Tue Aug 13 21:37:39 GMT 
2002)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and 
you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for 
details.
This GDB was configured as "powerpc-apple-macos10".
Reading symbols for shared libraries .... done
(gdb) r
Starting program: /usr/bin/python
[Switching to process 11215 thread 0xb03]
Reading symbols for shared libraries ............. done
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
Reading symbols for shared libraries ...... done
 >>> import objc
Reading symbols for shared libraries .......................... done
Reading symbols for shared libraries . done
 >>> help(objc)

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x000707e4 in PyCallIter_New ()
(gdb) bt
#0  0x000707e4 in PyCallIter_New ()
#1  0x000472f4 in PyTuple_GetSlice ()
#2  0x00070af4 in PyCallIter_New ()
#3  0x00070fd0 in PyCallIter_New ()
#4  0x0007128c in PyCallIter_New ()
#5  0x00071c18 in _PyObject_GC_Malloc ()
#6  0x00071c8c in _PyObject_GC_NewVar ()
....

b.bum

On Wednesday, October 9, 2002, at 04:10 PM, Ronald Oussoren wrote:

>
> I've also added a workaround to setup.py that allows you to build 
> pyobjc using Apple's python in Jaguar. However, this doesn't result in 
> a fully workable module: the addressbook.py example causes a coredump 
> :-(, but some of the other examples do work correctly.

Re: [Pyobjc-dev] Snapshots

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

On Thursday, Oct 10, 2002, at 21:26 Europe/Amsterdam, Bill Bumgarner 
wrote:

> I'm able to cause a bus error from just the objc module.  However, the 
> actual ObjC interface side of things seems to work fine -- it seems to 
> be some kind of a pure Python related problem....

I've done some experiments and it seems to be related to the garbage 
collector (the 'gc' module). If I call 'gc.disable()' before using the 
objc module python doesn't crash.

The current HEAD contains a workaround in Modules/objc/__init__.py that 
calls gc.disable() when the python version is 2.2.0. This is a bit of a 
hack, but at least allows you to use the Apple version of python.

BTW. This may be a bug in PyObjC but it could also be a bug in Python 
2.2.0 that is triggered by our code.

Ronald

Re: [Pyobjc-dev] Snapshots

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

Cool -- I was worried that disabling the garbage collector would cause 
the python interpreter to leak objects like a sieve.   Fortunately, the 
gc module is optional and, as such, it shouldn't cause a significant 
problem to disable it.

I'm reworking the PyCocoa PBX project to support Apple's python.

thanks!

b.bum

On Friday, October 11, 2002, at 03:19 AM, Ronald Oussoren wrote:
> On Thursday, Oct 10, 2002, at 21:26 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>
>> I'm able to cause a bus error from just the objc module.  However, 
>> the actual ObjC interface side of things seems to work fine -- it 
>> seems to be some kind of a pure Python related problem....
>
> I've done some experiments and it seems to be related to the garbage 
> collector (the 'gc' module). If I call 'gc.disable()' before using the 
> objc module python doesn't crash.
>
> The current HEAD contains a workaround in Modules/objc/__init__.py 
> that calls gc.disable() when the python version is 2.2.0. This is a 
> bit of a hack, but at least allows you to use the Apple version of 
> python.
>
> BTW. This may be a bug in PyObjC but it could also be a bug in Python 
> 2.2.0 that is triggered by our code.

[Pyobjc-dev] Cocoa vs. AppKit

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

Ronald,

     Should the AppKit module be called Cocoa instead?

     The Cocoa framework is basically nothing more than a header that 
imports the AppKit and a dylib that links against the AppKit dylib, but 
all of Apple's examples link against the Cocoa framework and simply 
include the AppKit framework for reference.

     At the moment, it is nothing more than a choice of naming, but I 
don't know if that will always be the case-- some day, Apple may stick 
actual Cocoa functionality into the Cocoa framework. :-)

     (I'm actually quite curious why this distinction continues to exist 
in the OS at all... then again, the NS 3.3 based appkit still shipped 
with OS X up to and, I believe, including the public beta.)

     b.bum