pyobjc-dev

[Pyobjc-dev] GNUstep support

[David B. <te...@bi...>]

Going with the assumption that I will get PyObjC working decently on my lap=
top=20
(can't try out the suggestions until tonight), I'm now trying to get it up=
=20
and going on my linux box.

After installing the python-dev packages, running python setup.py --help=20
produced the following:

<snip build of libffi that worked>
Performing task: Generating wrappers & stubs
sh: line 1: /usr/bin/sw_vers: No such file or directory
Traceback (most recent call last):
  File "Scripts/CodeGenerators/cocoa_generator.py", line 32, in ?
    VER =3D '.'.join(VER.split('.')[:2])
AttributeError: 'NoneType' object has no attribute 'split'
Task 'Generating wrappers & stubs' failed [256]

Now, 'locate sw_vers' produced nothing, as did 'apt-cache search sw_vers', =
so=20
I went to Google.  Every hit on sw_vers had to do with OSX, so can I safely=
=20
assume that it is not available in linux/GNUstep?  Maybe (really reading=20
between the lines here), it should be calling uname instead?  I *did* read=
=20
somewhere (in a changelog? maybe?) that GNUstep support was being removed=20
until a volunteer was found, so if necessary, take this as me stepping=20
forward...

Relevant (?) information:

Debian/Sid on i386
Python 2.2
GNUstep 1.6.0/0.8.5
GCC (objc) 3.3
Libra

P.S.  I went ahead and signed up to the list, so any replies need not cc: m=
e. =20
Same goes for the other thread, but whatever...

=2D-=20
"Sorry about the whole 'bomb' thing" - Bruce Rollins
D.A.Bishop

[Pyobjc-dev] GNUstep support

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

About a month ago PyObjC did built correctly on my Linux/ix86 system 
with GNUstep and it did pass most, if not all, unittests. It did not 
yet support AppKit because the Linux machine is a headless server 
without the X11 libraries.

I therefore updated the website to say that PyObjC works on GNUstep 
systems. ... only to discover that it no longer works... one of the 
updates to the linux machine completely broke PyObjC just now that I 
found an old box where I could install the GUI part of GNUstep :-(

There are two serious problems w.r.t. supporting GNUstep:

1. The only reason I work on GNUstep support at all is that I seriously 
believe that porting software to other platforms improves its quality. 
Porting to GNUstep already helped finding a number of bugs in the 
generic part of PyObjC. However, I don't use GNUstep myself and am 
therefore not terribly motivated to work on this.

2. The GNU Objective-C runtime is not well suited for the kind of 
things we do (such as creating new classes at runtime instead of 
loading dynamic libraries containing classes). I'm currently using some 
private functions to add new classes because the GNU runtime does not 
have a public API to do this, and that's probably what broke PyObjC.

The combination of these two items mean that GNUstep support will 
forever be lacking unless someone is willing to work on this.

Ronald

--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

[Pyobjc-dev] Re: GNUstep support

[Michael H. <mw...@py...>]

Ronald Oussoren <ous...@ci...> writes:

> 2. The GNU Objective-C runtime is not well suited for the kind of
>    things we do (such as creating new classes at runtime instead of
>    loading dynamic libraries containing classes). I'm currently using
>    some private functions to add new classes because the GNU runtime
>    does not have a public API to do this, and that's probably what
>    broke PyObjC.
>
> The combination of these two items mean that GNUstep support will
> forever be lacking unless someone is willing to work on this.

Well, it sounds like PyObjC on GNUstep could do with some support from
the GNUstep side... have you or anyone else tried badgering them into
supporting an API for this kind of thing?

Cheers,
mwh

-- 
  : Giant screaming pieces of excrement, they are.
  I have a feeling that some of the people in here have a 
  MUCH more exciting time relieving themselves than I do.
                                       -- Mike Sphar & Dave Brown, asr

Re: [Pyobjc-dev] Re: GNUstep support

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

On 6-feb-04, at 12:39, Michael Hudson wrote:

> Ronald Oussoren <ous...@ci...> writes:
>
>> 2. The GNU Objective-C runtime is not well suited for the kind of
>>    things we do (such as creating new classes at runtime instead of
>>    loading dynamic libraries containing classes). I'm currently using
>>    some private functions to add new classes because the GNU runtime
>>    does not have a public API to do this, and that's probably what
>>    broke PyObjC.
>>
>> The combination of these two items mean that GNUstep support will
>> forever be lacking unless someone is willing to work on this.
>
> Well, it sounds like PyObjC on GNUstep could do with some support from
> the GNUstep side... have you or anyone else tried badgering them into
> supporting an API for this kind of thing?

Nope, to be honest I haven't even thought of asking for such an API. 
Now that you mention this it is obvious that such a request is usefull 
:-)

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

Re: [Pyobjc-dev] GNUstep support

[David B. <te...@bi...>]

[Replying to yourself is so crass....]

On Tuesday 08 July 2003 02:34 pm, David Bishop wrote:
> <snip build of libffi that worked>
> Performing task: Generating wrappers & stubs
> sh: line 1: /usr/bin/sw_vers: No such file or directory
> Traceback (most recent call last):
>   File "Scripts/CodeGenerators/cocoa_generator.py", line 32, in ?
>     VER =3D '.'.join(VER.split('.')[:2])
> AttributeError: 'NoneType' object has no attribute 'split'
> Task 'Generating wrappers & stubs' failed [256]

I worked around this by putting the same os checking code into=20
cocoa_generator.py as is in setup.py.  It now only tries to call sw_vers on=
=20
OSX machines.  The next snag I ran into was farther down, where=20
cocoa_generator tries to run various commands 1) on OSX only things like=20
WebKit and AddressBook, but also 2) in an OSX specfic manner=20
(/System/Library/Frameworks, etc).  I now have it checking for GNUstep and=
=20
adjusting accordingly.  My hacked cocoa_generator available upon request. =
=20
The only garuntee is that it works for me :-)

