pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Build of pyobjc and pyobjc-nib failures

[Zachery B. <zb...@ur...>]

Hey, all. I'm using a Python2.3 built from CVS, and I get the 
following failure when trying to build PyObjC:

cc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -Wno-long-double 
-no-cpp-precomp -I/opt/include/python2.3 -c OC_PythonBundle.m -o 
build/temp.darwin-5.5-Power Macintosh-2.3/OC_PythonBundle.o -g
In file included from 
/System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h:33,
                  from 
/System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.
h:5,
                  from 
/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:7,
                  from ObjC.h:31,
                  from OC_PythonBundle.m:17:
/System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.
framework/Headers/MacTypes.h:291: warning: function declaration 
isn't a prototype
/System/Library/Frameworks/CoreServices.framework/Headers/../Frameworks/CarbonCore.
framework/Headers/MacTypes.h:292: warning: function declaration 
isn't a prototype
OC_PythonBundle.m: In function `+[OC_PythonBundle mainBundle]':
OC_PythonBundle.m:75: conflicting types for `getcwd'
/usr/include/unistd.h:103: previous declaration of `getcwd'
OC_PythonBundle.m:75: warning: extern declaration of `getcwd' 
doesn't match global one
Traceback (most recent call last):
   File "setup.py", line 26, in ?
     package_dir = { '':'Examples' }
   File "/opt/lib/python2.3/distutils/core.py", line 159, in setup
     raise SystemExit, "error: " + str(msg)
SystemExit: error: command 'cc' failed with exit status 1

Running 10.1.5 with the April Dev Tools (but not gcc 3.0)

I've installed the 2.3 into /opt

Zac

Re: [Pyobjc-dev] More NIB examples

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

I would not be opposed to seeing these changes checked into the pyobjc 
repository.

Ronald -- Do you have commit rights to the CVS repos?

Steve -- If you agree, I say go for it...

b.bum

On Tuesday, Jul 30, 2002, at 15:24 US/Eastern, Ronald Oussoren wrote:

> I've some more examples of building NIB-based Cocoa applications in 
> Python, and a heavily modified version of pyobjc to go with those.
>
> The 'CurrencyConvertor' applet that Jack posted a while back is now 
> much shorter, and I've added a document based application (the Todo 
> example from Learning Cocoa).
>
> The most important change to the pyobjc module is that you can now 
> subclass Objective-C classes in python. These subclasses are both 
> Python classes and Objective-C classes. This is very usefull when your 
> building document based applications.
>
> The archive can be downloaded here: 
> http://www.cistron.nl/~oussoren/pyobjc
>
> The code is work-in-progress, but usable. I'm developing using a 
> Python 2.3 (from CVS), this is probably required to use the code. 
> Check the readme in the archive for building and usage instructions.
>
> The layout of the archive is different from the original pyobjc, but 
> that will change again when we merge the code into the pyobjc 
> repository.
>
> Ronald
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Dice - The leading online job board
> for high-tech professionals. Search and apply for tech jobs today!
> http://seeker.dice.com/seeker.epl?rel_code=31
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
b.bum
We gladly feast on those who would subdue us.

[Pyobjc-dev] More NIB examples

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

I've some more examples of building NIB-based Cocoa applications in 
Python, and a heavily modified version of pyobjc to go with those.

The 'CurrencyConvertor' applet that Jack posted a while back is now much 
shorter, and I've added a document based application (the Todo example 
from Learning Cocoa).

The most important change to the pyobjc module is that you can now 
subclass Objective-C classes in python. These subclasses are both Python 
classes and Objective-C classes. This is very usefull when your building 
document based applications.

The archive can be downloaded here: 
http://www.cistron.nl/~oussoren/pyobjc

The code is work-in-progress, but usable. I'm developing using a Python 
2.3 (from CVS), this is probably required to use the code. Check the 
readme in the archive for building and usage instructions.

The layout of the archive is different from the original pyobjc, but 
that will change again when we merge the code into the pyobjc repository.

Ronald

Re: [Pyobjc-dev] Proof of concept - Cocoa Python applet with Interface Builder!

[Steven M. <sd...@ma...>]

