pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] IB question

[Etienne P. <ep...@ep...>]

On Monday, Feb 3, 2003, at 02:47 Europe/Amsterdam, Michael Engelhart 
wrote:
> I then went into Interface BUilder and added a sayGoodbyeAction: 
> action to the class and instantiated it and wired up the buttons, text 
> field and delegate.  WHen I rebuild the application, the button I  
> added to the sample window doesn't work yet the button that comes with 
> the template does work.   Well that's not true, sometimes my added 
> button/method combination works, sometimes it doesn't.  I've triple 
> checked that everything is wired up correctly and it still doesn't 
> function.  At one point I thought I had some bizarre spacing issue so 
> I copied the sayHelloAction method and pasted it and changed the 
> method body and method name and then it worked.  then I tried adding 
> another method and everything stopped working.

You mention that you added sayGoodbyeAction: to the class and 
instantiated it - but to which class did you add it? If you are just 
adding an extra button to the example, you shouldn't have to 
instantiate anything. You only need to add the new action to the 
MyAppDelegate, and then add the method to the Python code in 
MyAppDelegate.py.    Are you trying to add a whole new custom class? If 
so, that has to go in a separate Python class.

EP

Re: [Pyobjc-dev] Constants etc.

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

On Monday, Feb 3, 2003, at 03:08 America/New_York, Just van Rossum 
wrote:

> Ronald Oussoren wrote:
>
>> No it wouldn't, if the import hook gives you no more than the
>> currrent AddressBook module you don't have to compile anything.
>> Adding constants and global functions would require a compiler, but
>> luckily the scripts for extracting those are not really suitable for
>> this use :-)
>
> Don't the installed frameworks on a dev-tools-less system also contain
> the headers? If so, then the constants can be had from pure Python. If
> we use ctypes, the global functions can be had, too...

However, the installed frameworks _do not_ come with headers.. as 
evidenced by running those lsbom's though | cut -f 1 | grep 
"Frameworks/.*\.h\>"

ctypes is very enticing.  Making pyobjc (all of python really..) 
dependent on ctypes would surely make pyobjc a lot more powerful.

-bob

Re: [Pyobjc-dev] More on integer values

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

Ronald Oussoren wrote:

> Or we could translate NSNumbers to Python numbers when translating
> from Objective-C values to Python values, but I don't think we should
> do that.

Why not? It would surely be the least surprising behavior?

Just

Re: [Pyobjc-dev] Constants etc.

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

Ronald Oussoren wrote:

> No it wouldn't, if the import hook gives you no more than the
> currrent AddressBook module you don't have to compile anything.
> Adding constants and global functions would require a compiler, but
> luckily the scripts for extracting those are not really suitable for
> this use :-)

Don't the installed frameworks on a dev-tools-less system also contain
the headers? If so, then the constants can be had from pure Python. If
we use ctypes, the global functions can be had, too...

Just

Re: [Pyobjc-dev] More on integer values

[David E. <epp...@ic...>]

On 2/3/03 8:13 AM +0100 Ronald Oussoren <ous...@ci...> wrote:
> Not too hard. There are (at least) two possible solutions:
>
> - David could use objc.selector to specify a signature that is more to
> its liking (e.g. one of the    arguments is an int instead of an object).
> I don't really like this, mostly because of the arcane    interface of
> selector()

Rather than do that, I could (what I'm doing now) use int() to convert the 
type back to what I want.  So this isn't an issue that's preventing me from 
getting anything done; it's more in the nature of a rough edge that it 
would be nice to smooth off before it confuses too many other people.
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

Argh, I think I'm going mad... Did anyone else try this? One other  
thing that may make a difference: I've build my python 2.3 (framework  
install) with 'OPT=-O3 -mcpu=604 -faltivec -prebind -g'.

Ronald

On Monday, Feb 3, 2003, at 00:09 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, Feb 2, 2003, at 17:14 US/Eastern, Just van Rossum wrote:
>> I tried and ideed it works now. However, I must return None from
>> applicationShouldOpenUntitledFile_ for it to work: 0, False and NO  
>> seem
>> to be evaluated as YES.
>
> Odd. If I return 'None', the app crashes with:
>
> Traceback (most recent call last):
>   File  
> "/tmp/bbum-products/asdfasdfasdfadf.app/Contents/Resources/ 
> __main__.py", line 20, in ?
>     sys.exit(AppKit.NSApplicationMain(sys.argv))
> TypeError: applicationShouldOpenUntitledFile:: Cannot encode return  
> value: a string or an integer
>
> NO/0 cause it to bring up the stupid untitled window.
>
> b.bum
>
>

