pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Achieving 1.0....

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

[This is not a request to do a 1.0 release without an official interim 
release -- just some planning for the real live 1.0]

In the interests in achieving a 1.0 release, I thought I would take a 
very brief moment to toss out some ideas of what the project needs to 
get there.

---

First and foremost, we need a unit testing suite that provides complete 
coverage for the modules features.  As it stands, I keep stepping on 
Ronald's toes and he keeps stepping on mine -- once we work through the 
issues, the end result tends to work everywhere, but the interim is a 
pain for both of us.  This is largely because Ronald and I work against 
different builds of python [he uses a framework build of 2.3 alpha and 
I use the Apple supplied-- slightly incomplete-- build of 2.2] and work 
with a different set of examples largely to provide testing.

I would prefer to see a set of unit tests for each of the major modules 
that takes the form used by the rest of Python.   If I remember 
correctly, that had been changing over recent versions-- maybe so, 
maybe not.   I would also prefer to see the test suites ship with the 
binary distribution of the module (like Python, though Apple's build 
doesn't ship with the test suites).

---

Documentation:

     - need API documentation of the major functionality that isn't a 
part of the standard ObjC api.  (example:  the selector() function).   
A lot of this material exists.   Would be very good/cool if it were in 
pydoc compatible form.

     - need conceptual documentation.  Ronald started a user's guide 
that looks excellent -- need to flesh it out.

     - need example documentation;  fairly out of date -- mostly my 
examples. :-)

---

Examples:

     - need a general clean up and synchronization with underlying 
features (example:  web services tool currently does a bunch additional 
selector() definitions that are likely completely unnecessary)

     - remove examples that no longer work correctly or are rendered 
moot by unit testing

---

     Remove all references to True and False throughout codebase 
[assuming we are to continue supporting 2.2 throughout] -- or declare 
'em somewhere.

     Make sure the 2.2 support is appropriately isolated and documented 
[and doesn't affect 2.3+ support].

More as I think of it... I have to sleep now.

b.bum

[Pyobjc-dev] Bridging of foundation classes is a bit broken

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

It seems that the bridging of the various collection classes from 
Python to ObjC (or back, not sure) is broken in some fashion, at the 
moment.   I'm not sure exactly what is up.

Below is a transcript of interaction with the python interpreter under 
gdb.  Note that it doesn't not necessarily fail on a consistent number 
of executions of the allocator for NSMutableArray.   
NSMutableDictionary can cause the same crash.

One might point out that I really should be using Python collections 
and allowing the bridge to "automatically" convert the class into a 
compatible container on the other side.  That may be true, but this 
shouldn't cause the bridge to blow up entirely.

b.bum

[bumbox:~] 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 11162 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
 >>> from Foundation import *
Reading symbols for shared libraries .......................... done
Reading symbols for shared libraries . done
Reading symbols for shared libraries . done
 >>> a = NSMutableArray.alloc().init()
 >>> b = NSMutableArray.array()

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x907aba54 in objc_msgSend ()
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/bin/python
[Switching to process 11163 thread 0xf07]
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.
 >>> from Foundation import *
 >>> a = NSMutableArray.array()
 >>> b = NSMutableArray.array()
 >>> c = NSMutableArray.alloc().init()
 >>> d = NSMutableArray.alloc().init()

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x907aba64 in objc_msgSend ()
(gdb) bt
#0  0x907aba64 in objc_msgSend ()
#1  0x90948410 in -[NSInvocation setReturnValue:] ()
#2  0x9093033c in -[NSInvocation invoke] ()
#3  0x004654e8 in execute_and_pythonify_objc_method (aMeth=Cannot 
access memory at address 0x4e8
) at Modules/objc/objc_support.m:1352
#4  0x0046d760 in objcsel_call (self=0xc5e5f0, args=0x10b870) at 
Modules/objc/selector.m:402
#5  0x00045930 in PyObject_Call ()
#6  0x0005df64 in PyEval_GetFuncDesc ()
#7  0x0005b32c in PyEval_EvalCode ()
#8  0x0005c634 in PyEval_EvalCodeEx ()
#9  0x00058a80 in PyEval_EvalCode ()
#10 0x00027e90 in PyRun_FileExFlags ()
#11 0x00026c70 in PyRun_InteractiveOneFlags ()
#12 0x00026a58 in PyRun_InteractiveLoopFlags ()
#13 0x000268f0 in PyRun_AnyFileExFlags ()
#14 0x000069f0 in Py_Main ()
#15 0x00002970 in start ()
#16 0x000027f0 in start ()
(gdb)

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Michael J. B. <mj...@um...>]

On Wednesday, October 16, 2002, at 04:25  PM, Jack Jansen wrote:

> Something else that might be worthwhile is a helper command that 
> translates ObjC calls to Python. You would then copy [obj setObject: 
> value forKey: key], paste it in your Python script (where it will stay 
> selected) and select the "ObjC methodcall to Python" command to turn it 
> into obj.setObjectForKey(value, key). The only question is how we could 
> get this into Project Builder (into the Python IDE would be easy).

Sounds like a nice thing to do as a service or as a script. Getting it 
into Project Builder is then automatic.

Since I don't know how to write a service, I wrote a basic AppleScript 
for that. And I do mean basic: testing was minimal, nested method calls 
aren't handled correctly, and string arguments containing ":" will cause 
big problems. But, it's a starting point which someone might find 
useful, and doing it correctly would basically require a mini-parser for 
Objective-C, which there's no way I'm going to write in AppleScript! ;) 
Might be quite nice done in Python using Plex, though.

If anyone is interested in using it, copy the Objective C method call 
you want to convert, then run this script. The text will be converted to 
a Pythonic method call on the clipboard, which you can paste as usual. 
Be careful of spurious line breaks in the script when you first save it.

Here it is:

on run
	-- get an Objective C message from the clipboard
	set objcText to the clipboard
	if objcText starts with "[" and objcText ends with "]" then
		set objcText to items 2 through -2 of objcText as string
	end if
	
	set the tokens to split of the objcText at ":"
	set objectName to the first word of the first item of the tokens
	set methodName to {second word of the first item of the tokens}
	set methodArgs to {}
	
	repeat with tok in items 2 through -2 of tokens
		set namePiece to the last word of the tok
		copy namePiece to the end of the methodName
		copy (items 1 through -(1 + (length of namePiece)) of tok as 
string) to the end of methodArgs
	end repeat
	
	copy last item of tokens to the end of methodArgs
	
	--return {tokens, objectName, methodName, methodArgs}
	set the clipboard to objectName & "." & (join of methodName 
by "_") & "(" & (join of methodArgs by ",") & ")"
end run