Jack,
  I tried out your nibpythonexample code:
  I got around the problem with the scripts directory that's already
    been noted.
  On trying to build the CurrencyConverterPY, I get:

		Can't get DLOG resource with id = 260

  Do you happen to know where that resource is supposed to come from ?

  It's nice to see that my pyobjc "HelloWorld" works by dropping the
  script on the Python.app icon, as well as some Carbon examples like
  EasyDialogs. Donovan said that running from the Framework and/or
  Bundled App fixes some of the other problems I ran into with Cocoa
  (like the Menu problems caused by not having a MainMenu.nib) -- I'll
  go back and give a few of my failed experiments another try.

  I've started doing diffs of your modified pyobjc against cvs and will
  review the patches ASAP.

-- Steve

Re: [Pyobjc-dev] As you can see...

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

On Wednesday, July 10, 2002, at 09:55 , Jack Jansen wrote:

>
> On woensdag, juli 10, 2002, at 06:50 , Bill Bumgarner wrote:
>
>> .... sourceforge straightened out my stupidity regarding the 
>> administrative access to the mailing list.   Steve Majewski also has 
>> the admin password now.
>
> Ah, great! Then maybe now my posts will come through:-)
>
> And time for a request: with Ronald Oussoren I've been putting some 
> work into getting PyObjC to work with Interface Builder.
I'm currently translating the 'Todo Items' example from 'Learning Cocoa' 
into python, this should help to show of the features of the next 
snapshot of our hacked-up PyObjC.

Our current version features subclassing from objective-C classes. Those 
subclasses are not only full featured python classes but also 
objective-C classes (that can be instantiated by the NIB-loading code in 
Cocoa). The only important feature that's currently missing is 
performing calls to the superclass implementation of methods in 
subclasses of Objective-C classes. Other than that it's 'just' bugfixing 
and merging a (small) number of features of pyobjc 0.6.1 back in to get 
something that is usable again.


> It would be handy if we (or, at least, one of us) commit privileges on 
> the repository. What I'd like to do is create a branch for this stuff, 
> that would make communication a lot simpler and would allow other 
> people to look at this stuff and contribute more easily. When we think 
> it's ready for general consumption then you could decide whether to 
> incorporate it.
>
> My sourceforge login is jackjansen, I don't think Ronald has one (but 
> he can send diffs to me, so commit access for 1 person is probably good 
> enough). Let me know what you think,

I do not have a sourceforge login (never needed one before), but can get 
one if it is usefull.

Ronald

Re: [Pyobjc-dev] As you can see...

[Steven M. <sd...@ma...>]

On Friday, July 12, 2002, at 05:50  PM, Jonathan Wilson wrote:

>
> On Friday, July 12, 2002, at 02:36 PM, JW wrote:
>> A considerably long time ago I sent someone (bb...@co... ?) an 
>> 'fixed' home page that had proper CVS instructions on it (and I think 
>> update list-subscription instructions too).
> <snip>
>> If no one has it let me know and I'll see if I still have a copy 
>> somewhere.
>
> I do still have a copy -- see attached.


Thanks.
Attachment uploaded to sourceforge.net --
should be visible as: <http://pyobjc.sourceforge.net/>

-- Steve Majewski

Re: [Pyobjc-dev] As you can see...

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

On Friday, July 12, 2002, at 02:36 PM, JW wrote:
> A considerably long time ago I sent someone (bb...@co... ?) an 
> 'fixed' home page that had proper CVS instructions on it (and I think 
> update list-subscription instructions too).
<snip>
> If no one has it let me know and I'll see if I still have a copy 
> somewhere.

I do still have a copy -- see attached.

	JW

Re: [Pyobjc-dev] As you can see...

[JW <ma...@ce...>]

On Wednesday 10 July 2002 14:55, Jack Jansen wrote:
> On woensdag, juli 10, 2002, at 06:50 , Bill Bumgarner wrote:
> > .... sourceforge straightened out my stupidity regarding the
> > administrative access to the mailing list.   Steve Majewski
> > also has the admin password now.
>
> Ah, great! Then maybe now my posts will come through:-)
>

Howdy,

Good to see thigns back in motion.

A considerably long time ago I sent someone (bb...@co... ?) an 'fixed' home page that had proper CVS instructions on it (and I think update list-subscription instructions too).
I am somewhat dissapointed that it was never posted. 
If whoever I sent it to still has it, would you consider putting it up? I don't know if I still ahve a copy or not. 