Re: [Pyobjc-dev] Constants etc.

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

On Monday, Feb 3, 2003, at 04:39 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, Feb 2, 2003, at 13:08 US/Eastern, Just van Rossum wrote:
>> bb...@ma... wrote:
>>
>>> Ronald:   should we go ahead and auto-generate the source to cover 
>>> all
>>> of AB's compiled constants?   This would require creating
>>> yet-another-module.  Maybe AddressBook should be moved out of PyObjC
>>> and into its own project given that most apps will not use the AB 
>>> API?
>>
>> I've been wondering, if interfacing an arbitrary framework is mostly
>> automated, we could make it more dynamic with an import hook: if 
>> "import
>> SomeFramework" fails, a hook can be called to wrap it if it happens to
>> be ean existing framework. That way we could delete AddressBook
>> altogether ;-)
>
> That would require that the dev tools be installed on every machine 
> that can automatically bridge frameworks....

No it wouldn't, if the import hook gives you no more than the currrent 
AddressBook module you don't have to compile anything. Adding constants 
and global functions would require a compiler, but luckily the scripts 
for extracting those are not really suitable for this use :-)

Ronald

Re: [Pyobjc-dev] More on integer values

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

On Monday, Feb 3, 2003, at 04:35 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, Feb 2, 2003, at 21:08 US/Eastern, David Eppstein wrote:
>> If they're not interchangeable, then maybe it's a bug that calling 
>> into and back from the undo manager is changing my ints into 
>> integers?  The point is, I'm passing it arguments that should work, 
>> and it's giving me back ones that don't work.
>
> The underlying problem is that the bridge has no way of knowing the 
> signature of the method your are invoking upon 
> prepareWithInvocationTarget_() and, as such, assumes everything passed 
> into that method is an int.
is and object [ed.] ;-)

[explanation of how NSUndoManager works removed for brevity]
> At least, I think it does.
Thats right.
>
> Fixing it may be hard.

Not too hard. There are (at least) two possible solutions:

- David could use objc.selector to specify a signature that is more to 
its liking (e.g. one of the
   arguments is an int instead of an object). I don't really like this, 
mostly because of the arcane
   interface of selector()

- We could treat NSNumber like a Python number when translating 
arguments to Objective-C values. Doing
   that would not be too hard. Or we could translate NSNumbers to Python 
numbers when translating from
   Objective-C values to Python values, but I don't think we should do 
that.

Ronald

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

On Monday, Feb 3, 2003, at 00:07 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, Feb 2, 2003, at 16:44 US/Eastern, Ronald Oussoren wrote:
>> I've just checked in a patch that seems to fix this. From what I have 
>> seen it looks like Objective-C methods that say they return an char 
>> actually return an int, the method stub we insert in the Objective-C 
>> class did return char. Because of this, the return value seen by the 
>> caller of the method contains our return value as well as 3 bytes of 
>> garbage. If your lucky these bytes are all 0. Hmm, methods returning 
>> shorts probably have a simular problem.
>
> Use the source, Luke!
>
> Seriously -- the objc runtime source is available in Darwin.

Thanks, I'll download it.

>
> Going from memory -- yes, anything 4 bytes or less is returned as a 4 
> byte value and then downcast as necessary.
>
> Anything greater than 4 bytes is basically a struct return type and 
> the calling convention is slightly different.

And floating point values are returned as if the function is returning 
a float/double.

Ronald

Re: [Pyobjc-dev] Constants etc.

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

On Sunday, Feb 2, 2003, at 13:08 US/Eastern, Just van Rossum wrote:
> bb...@ma... wrote:
>
>> Ronald:   should we go ahead and auto-generate the source to cover all
>> of AB's compiled constants?   This would require creating
>> yet-another-module.  Maybe AddressBook should be moved out of PyObjC
>> and into its own project given that most apps will not use the AB API?
>
> I've been wondering, if interfacing an arbitrary framework is mostly
> automated, we could make it more dynamic with an import hook: if 
> "import
> SomeFramework" fails, a hook can be called to wrap it if it happens to
> be ean existing framework. That way we could delete AddressBook
> altogether ;-)

That would require that the dev tools be installed on every machine 
that can automatically bridge frameworks....