on split of str at delim
	set oldTIDs to the text item delimiters of AppleScript
	set the text item delimiters of AppleScript to delim
	set tokens to the text items of the str
	set the text item delimiters of AppleScript to oldTIDs
	return the tokens
end split

on join of tokens by delim
	set oldTIDs to the text item delimiters of AppleScript
	set the text item delimiters of AppleScript to delim
	set str to the tokens as string
	set the text item delimiters of AppleScript to oldTIDs
	return the str
end join

Re: [Pyobjc-dev] DictType -> ObjC

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

On Thursday, Oct 17, 2002, at 22:58 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Thursday, October 17, 2002, at 04:32 PM, Jack Jansen wrote:
>> On donderdag, oktober 17, 2002, at 01:12 , Bill Bumgarner wrote:
>>>     How hard would it be to proxy DictType, ArrayType, and TupleType 
>>> into Obj-C such that they look/feel/act/behave/are subclasses of 
>>> NSDictionary and NSArray?
>>
>> Will these objects still be compatible with CoreFoundation? I'm not 
>> familiar enough with how Apple made CF and NS objects 
>> interchangeable, but if Pyobjc would handle most objects not by 
>> actually converting them but by putting them in something that merely 
>> "looks/feels/acts/behaves" like the real NS class that may not be 
>> good enough. I assume that "are" is good enough, but again I'm not 
>> sure.
>
> Yes -- it is simply a matter of implementing the appropriate primitive 
> methods for each class [for class clusters]:
[removed example]

Great. Actually adding these collection proxies is fairly trivial.

With a just commited version of python:
from Foundation import NSMutableArray

a = NSMutableArray.alloc().init()
a.addObject_(1)
a.addObject_({'hello':'world'})
a.addObject_([3, 4, 5])
print "The array:", type(a), a
print "a[0]:", type(a[0]), `a[0]`
print "a[1]:", type(a[1]), `a[1]`
print "a[2]:", type(a[2]), `a[2]`

Gives:

The array: <objective-c class NSCFArray at 0x30ed70> (1, {hello = 
world; }, (3, 4, 5))
a[0]: <objective-c class NSCFNumber at 0x2d7550> 1
a[1]: <type 'dict'> {'hello': 'world'}
a[2]: <type 'list'> [3, 4, 5]


Note that a[1] and a[2] are printed like NSDictionary and NSArray 
objects while in the NSMutableArray.

Ronald

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Thursday, October 17, 2002, at 10:42 , Bill Bumgarner wrote:
>> The current mechanism is a bit of a hack: the 'objc' module maintains 
>> a list of methods that are added if a selector is present in the 
>> objective-C class (e.g. if the class has 'objectForKey:' add an 
>> __getitem__ method that calls objectForKey_). This should work for 
>> most collection classes.
>
> This is actually a really good solution in that it greatly automates 
> the bridging process and should work transparently with the 'no cost' 
> bridged CFTypes.
>
> Anything that makes a copy of data as it is passed across the bridge 
> should generally be avoided -- strings are about the only exception.

Now that I think about it: why should strings be an exception? Could we 
not create an NSString subclass (along the same lines as your ideas on 
dictionaries and lists) that will wrap either a Python string or a 
Python unicode object? Actually, two wrappers (one for strings, one for 
unicode) may be easier, there's a lot of code that's going to be 
different depending on whether the underlying object is a string or 
unicode.
Hmm, actually we may want a whole family of wrappers so we can use 
Python strings to represent the whole string/data/url group.
--
- 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] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Thursday, Oct 17, 2002, at 22:42 Europe/Amsterdam, Bill Bumgarner 
wrote:

>
> NSNumber is definitely bridged from Python -> ObjC, but not the other 
> way around (this is what caused me to say that NSNumber wasn't 
> bridged)?
>
> >>> x = NSArray.arrayWithObject_(1)
> >>> x[0]
> <NSCFNumber objective-c instance 0xc1d0e0>
> >>> x.objectAtIndex_(0)
> <NSCFNumber objective-c instance 0xc1d0e0>

Automaticly conversion in one direction is not very pretty. I prefer to 
add automatic conversion from NSNumber to a Python type (but I'll have 
to check if this is possible without loss of information).

>
> >>> a.addObject_(1)
> >>> a.addObject_(1)
> >>> a[0]
> <NSCFNumber objective-c instance 0xca1510>
> >>> a[1]
> <NSCFNumber objective-c instance 0xc905b0>
> >>> a[0] == a[1]
> 0
This is a bug. a[0] implements isEqual:, this means we should 
automaticly add '__eq__' to the python proxy.
>
> But not always -- if the developer were to ever run into a case where 
> the (id) of a[0] and a[1] are significant, the transparent bridging of 
> the NSNumber->Python(int/float/long) would force the developer to go 
> to ObjC for something that is likely trivial to implement.
This might already be a problem for strings. There is quite a large 
number of string constants in Cocoa, and I don't know if the identity 
('pointer value') of them is significant.

> With all that said, I don't see any reason why NSNumber should not 
> provide implementations for at least __eq__ and __ne__ -- and maybe 
> even the full set??
These should be added, maybe including '__int__' for transparent 
conversion to a Python integer if the object is passed to an extension 
module.
>
> In any case, bridging types where the type is copied should generally 
> be avoided.  It can make it impossible to deal with certain situations 
> where the address of the object is meaningful, but the contents are 
> not.
I agree.

> It can also lead to some serious inefficiency if a trip across the 
> bridge implies a copy each time.
With small values the copy is not that inefficient (the overhead of the 
interpreter is probably much more significant)

>
> .... response continued below ....
>
>> The current mechanism is a bit of a hack: the 'objc' module maintains 
>> a list of methods that are added if a selector is present in the 
>> objective-C class (e.g. if the class has 'objectForKey:' add an 
>> __getitem__ method that calls objectForKey_). This should work for 
>> most collection classes.
>
> This is actually a really good solution in that it greatly automates 
> the bridging process and should work transparently with the 'no cost' 
> bridged CFTypes.

I definitly do not want to get rid automaticly adding methods, but it 
might be possible to replace the current implementation with a more 
flexible solution.

As I mentioned before I do not want to add more automatic conversions 
because:
1. The identity of objects may be significant
2. Conversion might be inefficient (especially for collections)
3. The Objective-C objects often have a larger interface than their 
Python counterparts, automatic conversion would make it impossible to 
use the additional functionality.

Ronald

Re: [Pyobjc-dev] DictType -> ObjC

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