If no one has it let me know and I'll see if I still have a copy somewhere.

	JW

Re: [Pyobjc-dev] As you can see...

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

On woensdag, juli 10, 2002, at 06:50 , Bill Bumgarner wrote:

> .... sourceforge straightened out my stupidity regarding the 
> administrative access to the mailing list.   Steve Majewski 
> also has the admin password now.

Ah, great! Then maybe now my posts will come through:-)

And time for a request: with Ronald Oussoren I've been putting 
some work into getting PyObjC to work with Interface Builder. It 
would be handy if we (or, at least, one of us) commit privileges 
on the repository. What I'd like to do is create a branch for 
this stuff, that would make communication a lot simpler and 
would allow other people to look at this stuff and contribute 
more easily. When we think it's ready for general consumption 
then you could decide whether to incorporate it.

My sourceforge login is jackjansen, I don't think Ronald has one 
(but he can send diffs to me, so commit access for 1 person is 
probably good enough). Let me know what you think,
--
- 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 -

[Pyobjc-dev] As you can see...

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

.... sourceforge straightened out my stupidity regarding the 
administrative access to the mailing list.   Steve Majewski also has the 
admin password now.

b.bum

[Pyobjc-dev] Re: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder!

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

I believe there is value in keeping the NIB/ObjC discussion on pyobjc 
simply because the discussion is so specific to a particular aspect of a 
very particular platform.  But, whatever, I have almost zero time to 
devote to this stuff right now and, as such...

	Tag! Steve! You're it!

I am embarrassed to admit that I currently have *no idea* what the admin 
password is to the pyobjc mailing list.   I will ping the SF 
administrators and see what can be done -- when it is resolved, Steve can 
take admin.

b.bum

On Wednesday, June 26, 2002, at 12:07 PM, Steven Majewski wrote:

>
> Added Bill Bumgarner to Cc:
>
> On Wed, 19 Jun 2002, Jack Jansen wrote:
>
>> Folks,
>> we've just succeeded in creating the first Python applet (we
>> think, you can never be sure about the "first" bit:-) that is
>> awakened from a NIB file built with Interface Builder.
>>
>> The code is all pretty messy (both the Python code and the ObjC
>> code), but at least it seems to work.
>>
>> If you want to have a look at this: get
>> http://www.cwi.nl/ftp/jack/python/mac/nibpythonexample.tar.gz,
>> read the README and play away!
>>
>> If had very limited success (none, actually) reaching the pyobjc
>> crowd the last few weeks, so I suggest that discussion of this
>> beast take place on pyt...@py... with a cc to Pyobjc-
>> de...@li..., for the time being.
>
> Jack,
>
>  I'm still here and very interested!
>
>  I finally quit my job at UVA, and I've just gotten around to switching
> my email subscriptions to another account ( either sd...@ma... or
> ma...@cs... ) and getting it hooked up to OSX's mail client
> ( as well as moving lots of work onto my personal laptop from my
> former office machines ).
>
>  I'm taking some time off -- I'm about to leave to go camping at the
> beach with my two boys. When I get back (besides job hunting) I'm
> going to get back into macpython and pyobjc in a major way -- I should
> have a bit more time to hack on it.
>
>  CC: to bbum -- Bill's the email admin. on the pyobjc mailing list --
> Bill: if you don't have time to handle it you could transfer it to me.
> But maybe because the list has been so quit, he just hasn't looked it
> the inbox for a while. ( alternatives: just make the list open ? or
> now that it's getting more mailstream for macpython, just switch to
> macpython list ? )
>
>  I'll excitedly try out all this stuff as soon as I get back from the
> beach!
>
> -- Steve
>
>
>
>
b.bum
....lying there snoring,
	breath smelling like a 1948 buick.

[Pyobjc-dev] Re: [Pythonmac-SIG] Proof of concept - Cocoa Python applet with Interface Builder!

[Steven M. <sd...@ma...>]

Added Bill Bumgarner to Cc:

On Wed, 19 Jun 2002, Jack Jansen wrote:

> Folks,
> we've just succeeded in creating the first Python applet (we
> think, you can never be sure about the "first" bit:-) that is
> awakened from a NIB file built with Interface Builder.
>
> The code is all pretty messy (both the Python code and the ObjC
> code), but at least it seems to work.
>
> If you want to have a look at this: get
> http://www.cwi.nl/ftp/jack/python/mac/nibpythonexample.tar.gz,
> read the README and play away!
>
> If had very limited success (none, actually) reaching the pyobjc
> crowd the last few weeks, so I suggest that discussion of this
> beast take place on pyt...@py... with a cc to Pyobjc-
> de...@li..., for the time being.

Jack,

 I'm still here and very interested!

 I finally quit my job at UVA, and I've just gotten around to switching
my email subscriptions to another account ( either sd...@ma... or
ma...@cs... ) and getting it hooked up to OSX's mail client
( as well as moving lots of work onto my personal laptop from my
former office machines ).

 I'm taking some time off -- I'm about to leave to go camping at the
beach with my two boys. When I get back (besides job hunting) I'm
going to get back into macpython and pyobjc in a major way -- I should
have a bit more time to hack on it.

 CC: to bbum -- Bill's the email admin. on the pyobjc mailing list --
Bill: if you don't have time to handle it you could transfer it to me.
But maybe because the list has been so quit, he just hasn't looked it
the inbox for a while. ( alternatives: just make the list open ? or
now that it's getting more mailstream for macpython, just switch to
macpython list ? )

 I'll excitedly try out all this stuff as soon as I get back from the
beach!

-- Steve

[Pyobjc-dev] Proof of concept - Cocoa Python applet with Interface Builder!

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

Folks,
we've just succeeded in creating the first Python applet (we 
think, you can never be sure about the "first" bit:-) that is 
awakened from a NIB file built with Interface Builder.

The code is all pretty messy (both the Python code and the ObjC 
code), but at least it seems to work.

If you want to have a look at this: get 
http://www.cwi.nl/ftp/jack/python/mac/nibpythonexample.tar.gz, 
read the README and play away!

If had very limited success (none, actually) reaching the pyobjc 
crowd the last few weeks, so I suggest that discussion of this 
beast take place on pyt...@py... with a cc to Pyobjc-
de...@li..., for the time being.
--
- 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 -

[Pyobjc-dev] Rewrite status?

[Michael M. <mic...@ma...>]

Hi,
I've just perused the archives of this list, and I saw a lot of 
activity, running into some problems, mention of a major rewrite, then 
very little since.

I'm curious about the state of the project right now (is it still in 
active development?)

I've read the BUGS file in the distribution, and I'm curious if it's 
worth poking around, or if there's a major update on the horizon that I 
should wait for... - the freshest thing in the CVS repository is 6 weeks 
old now.

It'd sure be cool if we could get this going again - I know I'd love to 
use it!

I'm certainly willing to devote some time (maybe more time than talent) 
to help out - I had the idea that as I learned what was going on, I 
could generate some furhter documentation. Does that sound like a good 
idea?

cheers,
-mike

--
Michael O. McCracken
mi...@cs...
CSE Ph.D. Student

Re: [Pyobjc-dev] Hello & notes about the SourceForge Site

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

On Sat, 2 Feb 2002, ma...@ce... wrote:

> Howdy,
>
> I've very interested in this project. I am not yet a programmer (just
> starting to learn) but over the years I have become very interested in
> cross platform programming. Some day I'd like to help with ports too.
> Primary platforms of interest are UNIX (First Linux, then Mac OS X,
> then BSD)
>
> As a result of this interest I'm hoping to learn programming
> languages/skills in the following order:

> Python - because it's fast simply and cross-platform
> <insert Perl here for other reasons (read: it's what we use at work ;-) >
> Python/Tk - cross platform GUI for Python

> C - so I can read other's source code and port it to better languages
> ;-) also I've been told it's a good idea to learn C before ObjC

 Once you know C, there is very little extra syntax to learn for
objective C. The big hump on the learning curve is to learn how
to use all of the framework classes, and to learn O-O design
principles.
 The latter, you can pick up learning Python! Python's style of
Object-Orientation is much closer to the SmallTalk/Objective-C
model than it is to the C++ model.
 So yeah -- I think your order: Python, C, Objective-C ... makes
a lot of sense.

 You might want to step thru some of Apple's Cocoa programming