Have a look at DevSDK.pkg and DevTools.pkg -- anything in there cannot 
be used at runtime without introducing the requirement that the dev 
tools be installed on the target system.

lsbom /Library/Receipts/DevSDK.pkg/Contents/Archive.bom
lsbom /Library/Receipts/DevTools.pkg/Contents/Archive.bom

b.bum

Re: [Pyobjc-dev] More on integer values

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

On Sunday, Feb 2, 2003, at 21:08 US/Eastern, David Eppstein wrote:
> If they're not interchangeable, then maybe it's a bug that calling 
> into and back from the undo manager is changing my ints into integers? 
>  The point is, I'm passing it arguments that should work, and it's 
> giving me back ones that don't work.

The underlying problem is that the bridge has no way of knowing the 
signature of the method your are invoking upon 
prepareWithInvocationTarget_() and, as such, assumes everything passed 
into that method is an int.

-prepareWithInvocationTarget_() basically configures the undo manager 
to act as a proxy for the next method call-- pushing that call onto a 
stack for later undo purposes.  That is...

 >>> y = NSUndoManager.alloc().init()
 >>> y
<NSUndoManager: 0x64bea0>
 >>> y.prepareWithInvocationTarget_(NSMutableArray.array())
<NSUndoManager: 0x64bea0>

.... or, when used in context ...

 >>> a = NSMutableArray.array()
 >>> uM = NSUndoManager.alloc().init()
 >>> a.addObject_("foo")
 >>> uM.prepareWithInvocationTarget_(a).removeObject_("foo")
 >>> a
(foo)
 >>> uM.undo()
 >>> a
()

... the undo manager effectively captures the invocation of 
removeObject_() and stores it away until the undo() is invoked.  At 
that point, undo() pops the captured invocation off the undo stack and 
invokes it.

As far as the bridge can tell, removeObject_() is being invoked on the 
undo manager itself!  As such, when the bridge tries to query the undo 
manager for the signature of the method being invoked, nothing is 
returned and the bridge falls back to sending across straight object 
representations of the various parameters.

This causes a straight integer parameter to be converted to an (id) on 
the way to being captured by the undo manager.

At least, I think it does.

Fixing it may be hard.

b.bum

Re: [Pyobjc-dev] More on integer values

[David E. <epp...@ic...>]

On 2/2/03 7:52 PM -0500 Bob Ippolito <bo...@re...> wrote:
> On Sunday, Feb 2, 2003, at 19:46 America/New_York, David Eppstein wrote:
>
>> I just hit an error in my code; looks like the following scenario
>> happened:
>> 1. My code passed an integer value to
>> undoManager.prepareWithInvocationTarget_
>> 2. I invoked an undo.
>> 3. undoManager called my code with an NSCFInteger in place of the
>> integer
>> (so far, no problem...)
>> 4. my code used that value as the column parameter of
>> NSTableView.editColumn_row_withEvent_select_
>> 5. TypeError: expected an integer for argument 1: its typespec is 'i12'
>>
>> As usual, the workaround is to wrap the value in an int(), but
>> shouldn't an objc integer be allowed to be used for this typespec?
>
> Well, from ObjC I would say no, if it expects an integer, it should get
> an int.  int and NSNumber aren't interchangable on the ObjC side of
> things.

If they're not interchangeable, then maybe it's a bug that calling into and 
back from the undo manager is changing my ints into integers?  The point 
is, I'm passing it arguments that should work, and it's giving me back ones 
that don't work.
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

[Pyobjc-dev] IB question

[Michael E. <men...@ka...>]

Hi -

I'm testing out PyObjC and have some problems (or more likely 
misunderstandings) when trying to use IB to build a UI.

I took the Cocoa-Python application template from CVS (did a pyobjc 
build from CVS as well).  I change the MyAppDelegate file to add a 
method like this:

	def sayGoodbyeAction_(self, sender):
		print "goodbye"
		

I then went into Interface BUilder and added a sayGoodbyeAction: action 
to the class and instantiated it and wired up the buttons, text field 
and delegate.  WHen I rebuild the application, the button I  added to 
the sample window doesn't work yet the button that comes with the 
template does work.   Well that's not true, sometimes my added 
button/method combination works, sometimes it doesn't.  I've triple 
checked that everything is wired up correctly and it still doesn't 
function.  At one point I thought I had some bizarre spacing issue so I 
copied the sayHelloAction method and pasted it and changed the method 
body and method name and then it worked.  then I tried adding another 
method and everything stopped working.