On Thursday, October 17, 2002, at 04:32 PM, Jack Jansen wrote:
> On donderdag, oktober 17, 2002, at 01:12 , Bill Bumgarner wrote:
>>     How hard would it be to proxy DictType, ArrayType, and TupleType 
>> into Obj-C such that they look/feel/act/behave/are subclasses of 
>> NSDictionary and NSArray?
>>
>>     That is, such that they implement the primitive methods of the 
>> NSDictionary/NSArray class clusters and internally use the Py* APIs 
>> to retrieve/set values [converting as necessary]?
>>
>>     This would be significantly valuable in that it doesn't imply a 
>> conversion as the objects come across the bridge from Python->ObjC, 
>> yet they would be compatible with NSDictionary/NSArray and friends.
>
> Will these objects still be compatible with CoreFoundation? I'm not 
> familiar enough with how Apple made CF and NS objects interchangeable, 
> but if Pyobjc would handle most objects not by actually converting 
> them but by putting them in something that merely 
> "looks/feels/acts/behaves" like the real NS class that may not be good 
> enough. I assume that "are" is good enough, but again I'm not sure.

Yes -- it is simply a matter of implementing the appropriate primitive 
methods for each class [for class clusters]:

#import <Foundation/Foundation.h>
#import <CoreFoundation/CoreFoundation.h>

@interface FooArray:NSArray
id stuff[100];
@end
@implementation FooArray
- init
{
   [super init];
   int i;
   for(i = 0; i < 100; i++) stuff[i] = [[NSNumber numberWithInt: i] 
retain];
   return self;
}
- (id) objectAtIndex: (int) anIndex { return stuff[anIndex]; }
- (unsigned) count { return 100; }
@end

int main (int argc, const char * argv[]) {
   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   FooArray *fooArray = [[FooArray alloc] init];
   NSLog(@"objectAtIndex: 76 -- %@ - 0x%x",
		    [fooArray objectAtIndex: 76],
		    [fooArray objectAtIndex: 76]);
   CFArrayRef fooRef = (CFArrayRef) fooArray;
   NSLog(@"CFArrayGetValueAtIndex(..., 76) -- %@ - 0x%x",
		    CFArrayGetValueAtIndex(fooRef, 76),
		    CFArrayGetValueAtIndex(fooRef, 76));
   [pool release];
   return 0;
}

Outputs:

2002-10-17 16:54:06.121 arraytest[23625] objectAtIndex: 76 -- 76 - 
0x59a80
2002-10-17 16:54:06.122 arraytest[23625] CFArrayGetValueAtIndex(..., 
76) -- 76 - 0x59a80

The same can generally be said/done with any no-cost bridged object, 
just that it may require more methods to be implemented.

In any case, a PyArray subclass simply has to provide implementations 
of -objectAtIndex: and -count:.  All other methods in the NSArray API 
are implemented against those two primitive methods.   The CF "no cost" 
bridge is truly a "no cost" bridge -- it just calls the method IMPs 
directly (not sure how it looks 'em up).

The source to the CF<->NS 'no cost' bridge is in the Darwin CVS 
repository -- CFBase, I believe.

b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Thursday, October 17, 2002, at 04:18 PM, Ronald Oussoren wrote:
> On Thursday, Oct 17, 2002, at 20:29 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> On Thursday, October 17, 2002, at 02:01 PM, Bob Ippolito wrote:
>>> IMHO there should also be easy to use wrappers for NSNumber and 
>>> NSData.. I use those on a pretty regular basis for stuff that needs 
>>> to get serialized for DO or plists.
> I'd prefer not to special case Objective-C classes in the extension 
> module. We currently do so for NSString and NSNumber, and I'd prefer 
> to not add other exceptions.

NSNumber is definitely bridged from Python -> ObjC, but not the other 
way around (this is what caused me to say that NSNumber wasn't bridged)?

 >>> x = NSArray.arrayWithObject_(1)
 >>> x[0]
<NSCFNumber objective-c instance 0xc1d0e0>
 >>> x.objectAtIndex_(0)
<NSCFNumber objective-c instance 0xc1d0e0>

I'm not implying that I think the above behavior is incorrect -- I'm 
not really sure if I think it is or not.... In the following, it would 
seem that bridging would be the right thing to do:

 >>> a = NSMutableArray.array()
 >>> a.addObject_(1)
 >>> a.addObject_(1)
 >>> a[0]
<NSCFNumber objective-c instance 0xca1510>
 >>> a[1]
<NSCFNumber objective-c instance 0xc905b0>
 >>> a[0] == a[1]
0
 >>> a[0].isEqual_(a[1])
1

But not always -- if the developer were to ever run into a case where 
the (id) of a[0] and a[1] are significant, the transparent bridging of 
the NSNumber->Python(int/float/long) would force the developer to go to 
ObjC for something that is likely trivial to implement.

I remember running into this issue in the Java Bridge (and in the 
Tcl<->ObjC bridge I wrote in 1990/1991/1992).

With all that said, I don't see any reason why NSNumber should not 
provide implementations for at least __eq__ and __ne__ -- and maybe 
even the full set??

__lt__(a, b)
__le__(a, b)
__eq__(a, b)
__ne__(a, b)
__ge__(a, b)
__gt__(a, b)

In any case, bridging types where the type is copied should generally 
be avoided.  It can make it impossible to deal with certain situations 
where the address of the object is meaningful, but the contents are 
not.  It can also lead to some serious inefficiency if a trip across 
the bridge implies a copy each time.

.... response continued below ....

> The current mechanism is a bit of a hack: the 'objc' module maintains 
> a list of methods that are added if a selector is present in the 
> objective-C class (e.g. if the class has 'objectForKey:' add an 
> __getitem__ method that calls objectForKey_). This should work for 
> most collection classes.

This is actually a really good solution in that it greatly automates 
the bridging process and should work transparently with the 'no cost' 
bridged CFTypes.

Anything that makes a copy of data as it is passed across the bridge 
should generally be avoided -- strings are about the only exception.

Unlike the Java bridge, we have the distinct advantage of working with 
two relatively light weight, highly dynamic, languages on either side.  
Java really wants to be a closed box -- it really wants to tightly 
control everything passed into it and, as such, the bridge often had to 
copy and recreated data as it passed across (i.e. there was no way to 
wrap an NSMutableArray instance such that it was a subclass of Vector 
in any kind of an effective fashion).

Python's embedding API provides for a heck of a lot more informal 
flexibility...

b.bum

Re: [Pyobjc-dev] problems building editable tableviews

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

On Thursday, Oct 17, 2002, at 18:12 Europe/Amsterdam, Aaron Swartz 
wrote:

> Hi there,
>
> I've got a PyObjC app that has a table view working great, but as soon 
> as I add a definition for 
> tableView_setObjectValue_forTableColumn_row_, my app crashes as soon 
> as try to edit one of the rows and before my Python function gets 
> called. Here's the stacktrace:

Oops, you probably triggered a bug. Did you specify a signature for 
tableView_setObject*? (tableView_set* = selector(tableView_set*, 
signature="v@:@@@i"))

>
> Also, what's the policy on threading? I expect my app to do some 
> intense networking and indexing, and I don't want it to become 
> unresponsive while it's doing that. I tried importing "threading", but 
> when I tried to do something in another thread, it spewed out 
> thousands of no autoreleasepool -- leaking! messages.
>
Threading is not supported at the moment. If you create the thread 
using an Objective-C class (NSThread IIRC), the thread does not even 
have its own interpreter state (for the python interpreter); which will 
result in very interesting behaviour :-)

If you create the thread using the module 'thread' you might get 
working code if you create (and hang on to) an NSAutoreleasePool 
instance.

Ronald

Re: [Pyobjc-dev] DictType -> ObjC

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

On donderdag, oktober 17, 2002, at 01:12 , Bill Bumgarner wrote:

>     How hard would it be to proxy DictType, ArrayType, and 
> TupleType into Obj-C such that they look/feel/act/behave/are 
> subclasses of NSDictionary and NSArray?
>
>     That is, such that they implement the primitive methods of 
> the NSDictionary/NSArray class clusters and internally use the 
> Py* APIs to retrieve/set values [converting as necessary]?
>
>     This would be significantly valuable in that it doesn't 
> imply a conversion as the objects come across the bridge from 
> Python->ObjC, yet they would be compatible with 
> NSDictionary/NSArray and friends.

Will these objects still be compatible with CoreFoundation? I'm 
not familiar enough with how Apple made CF and NS objects 
interchangeable, but if Pyobjc would handle most objects not by 
actually converting them but by putting them in something that 
merely "looks/feels/acts/behaves" like the real NS class that 
may not be good enough. I assume that "are" is good enough, but 
again I'm not sure.
--
- 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] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Thursday, Oct 17, 2002, at 22:06 Europe/Amsterdam, Jack Jansen wrote:

>
> On donderdag, oktober 17, 2002, at 06:24 , Bill Bumgarner wrote:
>> Convenience wrappers are in the works.  Instead of wrapping, we are 
>> thinking of simply providing a subclass of NSDictionary and NSArray 
>> that can encapsulate DictType and Array/TupleTypes respectively.
The (Objective-C) class 'OC_PythonObject' already exposes the Python 
C-API to Objective-C. It would be easy to make the interface for 
collections more like the Foundation interfaces.

There is one thing that we should keep in mind: the documentation for 
Foundation mentions that most NS<Collection> classes are binary 
compatible with CF<Collection> types (Apple uses a fancy term like 
'zero-cost bridging', they mean you can cast an NS<Collection>* to a 
CF<Collection>* and back).

I've thought about adding a mechanism that automaticly converts 
Carbon.CF.CF<Collection> instances to Objective-C objects. This is 
pretty ease, but I do not have time to do this at the moment.

>> That way, Python arrays and dicts will behave like normal NSArray / 
>> NSDictionary instances on the ObjC side of the bridge.   (The other 
>> direction has already been bridged).
>
> I think we should again combine forces here.
<nod>

> At the moment we have two bridges that make the NS-objects or the 
> CoreFoundation alter-ego's available to Python, and half a bridge the 
> other way.

>
> The Carbon.CF module (a misnomer, it isn't Carbon-dependent, that'll 
> be fixed) exports most of CoreFoundation's objects to Python, but at 
> the moment it isn't complete in that you can't say obj[12] if obj as a 
> CFArray, i.e. it just exports method calls. It does have a nifty 
> toCF() method that takes any supported Python object (a recursive 
> combination of dict/list/string/scalar/CFObject) and returns its CF 
> equivalent, and each CFObject has a toPython() method that does the 
> reverse. And due to the way Carbon.CF works you hardly ever have to 
> call toCF(), usually if a conversion from a Python object is needed it 
> is done automatically.
Given the equivalence of lots of NS<X> classes with CF<X> types the 
toCF() function could easily be used to implement a toObjC() function.

>
> And in PyObjC we have support for using NS objects in a way that is 
> natural to Python, i.e. you can say obj[12] here. But when I last 
> looked PyObjC didn't handle all object types, and handled some in a 
> slightly funny way (strings, scalars). Note that "slightly funny" is 
> meant derogatory here, doing automatic conversion for these types is 
> often a good idea, but may come back to haunt us now that unicode is 
> more important, and now that a Python program may have obtained a 
> CFString object from another source.

The funny conversions grew up since the last time you looked at them: 
Unicode is handled correctly (I added this when I wanted to process 
keyboard events for function keys, those are unicode characters without 
an ASCII equivalent).

Ronald

[Pyobjc-dev] Bug in for x in y interaction w/NSDictionary

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

 >>> d = NSDictionary.dictionaryWithObject_forKey_("foo", "bar")
 >>> for k in d:
...     print k
...
None
None
None
.... repeat ad inifinitum ....

Of course, this works:

 >>> for k in d.keys():
...     print k
...
bar

b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Thursday, Oct 17, 2002, at 20:29 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Thursday, October 17, 2002, at 02:01 PM, Bob Ippolito wrote:
>> IMHO there should also be easy to use wrappers for NSNumber and 
>> NSData.. I use those on a pretty regular basis for stuff that needs 
>> to get serialized for DO or plists.
I'd prefer not to special case Objective-C classes in the extension 
module. We currently do so for NSString and NSNumber, and I'd prefer to 
not add other exceptions.

>
> Wrapping NSNumber and NSData is definitely on the radar, but there is 
> some subtlety in how they need to be wrapped.   I totally agree that 
> they should be wrapped in some fashion.
>
> On the ObjC->Python front, do you mean:
>
> [bumbox:~] bbum% python
> 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.
> >>> from Foundation import *
> >>> a = NSMutableArray.array()
> >>> d = NSMutableDictionary.dictionary()
> >>> a.addObject_("a")
> >>> a[0]
> 'a'
> >>> d['foo'] = 'bar'
> >>> d['baz'] = 'bob'
> >>> d.keys()
> ['baz', 'foo']
> >>> d.description()
> '{baz = bob; foo = bar; }'
> >>> d.objectForKey_('baz')
> 'bob'
> >>> d['baz']
> 'bob'
>
> Already in there -- just not quite complete.