demos/examples without waiting to master objective-c, just to
learn how to use the tools and see how easy it is to use the
AppKit framework.

> Objective C / Cocoa / Open/GNUStep - I presume everyone here knows why
> I'd use those

And when you're ready to tackle Cocoa seriously, I recommend Aaron
Hillegass's book: "Cocoa Programming for Mac OS X"  -- I've started
working my way thru and it's much better that the O'Reilly Cocoa book.

You ought to try to get GnuStep up and running on your Linux box --
it would be nice  to be able to test if things work cross platform.
We were thinking of stripping out some of the support for various
flavors of NextStep/OpenStep/GnuStep because it makes the code harder
to follow, has some deprecated features in it, and we really don't
have anyone using those systems to test if it even works. I have heard
that the Gnustep folks have been trying to track the Cocoa API's --
since that's going to be the major *Step platform, they're aiming
for application source compatability with Apple. So we're probably
going to limit the supported targets to OSX, OSX-Server and GnuStep,
and drop all of the ancient NextStep supporting code. (also:
Jack and I have been stripping out all of the unused and unneeded
legacy Next code from Python's dynamic library loading code
in dynload_next.c. )

> QT/C++ - again, for porting and also I favor KDE on Linux
> And finally Java - again, for porting+

FYI: you can also access the Cocoa classes from Jython -- some
things may work better right now, however, you're going thru
two bridges -- Python <-> Java <-> objC , which means you need
to do a more explicit conversions sometimes. ( Jython knows
about Java classes, but it doesn't have the same intimate
connection with the objC classes -- so for example, Jython
can translate automatically from Java strings to Python strings,
but it doesn't know that class NSString is also a type of
string. pyobjc knows and translates NSStrings to Python strings.)


> Anyway... this is all mostly dreams at the moment because I'm too busy
> to actually learn anything very quickly (I have a pretty good start on
> Python, but Perl interrupted and it's going slowly. I can honestly say
> I do not like Perl :-/ )
>
> In the mean time this project really caught my attention.

This project has had it's stop's and go's and we're all learning
as we go along: I suspect that outside of a lucky few who grew
up on NextStep and are now focusing on OSX/Cocoa, most of us are
not yet involved in large scale Cocoa development and are trying
to learn it in our spare time.

-- Steve Majewski

[Pyobjc-dev] Hello & notes about the SourceForge Site

[<ma...@ce...>]

Howdy,

I've very interested in this project. I am not yet a programmer (just starting to learn) but over the years I have become very interested in cross platform programming. Some day I'd like to help with ports too. Primary platforms of interest are UNIX (First Linux, then Mac OS X, then BSD)

As a result of this interest I'm hoping to learn programming languages/skills in the following order:

Python - because it's fast simply and cross-platform
<insert Perl here for other reasons (read: it's what we use at work ;-) >
Python/Tk - cross platform GUI for Python
C - so I can read other's source code and port it to better languages ;-) also I've been told it's a good idea to learn C before ObjC
Objective C / Cocoa / Open/GNUStep - I presume everyone here knows why I'd use those
QT/C++ - again, for porting and also I favor KDE on Linux
And finally Java - again, for porting+

Anyway... this is all mostly dreams at the moment because I'm too busy to actually learn anything very quickly (I have a pretty good start on Python, but Perl interrupted and it's going slowly. I can honestly say I do not like Perl :-/ )

In the mean time this project really caught my attention.

I have taken advantage of the permission given on the project's home page and fixed the link to the Mailman page, and also fixed the CVS instructions. I'll mail it to bb...@co... asap. Should I post it to the list too?

later,

	JW

[Pyobjc-dev] pyobjc 0.6.1 release

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

There is a new release pyobjc-0.6.1 on SourceForge:

http://prdownloads.sourceforge.net/pyobjc/pyobjc-0.6.1.tar.gz

which should build and work with Python-2.2

(It includes a redefinition to correct a bug in
   Python-2.2/Include/abstract.h, so you don't need a patched
   version of Python-2.2 )

It includes a Cocoa package with Foundation.py and AppKit.py
 wrappers. ( You can now do "from pyobjc.Foundation import *" )
and a HelloWorld.py program in the Examples folder.

It has one major bugfix and several smaller ones.