Is there some bit of weirdness that I should be aware of when using IB 
with PyObjC?

I have the October 2002 developer tools update and OS X 10.2.3.

Thanks for any guidance

Mike Engelhart

Re: [Pyobjc-dev] More on integer values

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

On Sunday, Feb 2, 2003, at 19:46 America/New_York, David Eppstein wrote:

> I just hit an error in my code; looks like the following scenario 
> happened:
> 1. My code passed an integer value to 
> undoManager.prepareWithInvocationTarget_
> 2. I invoked an undo.
> 3. undoManager called my code with an NSCFInteger in place of the 
> integer
> (so far, no problem...)
> 4. my code used that value as the column parameter of
> NSTableView.editColumn_row_withEvent_select_
> 5. TypeError: expected an integer for argument 1: its typespec is 'i12'
>
> As usual, the workaround is to wrap the value in an int(), but
> shouldn't an objc integer be allowed to be used for this typespec?

Well, from ObjC I would say no, if it expects an integer, it should get 
an int.  int and NSNumber aren't interchangable on the ObjC side of 
things.

-bob

[Pyobjc-dev] More on integer values

[David E. <epp...@ic...>]

I just hit an error in my code; looks like the following scenario happened:
1. My code passed an integer value to 
undoManager.prepareWithInvocationTarget_
2. I invoked an undo.
3. undoManager called my code with an NSCFInteger in place of the integer
(so far, no problem...)
4. my code used that value as the column parameter of
NSTableView.editColumn_row_withEvent_select_
5. TypeError: expected an integer for argument 1: its typespec is 'i12'

As usual, the workaround is to wrap the value in an int(), but
shouldn't an objc integer be allowed to be used for this typespec?
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] API mismatch

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

On Sunday, Feb 2, 2003, at 18:17 US/Eastern, Bob Ippolito wrote:
> Are you sure you're running setup.py with the python binary from  the 
> 2.3 cvs head you're targetting?  I think you may be running python 
> from the path, which would definitely pick up the wrong scent.

I just tried...

     sudo 
/Library/Frameworks/Python.framework/Versions/Current/bin/python 
setup.py install

... and the same warnings/errors appeared.

b.bum

Re: [Pyobjc-dev] API mismatch

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

On Sunday, Feb 2, 2003, at 18:05 America/New_York, bb...@ma... wrote:

> When I build PyObjC against Python 2.3 with both source trees from 
> CVS, I'm seeing quite a number of the following errors/warnings:
>
> mismatch for module _Foundation: This Python has API version 1012, 
> module _Foundation has version 1011.
>
> This smells like I'm picking up the wrong headers, but I'm not sure.
>
>

Are you sure you're running setup.py with the python binary from  the 
2.3 cvs head you're targetting?  I think you may be running python from 
the path, which would definitely pick up the wrong scent.

-bob

Re: [Pyobjc-dev] 0.9

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

On Sunday, Feb 2, 2003, at 15:26 US/Eastern, Tony Lownds wrote:
> Speaking of app wrappers, below is a bin-python-main.m that will load 
> a framework build of python. It seems to load faster than using the 
> execve methods...

That source is already in the CVS repository -- it is just in the Attic 
of, I believe, Web Services Tool.  Not a very useful spot.

There will be project builder templates created that use an embedded 
python interpreter.  Unfortunately, Apple's Python cannot [currently] 
be embedded into an application because it does not ship with a dylib 
or library to link against.


b.bum

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

On Sunday, Feb 2, 2003, at 17:14 US/Eastern, Just van Rossum wrote:
> I tried and ideed it works now. However, I must return None from
> applicationShouldOpenUntitledFile_ for it to work: 0, False and NO seem
> to be evaluated as YES.

Odd. If I return 'None', the app crashes with:

Traceback (most recent call last):
   File  
"/tmp/bbum-products/asdfasdfasdfadf.app/Contents/Resources/ 
__main__.py", line 20, in ?
     sys.exit(AppKit.NSApplicationMain(sys.argv))
TypeError: applicationShouldOpenUntitledFile:: Cannot encode return  
value: a string or an integer

NO/0 cause it to bring up the stupid untitled window.

b.bum

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