Now that it's getting to the actual build, I'm hitting the same snag I get=
=20
when trying to build ocunit, namely that Gnu/GCC 3.3 doesn't ship with=20
objc/runtime.h, or various other .h files that are apparently available in=
=20
OSX (objc/objc-class.h specifically).  This breaks any calls to=20
class_add_method_list or (in ocunit) class_getClassMethod.  Now, Marco=20
Sheurer was going to get back to me on what the proper fix is, but he hasn'=
t=20
as of yet (this only came up last week, so I'm not crying foul).

So, any suggestions?  I'm in no rush, so I can afford to spend the time to=
=20
work through these things.  All I need is someone better at this stuff than=
 I=20
am telling me what to do :-)

=2D-=20
"Sorry about the whole 'bomb' thing" - Bruce Rollins
D.A.Bishop

Re: [Pyobjc-dev] GNUstep support

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

On Tuesday, 8 July, 2003, at 22:34, David Bishop wrote:

> Going with the assumption that I will get PyObjC working decently on 
> my laptop
> (can't try out the suggestions until tonight), I'm now trying to get 
> it up
> and going on my linux box.

There is little change that you'll get the Linux part to work without a 
lot of work, the issue below is just the first and easiest problem. We 
currently do not support GNUstep and the code will not compile on 
GNUstep systems. Getting it to work requires writing some low-level 
functions to interface with the Objective-C runtime for GNUstep 
(actually the GNU runtime for Objective-C, as opposed to the Apple/NeXT 
one on MacOS X). While I'd like to have GNUstep support I currently 
don't care enough to perform the port myself, but enough to not rip the 
partial GNUstep support out.

>
> After installing the python-dev packages, running python setup.py 
> --help
> produced the following:
>
> <snip build of libffi that worked>
> Performing task: Generating wrappers & stubs
> sh: line 1: /usr/bin/sw_vers: No such file or directory
> Traceback (most recent call last):
>   File "Scripts/CodeGenerators/cocoa_generator.py", line 32, in ?
>     VER = '.'.join(VER.split('.')[:2])
> AttributeError: 'NoneType' object has no attribute 'split'
> Task 'Generating wrappers & stubs' failed [256]

The easiest way to work around this problem is to modify setup.py and 
make sure it doesn't call this script when on a GNUstep system. We have 
some (old) wrappers for the AppKit and Foundation frameworks that 
should work on GNUstep and those will automaticly be picked up when 
compiling the bridge.

>
> Now, 'locate sw_vers' produced nothing, as did 'apt-cache search 
> sw_vers', so
> I went to Google.  Every hit on sw_vers had to do with OSX, so can I 
> safely
> assume that it is not available in linux/GNUstep?  Maybe (really 
> reading
> between the lines here), it should be calling uname instead?  I *did* 
> read
> somewhere (in a changelog? maybe?) that GNUstep support was being 
> removed
> until a volunteer was found, so if necessary, take this as me stepping
> forward...

sw_vers is an OSX tool that solves the problem that 'uname -a' doesn't 
show usefull version information on OSX machines. Just like on Linux 
machines 'uname' shows the kernel version, which has no documented 
relation to the OS release.

Our non-support for GNUstep is prominently featured on the website. 
IMHO the best way to proceed with a port to GNUstep would be to ignore 
the 'cocoa_generator.py' issues for now and try to get the core going 
first. This requires the implementation of a number of functions, IIRC 
in class-builder.m and objc_support.m. Some OSX-specific stuff may have 
crept into the code, that would require fixing as well.

Good luck,
	Ronald