The current mechanism is a bit of a hack: the 'objc' module maintains a 
list of methods that are added if a selector is present in the 
objective-C class (e.g. if the class has 'objectForKey:' add an 
__getitem__ method that calls objectForKey_). This should work for most 
collection classes.

>
>> Does pyobjc do garbage collection?  I'd imagine that you could have 
>> the __init__ for anything to a retain and the __del__ for anything do 
>> a release without getting in the way..

Pyobjc tries very hard to maintain correct retainCounts on the 
Objective-C object. In general it should not be necessary to think 
about this.

Please tell the list if you do have to call 'retain' or 'release', upto 
now I've been able to find a generic solution for every instance where 
I had to take care of retainCounts in Python code.

Ronald

Re: [Pyobjc-dev] How to do isKindOfClass:? (and a bug fix)

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

Doesn't appear to work either -- likely because we both reversed the 
arguments... :-)

 >>> isinstance(d, NSDictionary)
1

(This was what I was originally going to send)

[bumbox:V3/OSX-Desktop/Intent] bbum% python
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.
 >>> from Foundation import *
 >>> d = NSMutableDictionary.dictionary()
 >>> d
<NSCFDictionary objective-c instance 0x161ae0>
 >>> isinstance(NSDictionary, d)
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: isinstance() arg 2 must be a class or type
 >>> isinstance(NSDictionary, type(d))
0
 >>> isinstance(NSDictionary, d.__class__)
0
 >>> d
<NSCFDictionary objective-c instance 0x161ae0>

thanks!

On Thursday, October 17, 2002, at 04:45 AM, Ronald Oussoren wrote:

> You can do 'isinstance(NSDictionary, mD)'.
>
> I'd expect that isKindOfClass: also works, I'll look into why it 
> doesn't.
>
> Ronald

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On donderdag, oktober 17, 2002, at 06:24 , Bill Bumgarner wrote:
> Convenience wrappers are in the works.  Instead of wrapping, we 
> are thinking of simply providing a subclass of NSDictionary and 
> NSArray that can encapsulate DictType and Array/TupleTypes 
> respectively.   That way, Python arrays and dicts will behave 
> like normal NSArray / NSDictionary instances on the ObjC side 
> of the bridge.   (The other direction has already been bridged).

I think we should again combine forces here. At the moment we 
have two bridges that make the NS-objects or the CoreFoundation 
alter-ego's available to Python, and half a bridge the other way.

The Carbon.CF module (a misnomer, it isn't Carbon-dependent, 
that'll be fixed) exports most of CoreFoundation's objects to 
Python, but at the moment it isn't complete in that you can't 
say obj[12] if obj as a CFArray, i.e. it just exports method 
calls. It does have a nifty toCF() method that takes any 
supported Python object (a recursive combination of 
dict/list/string/scalar/CFObject) and returns its CF equivalent, 
and each CFObject has a toPython() method that does the reverse. 
And due to the way Carbon.CF works you hardly ever have to call 
toCF(), usually if a conversion from a Python object is needed 
it is done automatically.

Most of this module is automatically generated, so as Apple 
comes up with more CF objects, or these objects grow new 
methods, that'll be automatically incorporated.

And in PyObjC we have support for using NS objects in a way that 
is natural to Python, i.e. you can say obj[12] here. But when I 
last looked PyObjC didn't handle all object types, and handled 
some in a slightly funny way (strings, scalars). Note that 
"slightly funny" is meant derogatory here, doing automatic 
conversion for these types is often a good idea, but may come 
back to haunt us now that unicode is more important, and now 
that a Python program may have obtained a CFString object from 
another source.
--
- 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] How to do isKindOfClass:? (and a bug fix)

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

You can do 'isinstance(NSDictionary, mD)'.

I'd expect that isKindOfClass: also works, I'll look into why it 
doesn't.

Ronald

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Thursday, October 17, 2002, at 02:01 PM, Bob Ippolito wrote:
> IMHO there should also be easy to use wrappers for NSNumber and 
> NSData.. I use those on a pretty regular basis for stuff that needs to 
> get serialized for DO or plists.  Another extremely convenient idea 
> would be to just make special cases for some of the most used 
> Foundation classes such as NS[Mutable]Array, NS[Mutable]Dictionary and 
> NSEnumerator so that you can treat them like native python objects.  
> Possibly even NS[Mutable]String and so on.  Probably wouldn't even 
> take too long to develop, especially if it's done (at least at first) 
> from the python end of the stick and not in ObjC.

Wrapping NSNumber and NSData is definitely on the radar, but there is 
some subtlety in how they need to be wrapped.   I totally agree that 
they should be wrapped in some fashion.

On the ObjC->Python front, do you mean:

[bumbox:~] bbum% python
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.
 >>> from Foundation import *
 >>> a = NSMutableArray.array()
 >>> d = NSMutableDictionary.dictionary()
 >>> a.addObject_("a")
 >>> a[0]
'a'
 >>> d['foo'] = 'bar'
 >>> d['baz'] = 'bob'
 >>> d.keys()
['baz', 'foo']
 >>> d.description()
'{baz = bob; foo = bar; }'
 >>> d.objectForKey_('baz')
'bob'
 >>> d['baz']
'bob'

Already in there -- just not quite complete.

> Does pyobjc do garbage collection?  I'd imagine that you could have 
> the __init__ for anything to a retain and the __del__ for anything do 
> a release without getting in the way..

Generally, you don't have to think about it (at least I haven't been 
and my apps aren't crashing -- they may be leaking like a sieve, though 
:-).  An assignment implies a -retain and destruction of the reference 
implies a -release.

It isn't all there yet, but I think we are fairly far down the correct 
path -- certainly far enough to write full featured apps with a minimum 
of pain.

BTW:  I also added this utility function to Foundation:

propertyListFromPythonCollection()

Which does this (in one of the examples in the pyobjc source):

Converting (Python Collection):
{'a': [1, 2, 3, 4],
  'b': 'c',
  'd': 3,
  'e': None,
  'f': [1, {'a': 'b', 2: 3}, [3, 4]],
  'g': {'h': 'i'},
  'j': (1, 2, 3, 'k', 'l')}


Converted (ObjC collection):
{
     a = (1, 2, 3, 4);
     b = c;
     d = 3;
     e = <null>;
     f = (1, {a = b; 2 = 3; }, (3, 4));
     g = {h = i; };
     j = (1, 2, 3, k, l);
}

b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Thursday, Oct 17, 2002, at 12:24 America/New_York, Bill Bumgarner 
wrote:

>
> Convenience wrappers are in the works.  Instead of wrapping, we are 
> thinking of simply providing a subclass of NSDictionary and NSArray 
> that can encapsulate DictType and Array/TupleTypes respectively.   
> That way, Python arrays and dicts will behave like normal NSArray / 
> NSDictionary instances on the ObjC side of the bridge.   (The other 
> direction has already been bridged).
>

IMHO there should also be easy to use wrappers for NSNumber and 
NSData.. I use those on a pretty regular basis for stuff that needs to 
get serialized for DO or plists.  Another extremely convenient idea 
would be to just make special cases for some of the most used 
Foundation classes such as NS[Mutable]Array, NS[Mutable]Dictionary and 
NSEnumerator so that you can treat them like native python objects.  
Possibly even NS[Mutable]String and so on.  Probably wouldn't even take 
too long to develop, especially if it's done (at least at first) from 
the python end of the stick and not in ObjC.

Does pyobjc do garbage collection?  I'd imagine that you could have the 
__init__ for anything to a retain and the __del__ for anything do a 
release without getting in the way..

-bob

Re: [Pyobjc-dev] problems building editable tableviews

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

On Thursday, October 17, 2002, at 12:12 PM, Aaron Swartz wrote:
> Hi there,
>
> I've got a PyObjC app that has a table view working great, but as soon 
> as I add a definition for 
> tableView_setObjectValue_forTableColumn_row_, my app crashes as soon 
> as try to edit one of the rows and before my Python function gets 
> called. Here's the stacktrace:

Did you declare the selector signature for that method?

I.e. after you declare the function on your Python object, add this:

         tableView_setObjectValue_forTableColumn_row_ = 
objc.selector(tableView_setObjectValue_forTableColumn_row_, 
signature='v@:@@@i')

Annoyingly confusing, I know.  We are working out how to make this 
easier.  The basic problem is that you need to tell the Obj-C runtime 
about the types accepted by the method.  In this case, v@:@@@i means -- 
returns void, has arguments of type (id self), (SEL _cmd), id, id, id, 
int.

I'd be willing to bet you were editing row 4 (or maybe 1)?

That objc_msgSend() died is likely because it tried to treat the int 
argument as an object of type (id) -- the method dispatch code in 
Python tried to send it a message to figure out if it needed to convert 
it as it passes across the bridge.

>
> Date/Time:  2002-10-17 10:40:30 -0500
> OS Version: 10.2.1 (Build 6D52)
> Host:       slithy.local.
>
> Command:    Memesh
> PID:        10833
>
> Exception:  EXC_BAD_ACCESS (0x0001)
> Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000004
>
> Thread 0 Crashed:
>  #0   0x9068ba4c in objc_msgSend
>  #1   0x00508694 in pythonify_c_value (objc_support.m:566)
>  #2   0x00574598 in meth_imp_211 (register.m:18542)
>  #3   0x932d744c in -[NSTableView textDidEndEditing:]
> .....


> Thanks for any help you can provide.

Hopefully, that'll "just work".

> Also, what's the policy on threading? I expect my app to do some 
> intense networking and indexing, and I don't want it to become 
> unresponsive while it's doing that. I tried importing "threading", but 
> when I tried to do something in another thread, it spewed out 
> thousands of no autoreleasepool -- leaking! messages.

I haven't looked -- Ronald?

But the problem you describe is because the threads don't have an 
NSAutoreleasePool when they are created, but you are causing Obj-C 
activity in that thread and, as a result, are causing objects to be 
created and autoreleased.  When autoreleased, but no pool has been 
created, you'll see this error.

(Try creating a default Foundation tool object, open the main, delete 
the lines referring to the autorelease pool and do: NSLog(@"%@ %@", 
@"Hello, World!", [NSCalendarDate date]); and you'll see the same 
messages.)

So -- when the thread is created, create an autorelease pool for that 
thread.  From the thread, just alloc/init a new autorelease pool.

As long as the thread is pure python, you shouldn't see this message.

>
> Thanks again for such an awesome tool!

Your welcome -- it makes me very happy to know that people are actually 
using it!

b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Thursday, October 17, 2002, at 12:00 PM, 
pyt...@py... wrote:
> I'll never 'win' this discussion, as if that is meaningful, but the
> syntax serves another purpose.  The main reason I like it is because I
> don't like calling conventions that list parameter names and values in
> separate places.

Agreed on conventions -- I like ObjC's and SmallTalk's calling 
conventions much better for exactly the reason you describe.

Minor correction:  There are no named parameters in Objective-C.   The 
method "setObject:forKey:" is named "setObject:forKey:" -- not 
"setObject: that takes an argument called forKey:".

> With the underscore convention, you have essentially
> (pseudocode):
>
> call((a,b,c), (1,2,3))
>
> when the *meaning* is
>
> call(a=1, b=2, c=3).

The underscore convention turns...

     [aDict setObject: foo forKey: @"bar"]

... into ...

     aDict.setObject_forKey_(foo, "bar")

That's it.   Given that there aren't named parameters, I'm not sure 
what the above statement is intending to mean.

> But I'm definitely not the target audience for pyobjc, so I would 
> ignore
> all of my comments at this point.  I love Python and I love
> Objective-C.  I see no reason to write GUI Cocoa code in Python when
> Objective-C does it perfectly and the GUI api was meant for use with
> Objective-C.

Four big reasons to use Python:

     - rapid development:  With Python in the mix, I can reduce the 