On Sunday, Feb 2, 2003, at 16:44 US/Eastern, Ronald Oussoren wrote:
> I've just checked in a patch that seems to fix this. From what I have 
> seen it looks like Objective-C methods that say they return an char 
> actually return an int, the method stub we insert in the Objective-C 
> class did return char. Because of this, the return value seen by the 
> caller of the method contains our return value as well as 3 bytes of 
> garbage. If your lucky these bytes are all 0. Hmm, methods returning 
> shorts probably have a simular problem.

Use the source, Luke!

Seriously -- the objc runtime source is available in Darwin.

Going from memory -- yes, anything 4 bytes or less is returned as a 4 
byte value and then downcast as necessary.

Anything greater than 4 bytes is basically a struct return type and the 
calling convention is slightly different.

b.bum

[Pyobjc-dev] API mismatch

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

When I build PyObjC against Python 2.3 with both source trees from CVS,  
I'm seeing quite a number of the following errors/warnings:

/tmp/bbum-products/asdfasdfasdfadf.app/Contents/Resources/PyObjC/objc/ 
__init__.py:28: RuntimeWarning: Python C API version mismatch for  
module _objc: This Python has API version 1012, module _objc has  
version 1011.
   from _objc import *
/tmp/bbum-products/asdfasdfasdfadf.app/Contents/Resources/PyObjC/objc/ 
__init__.py:88: RuntimeWarning: Python C API version mismatch for  
module _FoundationMapping: This Python has API version 1012, module  
_FoundationMapping has version 1011.
   import _FoundationMapping
/tmp/bbum-products/asdfasdfasdfadf.app/Contents/Resources/PyObjC/ 
Foundation/__init__.py:3: RuntimeWarning: Python C API version mismatch  
for module _Foundation: This Python has API version 1012, module  
_Foundation has version 1011.

This smells like I'm picking up the wrong headers, but I'm not sure.

b.bum

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

Ronald Oussoren wrote:

> I've just checked in a patch that seems to fix this. From what I have 
> seen it looks like Objective-C methods that say they return an char 
> actually return an int, the method stub we insert in the Objective-C 
> class did return char. Because of this, the return value seen by the 
> caller of the method contains our return value as well as 3 bytes of 
> garbage. If your lucky these bytes are all 0. Hmm, methods returning 
> shorts probably have a simular problem.

I tried and ideed it works now. However, I must return None from
applicationShouldOpenUntitledFile_ for it to work: 0, False and NO seem
to be evaluated as YES.

Just

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

On Sunday, Feb 2, 2003, at 22:11 Europe/Amsterdam, Ronald Oussoren 
wrote:
>
> On Sunday, Feb 2, 2003, at 21:25 Europe/Amsterdam, I wrote:
>>> Yes, latest from CVS.
>> I was using a slightly later version than you. After updating to the 
>> latest version in CVS I also have the problem :-(.
>
> That should have been 'earlier', if I had used a later version fixing 
> it would have been some much easier :-)

I seem like talking to myself ;-)

I've just checked in a patch that seems to fix this. From what I have 
seen it looks like Objective-C methods that say they return an char 
actually return an int, the method stub we insert in the Objective-C 
class did return char. Because of this, the return value seen by the 
caller of the method contains our return value as well as 3 bytes of 
garbage. If your lucky these bytes are all 0. Hmm, methods returning 
shorts probably have a simular problem.

As the CVS checkin message says: I am going to search for a document 
describing the exact calling convention for Objective-C methods. The 
current solution feels hackish.

Ronald

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

On Sunday, Feb 2, 2003, at 21:25 Europe/Amsterdam, I wrote:
>> Yes, latest from CVS.
> I was using a slightly later version than you. After updating to the 
> latest version in CVS I also have the problem :-(.

That should have been 'earlier', if I had used a later version fixing 
it would have been some much easier :-)

Ronald

Re: [Pyobjc-dev] applicationShouldOpenUntitledFile_

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

On Sunday, Feb 2, 2003, at 21:04 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, Feb 2, 2003, at 15:00 US/Eastern, Ronald Oussoren wrote:
>> That's very weird. I was using Python 2.3, maybe that explains 
>> things. I'll rebuild the bridge for Python 2.2 and check if this 
>> helps.
>
> I tried with both!   Same behavior.
>
>> You are using the fixes to libffi_support.m I checked in last week, 
>> aren't you? These include a fix for BOOL values (actually 
>> signed/unsigned characters). Hmm, but that's only relevant when 
>> calling into Objective-C, not for this problem.
>>
> Yes, latest from CVS.
I was using a slightly later version than you. After updating to the 
latest version in CVS I also have the problem :-(.

Ronald