Since there is still at least one major bug in this version,
it has some additional support for debugging:

It builds with -g for gdb debugging by default.

If you run Python with '-v' switch, pyobjc will dump a log of
message sends to a /tmp file.


This is not yet the 'New Improved Future Version that fixes
the Type/Class barrier' --   I've run into a few design
questions and I thought it worth exploring some of those issues
with the current model a bit longer.


Is anyone else going to be at Python10 next week?
Maybe we can have a BOF for pyobjc or the state of MacOSX Python?


-- Steve Majewski

Re: [Pyobjc-dev] was: [Swig] Swig for Mac OSX - Objective-C?

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

on 1/29/02 3:48 PM, Steven D. Majewski wrote:
>> 
>> I checked out the pyobjc from CVS, and ran "setup.py install" (probably with
>> the 2.2 version of Python, in case that makes a difference).
>> 
> 
> I believe that *does* make a difference: one of the features of distutils
> is that, since you're running Python, it knows which version you're
> running and where it's libraries are installed, etc.   If you have
> several versions installed, you can explicitly run 'python2.1' or
> you can give an entire path for an uninstalled version ( '/usr/local/
> src/Python-2.2/python.exe' for example. )

I still can't get it to work. I'm getting this error:

DistutilsPlatformError: invalid Python installation: unable to open
/usr/local/lib/python2.1/site-packages/lib/python2.1/config/Makefile (No
such file or directory)

In fact there is nothing in the 'site-packages' directory (??) I looked in
/usr/local/lib/python2.1/Lib where there is another site-packages directory
(also empty) and a bunch of other localized directories, but it is far from
clear to me that picking one of those will solve the problem.

> 
> To be more exact and precise: I did my diffs on 2.1.2 and 2.2 -- I didn't
> believe that this was in 2.1 or 2.1.1 but I'm not absolutely sure.
> (But that PyObject_DelItemString may be from running setup.py from 2.2)
 ...
> Giving the 2.2 bug a little more thought: I THINK that if I build
> a pyobjc.so with a patched 2.2, it should work with an unpatched 2.2
> binary. It's the wrong symbol in Python's Include file that causes
> pyobjc to bind to  symbol that's not there. If that is true, I'll
> probably roll out another distribution, as well as a 2.2 pyobjc.so
> binary whether or not I can find and fix that one-last-bug!

Well, I see that the patch was accepted, so perhaps the best thing for me to
do is sit tight and wait for your revision to work with 2.2 (?)

> 
> Does it also use NSProxy ?  (Just wondering if you have more know-how than
> I do for debugging my pyobjc problem! ;-)
> 

Sorry :) I guess all that stuff is handled by the NSConnection object.

Bob (must have pizza now)

Re: [Pyobjc-dev] was: [Swig] Swig for Mac OSX - Objective-C?

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

On Tue, 29 Jan 2002, Bob Savage wrote:

> :: Moved discussion to pyo...@li... because we strayed
> significantly from Swig ::
>
> on 1/29/02 12:50 PM, Steven Majewski wrote:
> >
> > pyobjc doesn't build with python 2.2 because of a bug in python 2.2 that's
> > fixed in CVS
> >
> > Include/abstract.h change this line:
> > #define PyMapping_DelItemString(O,K)  PyObject_DelItemString((O),(K))
> >
> > back to what it was in 2.1:
> > #define PyMapping_DelItemString(O,K) PyDict_DelItemString((O),(K))
> >
>
> I checked out the pyobjc from CVS, and ran "setup.py install" (probably with
> the 2.2 version of Python, in case that makes a difference).
>

