pyobjc-dev — CVS commit notices go here

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

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

On 6-apr-04, at 19:49, Bob Ippolito wrote:
>   The fact that it works is more of an exception than the rule, as it 
> does not comply with the rules in Apple's Multithreading 
> documentation.
>

Other than not calling priming the thread-safety of Cocoa the 
WebServicesTool seems to be correct. There is no reason for Cocoa to 
call into Python on the WorkerThread, and that thread creates an 
autorelease pool before doing anything that might call into Cocoa.

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

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

[Bob I. <bo...@re...>]

On Apr 6, 2004, at 12:47 PM, b.bum wrote:

> On Apr 6, 2004, at 7:21 AM, Bob Ippolito wrote:
>> The thing is that Foundation and Cocoa needs to know about the 
>> threads you are using in the same way that Python needs to know about 
>> them (via PyGILState_Ensure, etc.).  There is a hook and notification 
>> that happens in Foundation when you detach your first NSThread (which 
>> this program never explicitly does), and you are otherwise supposed 
>> to at least call +[NSThread currentThread] from any raw pthread that 
>> expects to call Foundation or Cocoa code (which this program also 
>> never does).
>
> If the program doesn't call Foundation or Cocoa from the threads, then 
> there is no need to notify the ObjC runtime (or Foundation) that the 
> app has 'gone threaded'.

It does call Foundation..

> And... as Ronald says.  Worked before, doesn't work now... look to the 
> changes.

Yeah, the new changes weren't complete, the GIL wasn't released during 
the call to NSApplicationMain, which didn't allow Python threads to 
run.  I was close to catching this myself, but I got caught up trying 
to make Python do the correct thing, instead of just making it work ;)

> Also -- in a chat w/Bob last night.   If we need to tie something to 
> the lifetime of an NSThread, use NSThread's threadDictionary.  That is 
> what it is far (and what it is used for by the Foundation).

I think the new method stub autorelease pool management should take 
care of things (need to read Python threadstate management source code 
to verify) in the case of NSThread calling Python code.  However, in 
order for a Python thread (pthread really) to *correctly* call into 
Foundation you must first perform an explicit NSThread.currentThread() 
and pool = NSAutoreleasePool.alloc().init() (not sure if that is 
necessarily the order).  WebServicesTool only does one of these things, 
and I think it should even be creating a NSAutoreleasePool earlier in 
case an ObjC thing gets passed over the queue.  The fact that it works 
is more of an exception than the rule, as it does not comply with the 
rules in Apple's Multithreading documentation.

-bob

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

[b.bum <bb...@ma...>]

On Apr 6, 2004, at 7:21 AM, Bob Ippolito wrote:
> The thing is that Foundation and Cocoa needs to know about the threads 
> you are using in the same way that Python needs to know about them 
> (via PyGILState_Ensure, etc.).  There is a hook and notification that 
> happens in Foundation when you detach your first NSThread (which this 
> program never explicitly does), and you are otherwise supposed to at 
> least call +[NSThread currentThread] from any raw pthread that expects 
> to call Foundation or Cocoa code (which this program also never does).

If the program doesn't call Foundation or Cocoa from the threads, then 
there is no need to notify the ObjC runtime (or Foundation) that the 
app has 'gone threaded'.

And... as Ronald says.  Worked before, doesn't work now... look to the 
changes.

Also -- in a chat w/Bob last night.   If we need to tie something to 
the lifetime of an NSThread, use NSThread's threadDictionary.  That is 
what it is far (and what it is used for by the Foundation).

b.bum

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

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

On 6-apr-04, at 16:21, Bob Ippolito wrote:

>
> On Apr 6, 2004, at 3:01 AM, Just van Rossum wrote:
>
>> Bob Ippolito wrote:
>>
>>> I have no idea how to reasonably debug that example, it freely mixes
>>> ObjC and Python threading code.  It's not even correct for at least
>>> one reason: it doesn't detach an NSThread anywhere, so Foundation and
>>> Cocoa are not notified to be thread safeish.  Even though it did work
>>> previously, that might have been by accident.
>>
>> Huh? The WST example goes through great pain not to call any GUI code
>> from the worker threads, so I don't see why Cocoa needs to be 
>> notified.
>>
>> It's also the first time I hear that pure pthreads would be a no-no in
>> Cocoa. Is that really so? How do NSThreads cooperate with the 
>> threading
>> module?
>
> The thing is that Foundation and Cocoa needs to know about the threads 
> you are using in the same way that Python needs to know about them 
> (via PyGILState_Ensure, etc.).  There is a hook and notification that 
> happens in Foundation when you detach your first NSThread (which this 
> program never explicitly does), and you are otherwise supposed to at 
> least call +[NSThread currentThread] from any raw pthread that expects 
> to call Foundation or Cocoa code (which this program also never does).
>
> That said, it's probably not WHY it doesn't work, I'm just saying the 
> program isn't strictly correct to begin with, and it uses threads, so 
> it will be hard to debug.

It worked before the PyGILState_ changes, and doesn't work now. I'd say 
this is a PyObjC bug until proven otherwise.

Luckily I've already fixed this problem: the wrapper for 
NSApplicationMain didn't release the GIL.

Ronald
>
> -bob
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

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

[Bob I. <bo...@re...>]

On Apr 6, 2004, at 3:01 AM, Just van Rossum wrote:

> Bob Ippolito wrote:
>
>> I have no idea how to reasonably debug that example, it freely mixes
>> ObjC and Python threading code.  It's not even correct for at least
>> one reason: it doesn't detach an NSThread anywhere, so Foundation and
>> Cocoa are not notified to be thread safeish.  Even though it did work
>> previously, that might have been by accident.
>
> Huh? The WST example goes through great pain not to call any GUI code
> from the worker threads, so I don't see why Cocoa needs to be notified.
>
> It's also the first time I hear that pure pthreads would be a no-no in
> Cocoa. Is that really so? How do NSThreads cooperate with the threading
> module?

The thing is that Foundation and Cocoa needs to know about the threads 
you are using in the same way that Python needs to know about them (via 
PyGILState_Ensure, etc.).  There is a hook and notification that 
happens in Foundation when you detach your first NSThread (which this 
program never explicitly does), and you are otherwise supposed to at 
least call +[NSThread currentThread] from any raw pthread that expects 
to call Foundation or Cocoa code (which this program also never does).

That said, it's probably not WHY it doesn't work, I'm just saying the 
program isn't strictly correct to begin with, and it uses threads, so 
it will be hard to debug.

-bob

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

[Just v. R. <ju...@le...>]

Bob Ippolito wrote:

> I have no idea how to reasonably debug that example, it freely mixes
> ObjC and Python threading code.  It's not even correct for at least
> one reason: it doesn't detach an NSThread anywhere, so Foundation and
> Cocoa are not notified to be thread safeish.  Even though it did work
> previously, that might have been by accident.

Huh? The WST example goes through great pain not to call any GUI code
from the worker threads, so I don't see why Cocoa needs to be notified. 

It's also the first time I hear that pure pthreads would be a no-no in
Cocoa. Is that really so? How do NSThreads cooperate with the threading
module?

Just

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

[Paul D. <pa...@do...>]

On 5 Apr 2004, at 22:31, Bob Ippolito wrote:

> What does your application actually do?  Chances are, there is a 
> single threaded (as far as Python is concerned, at least) approach you 
> can take that will have higher performance and be easier to debug.
>
>
It's quite a simple application. It parses the iTunes library XML file, 
gathers some statistics about all the tracks and display the stats and 
the tracks in a couple of NSTableViews. I was using a thread to parse 
the file and generate the python objects so that the UI remained 
responsive whilst the app starts up. It take 5 or 6 seconds to parse a 
very large library on my laptop. A spinning NSProgressIndicator is 
shown when the loading takes place.