compile-run part of the edit-compile-run to almost non-existent (as 
soon as I get class reloading working -- haven't had time to go there). 
   In my experience, it has *vastly* improved my productivity.

     - access to tools:  The Python world has an awesome-- both quantity 
and range-- variety of tools and libraries available that may not be 
available directly in ObjC.   By using PyObjC, I can write my UI 
widgets in ObjC, glue 'em together using a mix of Python and ObjC, and 
leverage whatever tools I need from the Python world.

     - efficiency of implementation:   There are certain tasks that 
Python is incredibly well suited for;  writing command line tools 
(getopt, modularity, etc...) and implementing/using network protocols, 
to name two examples.  Concrete example:  By switching from the 
WebServices API provided by Apple to the xmlrpclib provided in Python, 
I was able to reduce the number of lines of code in the network client 
portion of my Cocoa app by roughly 70% (well over several hundred lines 
of code).   At the same time, I gain....

     - portability: While the Cocoa specific bits of my app are not 
portable, my entire communication layer is.  Since my app is a client 
on top of a remote server and I also needed to create a command line 
client for the purposes of testing and automation.... and I needed to 
support many platforms on everything but the GUI specific bits, I chose 
to implement my client library in Python.   It is 100% portable-- runs 
everywhere-- including in my ObjC/Cocoa OS X specific GUI application.l 
   Not only did I eliminate 70% of the client side ObjC code in my Cocoa 
app, but I also reduced my code duplication -- I only have to write 
*one* client package.

> I thus think it would be far more useful to have a simple way to link 
> an
> Objective-C nib-based GUI controlled by a Python backend, with
> convenience wrappers to convert complex library types like dictionaries
> and mutable arrays.

I believe most of this is already done.  I certainly have a complex 
ObjC app using a python backend/client-library to talk to the server 
and control the UI -- it is up and running now and works very well!

Convenience wrappers are in the works.  Instead of wrapping, we are 
thinking of simply providing a subclass of NSDictionary and NSArray 
that can encapsulate DictType and Array/TupleTypes respectively.   That 
way, Python arrays and dicts will behave like normal NSArray / 
NSDictionary instances on the ObjC side of the bridge.   (The other 
direction has already been bridged).

b.bum

[Pyobjc-dev] problems building editable tableviews

[Aaron S. <me...@aa...>]

Hi there,

I've got a PyObjC app that has a table view working great, but as soon 
as I add a definition for tableView_setObjectValue_forTableColumn_row_, 
my app crashes as soon as try to edit one of the rows and before my 
Python function gets called. Here's the stacktrace:

Date/Time:  2002-10-17 10:40:30 -0500
OS Version: 10.2.1 (Build 6D52)
Host:       slithy.local.

Command:    Memesh
PID:        10833

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000004

Thread 0 Crashed:
  #0   0x9068ba4c in objc_msgSend
  #1   0x00508694 in pythonify_c_value (objc_support.m:566)
  #2   0x00574598 in meth_imp_211 (register.m:18542)
  #3   0x932d744c in -[NSTableView textDidEndEditing:]
  #4   0x907eaf7c in _nsNotificationCenterCallBack
  #5   0x90168b18 in _postNotification
  #6   0x90166238 in _CFNotificationCenterPostLocalNotification
  #7   0x9331519c in -[NSTextView(NSPrivate) _giveUpFirstResponder:]
  #8   0x932f7a98 in -[NSTextView doCommandBySelector:]
  #9   0x931d83f8 in 
-[NSKeyBindingManager(NSKeyBindingManager_MultiClients) 
interpretEventAsCommand:forClient:]
  #10  0x931ce84c in -[NSTSMInputContext interpretKeyEvents:]
  #11  0x93360a08 in -[NSView interpretKeyEvents:]
  #12  0x93301e08 in -[NSTextView keyDown:]
  #13  0x9336e63c in -[NSWindow sendEvent:]
  #14  0x930ce328 in -[NSApplication sendEvent:]
  #15  0x01ae78e0 in -[NSApplication(CocoaGestures) 
cocoaGesturesSendEvent:] (CocoaGestures.m:201)
  #16  0x930ca524 in -[NSApplication run]
  #17  0x930d2598 in NSApplicationMain
  #18  0x00002b14 in pyobjc_main (main.m:39)
  #19  0x00002b58 in main (main.m:44)
  #20  0x00002560 in _start (crt.c:267)
  #21  0x000023e0 in start

Thread 1:
  #0   0x90074328 in mach_msg_trap
  #1   0x90006670 in mach_msg
  #2   0xc00076cc in __ape_internal
  #3   0xc0000dd0 in __ape_agent
  #4   0x90021428 in _pthread_body

PPC Thread State:
   srr0: 0x9068ba4c srr1: 0x0200f030                vrsave: 0x00000000
    xer: 0x00000000   lr: 0x00508694  ctr: 0x9068ba3c   mq: 0x00000000
     r0: 0x00508694   r1: 0xbfffe640   r2: 0x0007ca10   r3: 0x00000004
     r4: 0x906aca0c   r5: 0x0063aa78   r6: 0x00000011   r7: 0x00000002
     r8: 0x00000002   r9: 0x0063a3e4  r10: 0x00000009  r11: 0x00638cd0
    r12: 0x9068ba3c  r13: 0xa3097d70  r14: 0x00b3e0f0  r15: 0x00000001
    r16: 0x01c44820  r17: 0x00000000  r18: 0x00000002  r19: 0x00000000
    r20: 0x00c2f7a0  r21: 0x6f7dbe5f  r22: 0xa3075a5c  r23: 0xbfffecc0
    r24: 0xa3075a5c  r25: 0x00c2f7a0  r26: 0x00000010  r27: 0x906dcf88
    r28: 0x00c2f7a0  r29: 0x00bab0f0  r30: 0xbfffe640  r31: 0x0050836c

Thanks for any help you can provide.

Also, what's the policy on threading? I expect my app to do some 
intense networking and indexing, and I don't want it to become 
unresponsive while it's doing that. I tried importing "threading", but 
when I tried to do something in another thread, it spewed out thousands 
of no autoreleasepool -- leaking! messages.

