pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Project builder project template...

[Jiva D. <ji...@de...>]

I have taken your sample project and put it into a template suitable 
for putting into the rest of the project builder templates in 
/Developer/ProjectBuilder Extras

You can download this template at:

http://www.devoesquared.com/pyobjc_template.tar.gz

Feel free to add this to cvs if you guys find it useful.

[Pyobjc-dev] This is so cool!

[Jiva D. <ji...@de...>]

So we can now rapidly prototype in python, and when we find bottlenecks 
needing to be faster, we recode that code in Obj-C.  This almost seems 
too good to be true! :)

Re: [Pyobjc-dev] Standalone Cocoa apps WORK!!!!

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

Not needed at all -- shouldn't affect the build other than possibly 
dumping a warning or two...

b.bum

On Friday, October 11, 2002, at 05:59 PM, Jiva DeVoe wrote:

> Also, there are some references to /sw/lib/python2.2 and 
> /sw/include/python which I presume is for the fink version of python.  
> Those aren't needed are they?

Re: [Pyobjc-dev] Standalone Cocoa apps WORK!!!!

[Jiva D. <ji...@de...>]

Also, there are some references to /sw/lib/python2.2 and 
/sw/include/python which I presume is for the fink version of python.  
Those aren't needed are they?
On Friday, October 11, 2002, at 02:41  PM, Bill Bumgarner wrote:

> On Friday, October 11, 2002, at 05:33 PM, Jiva DeVoe wrote:
>> Bill, this is awesome.  Is this packaged up as part of the distro 
>> yet?  I want some!
>>
>> :)
>
> Everything has been committed and I just released Web Services Tool as 
> a standalone app-on-a-disk image via my weblog.
>
> http://radio.weblogs.com/0100490/
>
> Have fun!
>
> b.bum
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Standalone Cocoa apps WORK!!!!

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

If you do another CVS update, you'll notice that it is unchecked.... 
:-)  It is only necessary if you want to use the original, embedded 
interpreter method of build PyCocoa apps -- see the README at the head 
of the two main files for more information.

The whole thing could really use some general cleanup...

b.bum

On Friday, October 11, 2002, at 05:54 PM, Jiva DeVoe wrote:

> Bill, I notice the project builder project for the web services tool 
> seems to have libpython2.2.a as part of it's "other frameworks" group. 
>  Is this actually required?

Re: [Pyobjc-dev] Standalone Cocoa apps WORK!!!!

[Jiva D. <ji...@de...>]

Bill, I notice the project builder project for the web services tool 
seems to have libpython2.2.a as part of it's "other frameworks" group.  
Is this actually required?


On Friday, October 11, 2002, at 02:41  PM, Bill Bumgarner wrote:

> On Friday, October 11, 2002, at 05:33 PM, Jiva DeVoe wrote:
>> Bill, this is awesome.  Is this packaged up as part of the distro 
>> yet?  I want some!
>>
>> :)
>
> Everything has been committed and I just released Web Services Tool as 
> a standalone app-on-a-disk image via my weblog.
>
> http://radio.weblogs.com/0100490/
>
> Have fun!
>
> b.bum
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Standalone Cocoa apps WORK!!!!

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

On Friday, October 11, 2002, at 05:33 PM, Jiva DeVoe wrote:
> Bill, this is awesome.  Is this packaged up as part of the distro yet? 
>  I want some!
>
> :)

Everything has been committed and I just released Web Services Tool as 
a standalone app-on-a-disk image via my weblog.

http://radio.weblogs.com/0100490/

Have fun!

b.bum

Re: [Pyobjc-dev] Standalone Cocoa apps WORK!!!!

[Jiva D. <ji...@de...>]

Bill, this is awesome.  Is this packaged up as part of the distro yet?  
I want some!

:)
On Friday, October 11, 2002, at 11:51  AM, Bill Bumgarner wrote:

> I fixed the problem with _AppKit -- it was a symbol collision.   See 
> the NEWS file for details on what changed -- in short, I added the 
> 'static' keyword to a couple of the symbols generated by the 
> enum/strconst generator script.  By using 'static', the symbols are 
> not externally advertised and, hence, no symbol collision occurs.
>
> The Web Services Tool can now be built as a standalone 
> double-clickable app that will run any stock OS X 10.2 box.
>
> To do so, you simply need to add a "Copy Files" build phase and copy 
> /usr/lib/python2.2/site-packages/{AppKit,Foundation,objc} into 
> Resources in a subdirectory named 'pyobjc'.
>
> The Main.py simply does...
>
> import sys
> import os.path
> sys.path.insert(0, os.path.join(sys.path[0], "pyobjc"))
>
> import objc
> import Foundation
> import AppKit
>
> import WSTApplicationDelegateClass
> import WSTConnectionWindowControllerClass
>
> sys.exit( AppKit.NSApplicationMain(sys.argv) )
>
> ---
>
> I can't even begin to tell you how happy this makes me -- finally, I 
> can build/release pure Python based Cocoa applications without the 
> user community having to dive through major hoops to install the > app!!!
>
> b.bum
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] Standalone Cocoa apps WORK!!!!

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

I fixed the problem with _AppKit -- it was a symbol collision.   See 
the NEWS file for details on what changed -- in short, I added the 
'static' keyword to a couple of the symbols generated by the 
enum/strconst generator script.  By using 'static', the symbols are not 
externally advertised and, hence, no symbol collision occurs.

The Web Services Tool can now be built as a standalone double-clickable 
app that will run any stock OS X 10.2 box.

To do so, you simply need to add a "Copy Files" build phase and copy 
/usr/lib/python2.2/site-packages/{AppKit,Foundation,objc} into 
Resources in a subdirectory named 'pyobjc'.

The Main.py simply does...

import sys
import os.path
sys.path.insert(0, os.path.join(sys.path[0], "pyobjc"))

import objc
import Foundation
import AppKit

import WSTApplicationDelegateClass
import WSTConnectionWindowControllerClass

sys.exit( AppKit.NSApplicationMain(sys.argv) )

---

I can't even begin to tell you how happy this makes me -- finally, I 
can build/release pure Python based Cocoa applications without the user 
community having to dive through major hoops to install the app!!!

b.bum

[Pyobjc-dev] Whoops! Looks like AppKit is broken.

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

I was testing some stuff and realized I still had some of the previous 
build of pyobjc in site-packages;  stuff prior to the recent namespace 
change.

In removing that, Web Services Tool now no longer works.  Further 
analysis reveals that:

     - 'import AppKit' before 'import Foundation' breaks with a "could 
not link module" error.  No big deal, really.

     - NSApplicationMain() is not defined when the AppKit is imported.   
It appears that AppKit's __init__.py catches ImportErrors and passes -- 
attempting to do the import by hand produces a "could not link module" 
import error.

I'm not sure exactly what is broken, but something is (it might be me).

b.bum

Re: [Pyobjc-dev] Web Services Tool example updated

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

The executable that results from building Web Services Tool could be 
used in any application to bootstrap into Python.  In reality, you 
could:

- create a new Cocoa project of whatever variety

- remove the main.m

- add a "copy files phase"

- copy the executable from WST into your app wrapper

- change the NSExecutable attribute to "Web Services Tool"

And it'll just work.

We should consider shipping a premade executable with pyobjc?   That 
way, as the executable is upgraded, developers can just rebuild their 
projects as opposed to having to track some random source file?   Not 
really a huge advantage here, I guess.

b.bum

On Friday, October 11, 2002, at 10:53 AM, Bill Bumgarner wrote:
> The Web Services Tool has been updated to work with the Apple supplied 
> Python.   The change was quite easy -- it simply sets up the command 
> line arguments as one normally would when using /usr/bin/python and 
> calls execve() to transfer control to the python interpreter.
>

....

[Pyobjc-dev] Web Services Tool example updated

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

The Web Services Tool has been updated to work with the Apple supplied 
Python.   The change was quite easy -- it simply sets up the command 
line arguments as one normally would when using /usr/bin/python and 
calls execve() to transfer control to the python interpreter.