I believe that *does* make a difference: one of the features of distutils
is that, since you're running Python, it knows which version you're
running and where it's libraries are installed, etc.   If you have
several versions installed, you can explicitly run 'python2.1' or
you can give an entire path for an uninstalled version ( '/usr/local/
src/Python-2.2/python.exe' for example. )


> Then I started the 2.1 version of Python, added the 2.1 modules to the end
> of the python_path, and got the following error:
>
> >>> import pyobjc
> dyld: /usr/local/bin/python2.1.exe Undefined symbols:
> _PyObject_DelItemString
> _PyType_IsSubtype
>
> If I understand what you said above, I should not see this error under 2.1?

To be more exact and precise: I did my diffs on 2.1.2 and 2.2 -- I didn't
believe that this was in 2.1 or 2.1.1 but I'm not absolutely sure.
(But that PyObject_DelItemString may be from running setup.py from 2.2)


> > There seem to be a few problems using AppKit GUI classes from a unix
> > command line program running from Terminal.App -- there may also be
> > a few Carbon problems, but I don't know if they are as bad. Is that
> > what you're talking about doing, or are you going to roll your own
> > command line front end?
>
> We use the distributed object architecture (through an NSConnection). It
> works quite well for GnuPlot.

Does it also use NSProxy ?  (Just wondering if you have more know-how than
I do for debugging my pyobjc problem! ;-)

Giving the 2.2 bug a little more thought: I THINK that if I build
a pyobjc.so with a patched 2.2, it should work with an unpatched 2.2
binary. It's the wrong symbol in Python's Include file that causes
pyobjc to bind to  symbol that's not there. If that is true, I'll
probably roll out another distribution, as well as a 2.2 pyobjc.so
binary whether or not I can find and fix that one-last-bug!

-- Steve Majewski

[Pyobjc-dev] was: [Swig] Swig for Mac OSX - Objective-C?

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

:: Moved discussion to pyo...@li... because we strayed
significantly from Swig ::

on 1/29/02 12:50 PM, Steven Majewski wrote:
>
> pyobjc doesn't build with python 2.2 because of a bug in python 2.2 that's
> fixed in CVS
> 
> Include/abstract.h change this line:
> #define PyMapping_DelItemString(O,K)  PyObject_DelItemString((O),(K))
> 
> back to what it was in 2.1:
> #define PyMapping_DelItemString(O,K) PyDict_DelItemString((O),(K))
> 

I checked out the pyobjc from CVS, and ran "setup.py install" (probably with
the 2.2 version of Python, in case that makes a difference).

Then I started the 2.1 version of Python, added the 2.1 modules to the end
of the python_path, and got the following error:

>>> import pyobjc
dyld: /usr/local/bin/python2.1.exe Undefined symbols:
_PyObject_DelItemString
_PyType_IsSubtype

If I understand what you said above, I should not see this error under 2.1?

> There seem to be a few problems using AppKit GUI classes from a unix
> command line program running from Terminal.App -- there may also be
> a few Carbon problems, but I don't know if they are as bad. Is that
> what you're talking about doing, or are you going to roll your own
> command line front end?

We use the distributed object architecture (through an NSConnection). It
works quite well for GnuPlot.

Bob

[Pyobjc-dev] new cvs checkins

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

Checking in pyobjc/OC_PythonObject.m;
/cvsroot/pyobjc/pyobjc/OC_PythonObject.m,v  <--  OC_PythonObject.m
new revision: 1.3; previous revision: 1.2
done
	replaced [super forwardInvocation] lines that were wrongly
	commented out. the real fix is in ObjCObject.m below.

Checking in pyobjc/ObjC.m;
/cvsroot/pyobjc/pyobjc/ObjC.m,v  <--  ObjC.m
new revision: 1.3; previous revision: 1.2
done
	With -v ($PYTHONVERBOSE) flag, pyobjc will dump all
	message sends to a /tmp file.

Checking in pyobjc/ObjCObject.m;
/cvsroot/pyobjc/pyobjc/ObjCObject.m,v  <--  ObjCObject.m
new revision: 1.3; previous revision: 1.2
done
	fixed crash on accessing some abstract classes like NSProxy

Checking in pyobjc/setup.py;
/cvsroot/pyobjc/pyobjc/setup.py,v  <--  setup.py
new revision: 1.3; previous revision: 1.2
done
	added -g flag for compile.
	might as well build for debugging as long as there's bugs

Checking in pyobjc/Examples/HelloWorld.py;
/cvsroot/pyobjc/pyobjc/Examples/HelloWorld.py,v  <--  HelloWorld.py
new revision: 1.3; previous revision: 1.2
done
	fixed spelling and added missing line.
	example should really work now.

[Pyobjc-dev] patch to fix crash on accessing NSProxy and some others

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

pyobjc crashes when you try to touch some Abstract Proxy classes
like NSProxy. For example, you can't iterate thru the objects
in pyobjc.runtime and print them all without crashing.

Problem is that isKindOfClass: isn't implemented for those
classes as it's intended to be forwarded. But when you're
asking the abstract Class itself, rather than an object of
a subclass, it's not going to get forwarded. (The same goes
for isProxy, which call isKindOfClass: -- they are both
meant to be called on objects, not classes. (Class Objects
are all of type Class.)

Inserting an ISCLASS() test seems to fix this.
I'm not yet sure if there's any other side effects of this patch.

-- Steve Majewski


*** ObjCObject.m.0      Tue Jan 22 12:38:29 2002
--- ObjCObject.m        Tue Jan 22 13:37:50 2002
***************
*** 52,58 ****
    if (self == NULL)
      return NULL;

!   if (obj && ([obj isKindOfClass: [NSAutoreleasePool class]] == NO) )
      [obj retain];

    self->oc_object = obj;
--- 52,59 ----
    if (self == NULL)
      return NULL;

!   if (obj &&  !ISCLASS(obj) &&
!       ([obj isKindOfClass: [NSAutoreleasePool class]] == NO) )
      [obj retain];

    self->oc_object = obj;

[Pyobjc-dev] pyobjc-0.6 with Python2.2 and message debugging

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

[1] pyobjc will build for Python2.2, but there is a bug in 2.2 that
 needs to be fixed. (This is fixed in CVS)

http://sourceforge.net/tracker/?group_id=5470&atid=105470&func=detail&aid=498915

[This has been discussed further on pythonmac-sig]


For debugging, I have found that setting instrumentObjcMessageSends()
causes a trace of all object messages to be dumped to a /tmp file.
I've put a line in pyobjc ObjC.m to turn on tracing if the -v
(PYTHONVERBOSE) flag it set. This will go into the next release,
but below is a diff if anyone wants it before then.

-- Steve Majewski


*** ObjC.m      Mon Jan 21 17:03:28 2002
--- ObjC.m.0    Mon Jan 21 17:00:52 2002
***************
*** 146,153 ****
    [OC_PythonBundle class];

    ObjCObject_initialize();
-
-   if (Py_VerboseFlag) instrumentObjcMessageSends(1);

    if (PyErr_Occurred())
      Py_FatalError ("can't initialize module pyobjc");
--- 146,151 ----

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

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

On Tue, 10 Jul 2001, Andrew Zeldis wrote:

> > Subject says it all...
>
> I myself have become convinced that the gap between python and cocoa is big
> enough that, for the purpose I wanted (interactive experimentation with
> cocoa) other solutions are better.  Joy (commercial) and F-script (free)
> come to mind.
>
> For developing applications in python, IMO, a more pythonic framework built
> around the cocoa classes would be useful.  The python-Objective-C
> translation works well, but it's not pretty...  Also, I don't think anyone
> has solved the bootstrapping problems with getting an NSApplication up and
> running (with python objects as delegates, etc).

 The other reason things have been quiet is that we're heading towards
a major rewrite -- we need to make ObjC objects into not just Python
objects, but Python classes that are fully subclassable. There is a
way to do this now with Extension Classes: this is used in Zope and
the Boost C++ libraries, but it relies on a hack that may be changed --
this has been under discussion on the Python-Dev list -- there is
an initial implementation of the new method in the python-dev cvs
tree, but I haven't had a chance yet to download it and look at how
it differs from the old method. ( Since the plan is to reduce or
eliminate the difference between classes and objects and to make
built-in objects subclassable, it's possible that not much new will
have to be done to enable this feature. )

 Being able to subclass objective-c classes in Python (which thru
the bridge, will appear as objective-c classes to Cocoa ) will make
it much easier to do Cocoa programming in Python.


-- Steve Majewski

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

[Andrew Z. <az...@ma...>]

> Subject says it all...

I myself have become convinced that the gap between python and cocoa is big
enough that, for the purpose I wanted (interactive experimentation with
cocoa) other solutions are better.  Joy (commercial) and F-script (free)
come to mind.

For developing applications in python, IMO, a more pythonic framework built
around the cocoa classes would be useful.  The python-Objective-C
translation works well, but it's not pretty...  Also, I don't think anyone
has solved the bootstrapping problems with getting an NSApplication up and
running (with python objects as delegates, etc).

Disclaimer: I'm a novice!