Thanks again for such an awesome tool!
-- 
Aaron Swartz [http://www.aaronsw.com] "Curb your consumption," he said.

[Pyobjc-dev] Bug fix in exception bridging code

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

The whole exercise with figuring out how to use gdb w/my app (that is 
composed of multiple frameworks that are dynaloaded) was to track down 
a bug in bridge.  Specifically, the bridge was crashing if I tried to 
invoke a selector on an Python subclass of an ObjC object where neither 
the ObjC or Python subclass implemented the method (I'm in the middle 
of porting code from ObjC to Python [and not just as a mental exercise] 
and haven't finished implementing all methods) -- the classic forward:: 
/ does not recognize selector situation.

According to the documentation, the PyErr_Fetch() function can return 
NULL for the exc_value and exc_traceback arguments.  This appears to be 
exactly what is happening -- see the gdb session below -- in that 
exc_traceback is NULL.   Calling Py_DECREF() with a NULL pointer causes 
a bus error / bad access error.

Patched.  Fixed.  Committed.  Ronald:  Is it correct? :-)

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x004168c8 in ObjCErr_ToObjC () at Modules/objc/objc_util.m:222
222             Py_DECREF(exc_traceback);
(gdb) l
217                     userInfo:userInfo];
218
219             Py_DECREF(repr);
220             Py_DECREF(exc_type);
221             Py_DECREF(exc_value);
222             Py_DECREF(exc_traceback);
223
224             [val raise];
225     }
226
Current language:  auto; currently objective-c
(gdb) bt
#0  0x004168c8 in ObjCErr_ToObjC () at Modules/objc/objc_util.m:222
#1  0x0041caf0 in object_method_methodSignatureForSelector 
(self=0x1ee6d50, selector=0x907e2470, aSelector=0xdd32bc) at 
Modules/objc/class-builder.m:869
#2  0x90935664 in -[NSObject(NSForwardInvocation) forward::] ()
#3  0x907ac130 in _objc_msgForward ()
#4  0x00dcf8d4 in -[ViewTableDataSource issueUrlButtonAction:] 
(self=0x6c8b80, _cmd=0xdd2bf8, sender=0xe60b20) at 
Intent-Application/ViewTableDataSource.m:468
#5  0x9426fe2c in -[NSApplication sendAction:to:from:] ()
#6  0x942fbff0 in -[NSControl sendAction:to:] ()
#7  0x942b3a38 in -[NSCell _sendActionFrom:] ()
#8  0x942b3fc4 in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] ()
#9  0x9429ef78 in -[NSButtonCell 
trackMouse:inRect:ofView:untilMouseUp:] ()
#10 0x944763b0 in -[NSTableView mouseDown:] ()
#11 0x9450dfd4 in -[NSWindow sendEvent:] ()
#12 0x9426e328 in -[NSApplication sendEvent:] ()
#13 0x9426a524 in -[NSApplication run] ()
#14 0x94272598 in NSApplicationMain ()
#15 0x00c23f40 in objc_NSApplicationMain (self=0x229d2c0, 
args=0x907c85c8, kwds=0x0) at Modules/Cocoa/_AppKit.m:80
#16 0x00045930 in PyObject_Call ()
#17 0x0005df64 in PyEval_GetFuncDesc ()
#18 0x0005b1f8 in PyEval_EvalCode ()
#19 0x0005c634 in PyEval_EvalCodeEx ()
#20 0x00058a80 in PyEval_EvalCode ()
#21 0x00027e90 in PyRun_FileExFlags ()
#22 0x00026ef4 in PyRun_SimpleFileExFlags ()
#23 0x000069f0 in Py_Main ()
#24 0x00002970 in start ()
#25 0x000027f0 in start ()
(gdb) p exc_traceback
$1 = (PyObject *) 0x0
(gdb)
(gdb) p exc_value
$2 = (PyObject *) 0x1ec6fe0

[Pyobjc-dev] Better way to use gdb.

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

Paste this into the main file just before the call to execve().

   if ([[[NSProcessInfo processInfo] environment] objectForKey: 
@"SHOWPID"])
     NSLog(@"Process ID is: %d (\n\tgdb %s %d\n to debug)", getpid(), 
pythonBinPathPtr, getpid());

Then, set the SHOWPID environment variable to some random value.

Upon launch, the app will spew something like:

2002-10-17 09:48:46.366 Intent[14992] Process ID is: 14992 (
	gdb /usr/bin/python 14992
  to debug)

Copy/paste the command line (middle line) into Terminal.

You can also add a custom executable to the PBX project -- set the 
executable to /usr/bin/python.  You also have to write the following 
default to cause Project Builder's gdb module to not autolaunch the 
target executable on launch (or else you'll end up debugging the 
generic Python interpreter!).

     defaults write com.apple.ProjectBuilder PBXDebuggerAutoRun NO

Once the app is launched and spews the output shown, you can type 
'attach 14992' (or whatever the PID is) to attach gdb to the 
appropriate process.   When gdb attaches to the process, it'll 
automatically load any shlibs and other symbol tables.   It will also 
stop the process -- use the continue command to continue the execution 
of the inferior process.

b.bum

Re: [Pyobjc-dev] Any trick to building and running (debugging) Web Services Tool?

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

An abstract answer was posted last night, but here is the recipe:

Use the -e flag to gdb to specify the executable from which it'll take 
symbols:

gdb -e /usr/bin/python Web\ Services\ Tool.app/Contents/MacOS/Web\ 
Services\ Tool.app

(From the terminal while cd'd into the directory that contains the 
build app product).

When it runs, gdb will break when it passes control from the bootstrap 
app into the python.  Just type 'c' and hit return to continue.

After that point, you *should* be up and running with the appropriate 
set of symbols.

If frameworks are involved in your project, there may be some other 
issues involved -- namely, you might have to set up one of the DYLD 
environment variables (see the dyld man page).

b.bum

On Thursday, October 17, 2002, at 03:17 AM, Joseph Grace wrote:

> Hi:
>
> I can run the shipped tool fine, but when I try to build it and run 
> the result (debugging actually) in ProjectBuilder, I get the following 
> from the debugger console:
> -=-
> run
> tty /dev/ttyp2
> [Switching to process 11253 thread 0xb03]
> warning: ppc_frame_chain_valid: stack pointer from 0xbffffc08 to 
> 0x1000 grows upward; assuming invalid
>
> warning: ppc_frame_chain_valid: stack pointer from 0xbffffc08 to 
> 0x1000 grows upward; assuming invalid
>
> warning: ppc_frame_chain_valid: stack pointer from 0xbffffc08 to 
> 0x1000 grows upward; assuming invalid
>
> (gdb)
> -=-
>
> Also:
>
> 'Program received signal: "SIGTRAP".'
>
> And:
>
> 'Error from Debugger: mi_cmd_stack_list_frames: Not enough frames in 
> stack.'
>
> I've done the setup.py, and I'm not sure what I'm missing to be able 
> to build and run a workable version of the WST example pyobj example 
> app.
>
> Tips, pointers, suggestions appreciated!
>
> Thanks,
>
> = Joe =
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
b.bum
Do the voices in my head bother you?

[Pyobjc-dev] Any trick to building and running (debugging) Web Services Tool?

[Joseph G. <oc...@se...>]

Hi:

I can run the shipped tool fine, but when I try to build it and run the 
result (debugging actually) in ProjectBuilder, I get the following from 
the debugger console:
-=-
run
tty /dev/ttyp2
[Switching to process 11253 thread 0xb03]
warning: ppc_frame_chain_valid: stack pointer from 0xbffffc08 to 0x1000 
grows upward; assuming invalid

warning: ppc_frame_chain_valid: stack pointer from 0xbffffc08 to 0x1000 
grows upward; assuming invalid

warning: ppc_frame_chain_valid: stack pointer from 0xbffffc08 to 0x1000 
grows upward; assuming invalid

(gdb)
-=-

Also:

'Program received signal: "SIGTRAP".'

And:

'Error from Debugger: mi_cmd_stack_list_frames: Not enough frames in 
stack.'

I've done the setup.py, and I'm not sure what I'm missing to be able to 
build and run a workable version of the WST example pyobj example app.

Tips, pointers, suggestions appreciated!

Thanks,

= Joe =