I'm keen to do this the correct way, but I'm still learning Mac 
programming so I just picked the first thread stuff that I found. I 
also seem to recall reading that NSThread couldn't be used easily with 
PyObjc. That was around Christmas time (I don't get much time to spend 
on this stuff, so I'm on a slow learning schedule)

Cheers,

Paul

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

[Bob I. <bo...@re...>]

On Apr 5, 2004, at 4:53 PM, Paul Donovan wrote:

> I've been getting pyobjc from CVS over the last few days, and noticed 
> that the thread in my test app doesn't work any more. I copied the 
> thread code from the Web Services Tool example, so I checked that, and 
> it doesn't work either. In my case, the worker thread starts but never 
> finishes its task.
>
> Just guessing, but it seems that the recent checkins of fixes for DO 
> and NSProxy stuff have broken this.

I have no idea how to reasonably debug that example, it freely mixes 
ObjC and Python threading code.  It's not even correct for at least one 
reason: it doesn't detach an NSThread anywhere, so Foundation and Cocoa 
are not notified to be thread safeish.  Even though it did work 
previously, that might have been by accident.

What does your application actually do?  Chances are, there is a single 
threaded (as far as Python is concerned, at least) approach you can 
take that will have higher performance and be easier to debug.

-bob

[Pyobjc-dev] Web Services Tool example broken

[Paul D. <pa...@do...>]

I've been getting pyobjc from CVS over the last few days, and noticed 
that the thread in my test app doesn't work any more. I copied the 
thread code from the Web Services Tool example, so I checked that, and 
it doesn't work either. In my case, the worker thread starts but never 
finishes its task.

Just guessing, but it seems that the recent checkins of fixes for DO 
and NSProxy stuff have broken this.

Paul

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

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

On 5-apr-04, at 8:31, Bob Ippolito wrote:
>>
>> You get the same error with PyObjC. The only problem is that the 
>> bridge crashes before you see the exception :-(. The bridge crashes 
>> because it tries to -release an object that is not initialized, which 
>> causes serious errors for some classes (such as NSURL).
>
> Yeah, I tried to explain that.. it uses dealloc now, which seems to 
> work much better, especially for NSURL ;)

I'm checking in a version that leaks such objects, dealloc doesn't work 
with NSArray.

I've also added a unittest for this.

Ronald


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

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

[Bob I. <bo...@re...>]

On Apr 5, 2004, at 2:18 AM, Ronald Oussoren wrote:

>
> On 5-apr-04, at 7:31, b.bum wrote:
>
>> On Apr 4, 2004, at 9:31 PM, Bob Ippolito wrote:
>>> That's not the correct way of looking at it.  The problem is 
>>> precisely that it is sending the release message to an object that 
>>> is not prepared to receive it.  It actually does try and throw an 
>>> exception due to the incorrect selector, you just don't see it 
>>> because it does some garbage collection in the process and the world 
>>> ends before it gets a chance to let you know what went wrong.
>>
>> I disagree.
>>
>> Regardless of the state of the underlying object or the bridge 
>> between, the user is attempting to send a method to an object where 
>> that method does not exist.
>>
>> If I do the following from ObjC...
>>
>> 	    [[NSURL alloc] initWithString];
>>
>> ... the runtime responds with...
>>
>> 2004-04-04 22:28:02.775 asdfasdf[6043] *** -[NSURL initWithString]: 
>> selector not recognized
>> 2004-04-04 22:28:02.777 asdfasdf[6043] *** Uncaught exception: 
>> <NSInvalidArgumentException> *** -[NSURL initWithString]: selector 
>> not recognized
>
> You get the same error with PyObjC. The only problem is that the 
> bridge crashes before you see the exception :-(. The bridge crashes 
> because it tries to -release an object that is not initialized, which 
> causes serious errors for some classes (such as NSURL).

Yeah, I tried to explain that.. it uses dealloc now, which seems to 
work much better, especially for NSURL ;)

-bob

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

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

On 5-apr-04, at 7:31, b.bum wrote:

> On Apr 4, 2004, at 9:31 PM, Bob Ippolito wrote:
>> That's not the correct way of looking at it.  The problem is 
>> precisely that it is sending the release message to an object that is 
>> not prepared to receive it.  It actually does try and throw an 
>> exception due to the incorrect selector, you just don't see it 
>> because it does some garbage collection in the process and the world 
>> ends before it gets a chance to let you know what went wrong.
>
> I disagree.
>
> Regardless of the state of the underlying object or the bridge 
> between, the user is attempting to send a method to an object where 
> that method does not exist.
>
> If I do the following from ObjC...
>
> 	    [[NSURL alloc] initWithString];
>
> ... the runtime responds with...
>
> 2004-04-04 22:28:02.775 asdfasdf[6043] *** -[NSURL initWithString]: 
> selector not recognized
> 2004-04-04 22:28:02.777 asdfasdf[6043] *** Uncaught exception: 
> <NSInvalidArgumentException> *** -[NSURL initWithString]: selector not 
> recognized

You get the same error with PyObjC. The only problem is that the bridge 
crashes before you see the exception :-(. The bridge crashes because it 
tries to -release an object that is not initialized, which causes 
serious errors for some classes (such as NSURL).

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

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

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

On 5-apr-04, at 6:07, James Eagan wrote:
>
> MyAppController is a class that I've defined in python and is the 
> File's Owner in the nib that constructs the particular window at issue 
> here (I probably confused you with the code fragment above since the 
> fragment should use an instance, not the class).  That controller 
> specifies, among others, and outlet named window, which is connected 
> to the NSWindow instance in the nib.  Which is why I would have 
> thought that I'd use something like: 
> myAppControllerInstance.window.isMainWindow() just like I use in other 
> places myAppControllerInstance.textField.stringValue().  So why is 
> window suddenly a method?  (since 
> myAppControllerInstance.window().isMainWindow() works where I would 
> have expected an error)

What's the superclass of MyAppController? Does that have a method named 
'window'?

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

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

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

On 5-apr-04, at 6:05, b.bum wrote:

> On Apr 4, 2004, at 8:59 PM, Bob Ippolito wrote:
>> It's releasing something that was alloc'ed but not init'ed.  It 
>> probably should bus error.  I'm not sure how we are supposed to catch 
>> that anyway?  I guess we would have to keep track to see if it was 
>> alloc'ed but not initialized, and then send it dealloc instead of 
>> release.
>>
>> This gets a bus error too, btw:
>> #import <Foundation/Foundation.h>
>>
>> int main (int argc, char **argv) {
>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>     NSURL *url;
>>     url = [NSURL alloc];
>>     [url release];
>>     [pool release];
>> }
>
> That is a symptom of an earlier failure.    The fact the PyObjC is 
> attempting to send initWithString instead of initWithString: is the 
> root cause (or else initWithString: wouldn't work, would it?).
>
> Can we catch the attempt to invoke a method that does not exist?

We do that. As bob noted the problem is that we release an 
uninitialized object. I try to do the right thing when this happens, 
but that's obviously not good enough. It's probably better to just leak 
when this happens (and log/warn about this)

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

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

[b.bum <bb...@ma...>]

On Apr 4, 2004, at 9:31 PM, Bob Ippolito wrote:
> That's not the correct way of looking at it.  The problem is precisely 
> that it is sending the release message to an object that is not 
> prepared to receive it.  It actually does try and throw an exception 
> due to the incorrect selector, you just don't see it because it does 
> some garbage collection in the process and the world ends before it 
> gets a chance to let you know what went wrong.

I disagree.

Regardless of the state of the underlying object or the bridge between, 
the user is attempting to send a method to an object where that method 
does not exist.

If I do the following from ObjC...

	    [[NSURL alloc] initWithString];

... the runtime responds with...

2004-04-04 22:28:02.775 asdfasdf[6043] *** -[NSURL initWithString]: 
selector not recognized
2004-04-04 22:28:02.777 asdfasdf[6043] *** Uncaught exception: 
<NSInvalidArgumentException> *** -[NSURL initWithString]: selector not 
recognized

... as I would expect.   That PyObjC crashes in, effectively, the same 
situation without a useful warning message means that there is a bug in 
PyObjC.

And now it is fixed.  That rocks.  Thanks, Bob!    :-)

b.bum

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

[Bob I. <bo...@re...>]

On Apr 5, 2004, at 12:31 AM, Bob Ippolito wrote:

>
> On Apr 5, 2004, at 12:05 AM, b.bum wrote:
>
>> On Apr 4, 2004, at 8:59 PM, Bob Ippolito wrote:
>>> It's releasing something that was alloc'ed but not init'ed.  It 
>>> probably should bus error.  I'm not sure how we are supposed to 
>>> catch that anyway?  I guess we would have to keep track to see if it 
>>> was alloc'ed but not initialized, and then send it dealloc instead 
>>> of release.
>>>
>>> This gets a bus error too, btw:
>>> #import <Foundation/Foundation.h>
>>>
>>> int main (int argc, char **argv) {
>>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>>     NSURL *url;
>>>     url = [NSURL alloc];
>>>     [url release];
>>>     [pool release];
>>> }
>>
>> That is a symptom of an earlier failure.    The fact the PyObjC is 
>> attempting to send initWithString instead of initWithString: is the 
>> root cause (or else initWithString: wouldn't work, would it?).
>>
>> Can we catch the attempt to invoke a method that does not exist?
>
> That's not the correct way of looking at it.  The problem is precisely 
> that it is sending the release message to an object that is not 
> prepared to receive it.  It actually does try and throw an exception 
> due to the incorrect selector, you just don't see it because it does 
> some garbage collection in the process and the world ends before it 
> gets a chance to let you know what went wrong.
>
> >>> a = NSURL.alloc()
> >>> del a
> Bus error

I just fixed this in CVS..  apparently the code already knew about this 
situation (reaping an uninitialized object), it was just handling it 
incorrectly.

 >>> from Foundation import *
 >>> url = NSURL.alloc().initWithString(u'http://pyobjc.sf.net')
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
AttributeError: 'NSURL' object has no attribute 'initWithString'

-bob

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

[Bob I. <bo...@re...>]

On Apr 5, 2004, at 12:05 AM, b.bum wrote:

> On Apr 4, 2004, at 8:59 PM, Bob Ippolito wrote:
>> It's releasing something that was alloc'ed but not init'ed.  It 
>> probably should bus error.  I'm not sure how we are supposed to catch 
>> that anyway?  I guess we would have to keep track to see if it was 
>> alloc'ed but not initialized, and then send it dealloc instead of 
>> release.
>>
>> This gets a bus error too, btw:
>> #import <Foundation/Foundation.h>
>>
>> int main (int argc, char **argv) {
>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>     NSURL *url;
>>     url = [NSURL alloc];
>>     [url release];
>>     [pool release];
>> }
>
> That is a symptom of an earlier failure.    The fact the PyObjC is 
> attempting to send initWithString instead of initWithString: is the 
> root cause (or else initWithString: wouldn't work, would it?).
>
> Can we catch the attempt to invoke a method that does not exist?

That's not the correct way of looking at it.  The problem is precisely 
that it is sending the release message to an object that is not 
prepared to receive it.  It actually does try and throw an exception 
due to the incorrect selector, you just don't see it because it does 
some garbage collection in the process and the world ends before it 
gets a chance to let you know what went wrong.

 >>> a = NSURL.alloc()
 >>> del a
Bus error

-bob

[Pyobjc-dev] MacPython AIM channel is deprecated, moved to IRC

[Bob I. <bo...@re...>]

Due to the immense amount of problems with the AIM network and iChat, 
especially with regard to chat rooms, we've decided to move the to the 
#macpython channel on the irc.freenode.net IRC network.  This is 
primarily for pythonmac-sig and pyobjc-dev related discussions, but any 
MacPython related discussion is welcome.

For slightly more information, check the wiki: 
http://pythonmac.org/wiki/MacPythonChannel

If you do not currently have an IRC client, or are looking for a nice 
Cocoa client, try Colloquy: http://colloquy.info/

-bob

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

[James E. <ea...@ba...>]

On 4 Apr 2004, at 23:37, b.bum wrote:
> That should be:
>
> >>> from Foundation import *
> >>> u = NSURL.alloc().initWithString_('http://pyobjc.sf.net')

Ahhh, it's good to see that that was just a case of me being stupid 
(with more practice with pyobjc I expect that sort of thing will become 
blatantly obvious to me) ;-)

>> That error occurs when I call MyAppController.window.isMainWindow()  
>> where MyAppController.window is an IBOutlet of type NSWindow.
>
> Do you mean that 'window' is an outlet of type NSWindow?
>
> The error message indicates that whatever is found via the '.window' 
> is a method, not a reference to a window object.
>
> So, MyAppController.window().isMainWindow() might "just work", but I'm 
> still confused.   What is MyWindowController?   The naming implies 
> that it is a class of some kind...

Now I'm really confused.  I tried your trick of invoking 
MyAppController.window as a method instead of a variable and that seems 
to have worked.

MyAppController is a class that I've defined in python and is the 
File's Owner in the nib that constructs the particular window at issue 
here (I probably confused you with the code fragment above since the 
fragment should use an instance, not the class).  That controller 
specifies, among others, and outlet named window, which is connected to 
the NSWindow instance in the nib.  Which is why I would have thought 
that I'd use something like: 
myAppControllerInstance.window.isMainWindow() just like I use in other 
places myAppControllerInstance.textField.stringValue().  So why is 
window suddenly a method?  (since 
myAppControllerInstance.window().isMainWindow() works where I would 
have expected an error)

Thanks!
James

--
There is no spoo.

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

[b.bum <bb...@ma...>]

On Apr 4, 2004, at 8:59 PM, Bob Ippolito wrote:
> It's releasing something that was alloc'ed but not init'ed.  It 
> probably should bus error.  I'm not sure how we are supposed to catch 
> that anyway?  I guess we would have to keep track to see if it was 
> alloc'ed but not initialized, and then send it dealloc instead of 
> release.
>
> This gets a bus error too, btw:
> #import <Foundation/Foundation.h>
>
> int main (int argc, char **argv) {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>     NSURL *url;
>     url = [NSURL alloc];
>     [url release];
>     [pool release];
> }

That is a symptom of an earlier failure.    The fact the PyObjC is 
attempting to send initWithString instead of initWithString: is the 
root cause (or else initWithString: wouldn't work, would it?).

Can we catch the attempt to invoke a method that does not exist?

b.bum

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

[Bob I. <bo...@re...>]

On Apr 4, 2004, at 11:37 PM, b.bum wrote:

> On Apr 4, 2004, at 8:18 PM, James Eagan wrote:
>> I've been doing more with PyObjC lately, and I've been having a few 
>> weird issues creep up....  The first one's probably the easiest to 
>> demonstrate:
>>
>> Python 2.3 (#1, Sep 13 2003, 00:49:11)
>> [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> from Foundation import *
>> >>> u = NSURL.alloc().initWithString('http://pyobjc.sf.net')
>> Bus error
>> %
>
> That should be:
>
> >>> from Foundation import *
> >>> u = NSURL.alloc().initWithString_('http://pyobjc.sf.net')
>
> But the incorrect form shouldn't bus error, either...

It's releasing something that was alloc'ed but not init'ed.  It 
probably should bus error.  I'm not sure how we are supposed to catch 
that anyway?  I guess we would have to keep track to see if it was 
alloc'ed but not initialized, and then send it dealloc instead of 
release.

This gets a bus error too, btw:
#import <Foundation/Foundation.h>

int main (int argc, char **argv) {
     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
     NSURL *url;
     url = [NSURL alloc];
     [url release];
     [pool release];
}

In any case, you are far better off using 
NSURL.URLWithString_(u'http://pyobjc.sf.net/') .. in general I would 
recommend avoiding alloc/init from PyObjC in exchange for the 
autoreleased classmethod version, if for no other reason than 
aesthetics.  Surely the amount of code you have to type is proportional 
to the number of mistakes you can make :)

-bob

Re: [Pyobjc-dev] issues with NSURL and NSWindow?

[b.bum <bb...@ma...>]

On Apr 4, 2004, at 8:18 PM, James Eagan wrote:
> I've been doing more with PyObjC lately, and I've been having a few 
> weird issues creep up....  The first one's probably the easiest to 
> demonstrate:
>
> Python 2.3 (#1, Sep 13 2003, 00:49:11)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from Foundation import *
> >>> u = NSURL.alloc().initWithString('http://pyobjc.sf.net')
> Bus error
> %

That should be:

 >>> from Foundation import *
 >>> u = NSURL.alloc().initWithString_('http://pyobjc.sf.net')

But the incorrect form shouldn't bus error, either...

> Also, it appears that the NSWindow doesn't implement the -isKeyWindow 
> and -isMainWindow methods:  'objc.native_selector' object has no 
> attribute 'isMainWindow'
>
> That error occurs when I call MyAppController.window.isMainWindow()  
> where MyAppController.window is an IBOutlet of type NSWindow.

Do you mean that 'window' is an outlet of type NSWindow?

The error message indicates that whatever is found via the '.window' is 
a method, not a reference to a window object.

So, MyAppController.window().isMainWindow() might "just work", but I'm 
still confused.   What is MyWindowController?   The naming implies that 
it is a class of some kind...

b.bum

[Pyobjc-dev] issues with NSURL and NSWindow?

[James E. <ea...@ba...>]

I've been doing more with PyObjC lately, and I've been having a few 
weird issues creep up....  The first one's probably the easiest to 
demonstrate:

Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> u = NSURL.alloc().initWithString('http://pyobjc.sf.net')
Bus error
%

That's the behaviour that I get with PyObjC 1.0 and with the version 
checked out from CVS last night.

Am I just being stupid in how I'm using NSURL, or is that a bug?

Also, it appears that the NSWindow doesn't implement the -isKeyWindow 
and -isMainWindow methods:  'objc.native_selector' object has no 
attribute 'isMainWindow'

That error occurs when I call MyAppController.window.isMainWindow()  
where MyAppController.window is an IBOutlet of type NSWindow.

Any help would be greatly appreciated...

I love the work that you folks are doing!

Cheers,
James

--
I can't give you a brain, but I can give you a diploma.  -- The Wizard 
of Oz

Re: [Pyobjc-dev] GNUstep PyObjC compatibility

[Alex P. <ap...@st...>]

Ronald Oussoren wrote:

> I haven't checked the current CVS version, but several weeks ago the 
> core of PyObjC worked with GNUstep. The Foundation bindings were also 
> functional, but I didn't port the AppKit bindings.

Hm, doesn't seem to now.

>
> We've recently done some invasive surgery on the bridge to increase 
> its usefulness in multi-threaded environment. This might have broken 
> GNUstep support.

Probably :)

>
>>
>> I downloaded the CVS sources to PyObjC a day ago and attempted to get 
>> it to build, to no avail. Someone told me to look in 
>> Scripts/gen_all_protocols.py and it looks like there are some 
>> hardcoded paths in there.
>
>
> It should not be necessary to use gen_all_protocols.py just yet. This 
> might be required to add support for GNUstep-specific features, but 
> that can wait.
>
>> GNUstep system header files live in a slightly different place than 
>> they do on OS X. Foundation and AppKit headers are found in 
>> $GNUSTEP_SYSTEM_ROOT/Library/Headers/Foundation and 
>> $GNUSTEP_SYSTEM_ROOT/Library/Headers/AppKit, respectively. There are 
>> also some InterfaceBuilder (our IB-esque app is called GORM) in 
>> $GNUSTEP_SYSTEM_ROOT/Library/Headers/InterfaceBuilder. GNUstep also 
>> has a 100% API compatible AddressBook implementation, but it is not 
>> part of GNUstep proper, and as such may or may not be on any given 
>> machine. If it is, the headers would be in 
>> $GNUSTEP_LOCAL_ROOT/Library/Headers/AddressBook .
>>
>> For those of you who might be wondering, GNUstep lives in various 
>> places. I have it installed in / so my System folder is simply 
>> /System, local is /. Most distributions which package GNUstep put it 
>> in /usr/GNUstep or /usr/lib/GNUstep, which is why we must use system 
>> variables such as $GNUSTEP_SYSTEM_ROOT et al.
>
> My development box for the GNUstep box is a debian linux system 
> ("testing" release). I've also installed SimplyGNUstep on an old PC, 
> which has GNUSTEP_SYSTEM_ROOT=/System as well.

Okay, good. Never ever ever ever ever *ever* hardcode paths WRT GNUstep 
:) You can't be sure of where things actually live, but I'm sure you 
already know that, just stating it for the sake of the others here who 
may not.

>
> The first step to getting a full-featured GNUstep port of PyObjC is to 
> get the current port working again (e.g. core module + Foundation), 
> adding support for other frameworks should be easy enough.

Agreed.

> Now that I have the attention of a real GNUstep developer, I also have 
> a question: setup.py currently contains hard-coded CFLAGS and LDFLAGS 
> for GNUstep (see line 365 and on in setup.py), is there an easy way to 
> extract this information from the GNUstep build environment?

For the record, I'm not on the GNUstep developer team, but I am 
affiliated with them. I don't do much programming myself these days due 
to my hectic academic schedule, but I do help out where I can and when I 
have time. Lately, I've taken to "spreading the word" if you will, and 
that includes being proactive about things when people ask what the 
benefits of using GNUstep are. I just want to add yet another to the 
list :) My primary role is as GNUstep.org maintainer.

In any event, yes,  the -DGNU_RUNTIME=1, -fgnu-runtime, and -lobjc flags 
which are currently hardcoded in setup.py are set as RUNTIME_DEFINE, 
RUNTIME_FLAG, and OBJC_LIBS in the 
$GNUSTEP_SYSTEM_ROOT/Makefiles/library-combo.make file. This is not an 
executable shell script,  and is not set by default. Since GNUstep runs 
on a plethora of platforms, it uses its own make system typically, which 
is just pasted on top of GNU make. There are a number of  ifeq's in that 
file. The one that is by far the most common is the "ifeq 
($(OBJC_RUNTIME_LIB), gnu)" statement, in which the aforementioned 
variables are set. Additionally, in 
$GNUSTEP_SYSTEM_ROOT/Makefiles/Additional/base.make, there is a line, 
'AUXILIARY_OBJCFLAGS += -fconstant-string-class=NSConstantString' which 
sets the GCC constant string class flag. Finally, in 
$GNUSTEP_SYSTEM_ROOT/Makefiles/library-combo.make, there is a line which 
says "FOUNDATION_LIBRARY_DEFINE = -DGNUSTEP_BASE_LIBRARY=1" You should 
be able to parse what you need out of those files.

If you have any more questions or would like me to try anything out, let 
me know.

Cheers,
Alex Perez

Re: [Pyobjc-dev] GNUstep PyObjC compatibility

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

On 4-apr-04, at 2:11, Alex Perez wrote:

> Ronald et al,
>
> I lurk on the cocoa-dev mailing list, and recently saw a posting about 
> PyObjC. Someone in #macpython on FreeNode told me you'd done the bulk 
> (all?) of the work to make PyObjC work with GNUstep once upon a time. 
> I'm the GNUstep website maintainer (one of a couple of others), and am 
> putting together a page with a list of language bindings to 
> demonstrate how many languages you can use with GNUstep. I'd love to 
> help you resuscitate the GNUstep support in PyObjC and keep it 
> actively working.

I haven't checked the current CVS version, but several weeks ago the 
core of PyObjC worked with GNUstep. The Foundation bindings were also 
functional, but I didn't port the AppKit bindings.

We've recently done some invasive surgery on the bridge to increase its 
usefulness in multi-threaded environment. This might have broken 
GNUstep support.

>
> I downloaded the CVS sources to PyObjC a day ago and attempted to get 
> it to build, to no avail. Someone told me to look in 
> Scripts/gen_all_protocols.py and it looks like there are some 
> hardcoded paths in there.

It should not be necessary to use gen_all_protocols.py just yet. This 
might be required to add support for GNUstep-specific features, but 
that can wait.

> GNUstep system header files live in a slightly different place than 
> they do on OS X. Foundation and AppKit headers are found in 
> $GNUSTEP_SYSTEM_ROOT/Library/Headers/Foundation and 
> $GNUSTEP_SYSTEM_ROOT/Library/Headers/AppKit, respectively. There are 
> also some InterfaceBuilder (our IB-esque app is called GORM) in 
> $GNUSTEP_SYSTEM_ROOT/Library/Headers/InterfaceBuilder. GNUstep also 
> has a 100% API compatible AddressBook implementation, but it is not 
> part of GNUstep proper, and as such may or may not be on any given 
> machine. If it is, the headers would be in 
> $GNUSTEP_LOCAL_ROOT/Library/Headers/AddressBook .
>
> For those of you who might be wondering, GNUstep lives in various 
> places. I have it installed in / so my System folder is simply 
> /System, local is /. Most distributions which package GNUstep put it 
> in /usr/GNUstep or /usr/lib/GNUstep, which is why we must use system 
> variables such as $GNUSTEP_SYSTEM_ROOT et al.

My development box for the GNUstep box is a debian linux system 
("testing" release). I've also installed SimplyGNUstep on an old PC, 
which has GNUSTEP_SYSTEM_ROOT=/System as well.

The first step to getting a full-featured GNUstep port of PyObjC is to 
get the current port working again (e.g. core module + Foundation), 
adding support for other frameworks should be easy enough.

Now that I have the attention of a real GNUstep developer, I also have 
a question: setup.py currently contains hard-coded CFLAGS and LDFLAGS 
for GNUstep (see line 365 and on in setup.py), is there an easy way to 
extract this information from the GNUstep build environment?

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