Unfortunately, due to the way python starts the interpreter, the path 
to the python executable is required (i.e. the #! at the head of the 
script is ignored.

Fortunately, it really doesn't matter and I could recycle the code from 
the original main file.

If you want to mix compiled ObjC with Python, you'll need to create a 
bundle target in your app project.  Then, create a copy files build 
phase that copies the bundle product into your app wrapper.  Finally, 
load the bundle from Main.py.

b.bum

[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

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.

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

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 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] Functions in the Objective-C method table

[Jack J. <Jac...@or...>]

On dinsdag, oktober 8, 2002, at 03:06 , Ronald Oussoren wrote:
>>> The major problem I see with the current version of PyObjC is 
>>> the (large) list of functions that are used in the method 
>>> dispatch tables in Objective-C classes (the file 
>>> 'Modules/objc/register.m'). Using a static list makes the 
>>> compile-time of PyObjC too long and makes it necessary to add 
>>> C module when you want to override methods whose signature is 
>>> not in the table.
>>
>> Is it possible to find out how the ObjC-Java bridge handles 
>> this? It must have the same problems, if I'm not mistaken, and 
>> it'll also have the super method call problem.
>
> I'll take a look at the code generated by bridget, but I 
> wouldn't be surprised if they don't have the same problem 
> because they generate static wrappers.

Uhm... You've lost me here, why would static wrappers make a 
difference? Or are you suggesting that for every method [x] they 
generate both a [object x] and [super x] wrapper?
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -

Re: [Pyobjc-dev] Functions in the Objective-C method table

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

In the context of going from Obj-C -> Java, there was both the formal 
bridget mechanism, but the ObjC->Java bridge also allowed for arbitrary 
messaging into Java for methods that had not been explicitly bridged in 
a jobs file.   This was done dynamically and, as such, there must be a 
mechanism available that avoids the use of a mechanism like the whole 
"register.m" thing.

In general, the presence of register.m is fairly inoffensive in 
everything but the compilation time -- it is a whole lot faster to do 
the dispatch via the stuff in register.m than it is to do something 
dynamic/on-the-fly.   Why not add the compiled result of register.m to 
the CVS repository as register.o (or as a library) that everything can 
link against -- the only time it would be recompiled is when the 
register.m file is regenerated.

In any case, the Java Bridge-- as of WebObjects 4.5-- works by creating 
an ObjC class for each bridged Java class.  This includes creating both 
a class struct and a meta class struct to describe the Java class in 
terms of ObjC.

The bridged classes do not bridge the instance variables, but do bridge 
each instance and class/static method.

The method signatures were generated on the fly based on the Java 
class's method signatures.   The bridged classes would also 
conditionally have a series of standard methods added to them;  i.e. 
-copy, -retain, -description, etc... depending on the nature of the 
class being bridged (does it inherit from ObjC or Java, etc).

An implementaton of -forward:: or -forwardInvocation: (because it had 
to work with both) was provided to do the forwarding of method 
invocations from ObjC into Java.  This was done by effectively wrapping 
the instance of the Java object in a proxy class (NSJavaObject) that 
contained the appropriate forwarding mechanism.

The forwarding mechanism basically ripped apart the stack by hand, 
converted the arguments to the corresponding Java types based on their 
ObjC signatures, invoked the Java method, then converted the return 
values, as needed.

I could dig some more and see if I can find my notes that may provide 
more detail -- the above was done from memory.   I have some deep scars 
from having to debug some truly painful interaction between ObjC and 
Java under WO 3.5 - 4.5.   There were some nasty bugs that could 
potentially cause a deadlock in the bridge...

b.bum

On Tuesday, October 8, 2002, at 09:06 AM, Ronald Oussoren wrote:

>
> On Tuesday, Oct 8, 2002, at 13:58 Europe/Amsterdam, Jack Jansen wrote:
>> On Wednesday, Sep 25, 2002, at 19:23 Europe/Amsterdam, Ronald 
>> Oussoren wrote:
>>
>>> The major problem I see with the current version of PyObjC is the 
>>> (large) list of functions that are used in the method dispatch 
>>> tables in Objective-C classes (the file 'Modules/objc/register.m'). 
>>> Using a static list makes the compile-time of PyObjC too long and 
>>> makes it necessary to add C module when you want to override methods 
>>> whose signature is not in the table.
>>
>> Is it possible to find out how the ObjC-Java bridge handles this? It 
>> must have the same problems, if I'm not mistaken, and it'll also have 
>> the super method call problem.
>
> I'll take a look at the code generated by bridget, but I wouldn't be 
> surprised if they don't have the same problem because they generate 
> static wrappers.
>
> Ronald
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
b.bum
In cyberspace, no one can hear you laugh.

Re: [Pyobjc-dev] Functions in the Objective-C method table

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

On Tuesday, Oct 8, 2002, at 13:58 Europe/Amsterdam, Jack Jansen wrote:
> On Wednesday, Sep 25, 2002, at 19:23 Europe/Amsterdam, Ronald Oussoren 
> wrote:
>
>> The major problem I see with the current version of PyObjC is the 
>> (large) list of functions that are used in the method dispatch tables 
>> in Objective-C classes (the file 'Modules/objc/register.m'). Using a 
>> static list makes the compile-time of PyObjC too long and makes it 
>> necessary to add C module when you want to override methods whose 
>> signature is not in the table.
>
> Is it possible to find out how the ObjC-Java bridge handles this? It 
> must have the same problems, if I'm not mistaken, and it'll also have 
> the super method call problem.

I'll take a look at the code generated by bridget, but I wouldn't be 
surprised if they don't have the same problem because they generate 
static wrappers.

Ronald

Re: [Pyobjc-dev] Functions in the Objective-C method table

[Jack J. <Jac...@cw...>]

On Wednesday, Sep 25, 2002, at 19:23 Europe/Amsterdam, Ronald Oussoren 
wrote:

> The major problem I see with the current version of PyObjC is the 
> (large) list of functions that are used in the method dispatch tables 
> in Objective-C classes (the file 'Modules/objc/register.m'). Using a 
> static list makes the compile-time of PyObjC too long and makes it 
> necessary to add C module when you want to override methods whose 
> signature is not in the table.

Is it possible to find out how the ObjC-Java bridge handles this? It 
must have the same problems, if I'm not mistaken, and it'll also have 
the super method call problem.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- Emma 
Goldman -

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

[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

[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

[Pyobjc-dev] Re: problems with WebServicesTool

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

Oh, shoot.  That's because your pyobjc module doesn't have the 
NSProgressIndicatorSpinningStyle committed into the repository.

See Modules/Cocoa/scripts/ in the pyobjc module -- specifically, you 
need to regenerate the enumerated types file and recompile pyobjc.

Better yet -- just update your pyobjc workarea and rebuild the module 
as I just committed the two files that needed changes.   Note that not 
all of the jaguar functions will appear quite yet.

(Ronald et. al. on pyobjc -- this commit breaks the build on 10.1 and 
prior.   If that is a problem, back it out and we can "fix it right" in 
the future.)

Aaron:  Sorry about the inconvenience!

b.bum


On Monday, September 30, 2002, at 06:05 PM, Aaron Swartz wrote:

> Hi there,
>
> Thanks so much for introducing me to the new pyobjc -- if I can get 
> this to work I'm going to explode with joy (not Joy, tho...).
>
> When I try to run your app, it dies with a NameError on 
> NSProgressIndicatorSpinningStyle. I'm running Jaguar and I can see 
> NSProgressIndicatorSpinningStyle in the Header files for 
> AppKit.framework, but it doesn't appear when I import Cocoa.AppKit in 
> Python.
>
> Any ideas? Thanks a ton,
> -- 
> Aaron Swartz [http://www.aaronsw.com] "Curb your consumption," he said.
>
>
b.bum
No Chunks...
	... No Foul!