pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] status of enumerators?

[<bo...@pa...>]

i found this message in the list archives. does anyone know if 
enumerators
are working yet (they don't seem to be)? thanks, bob



>  I had thought enumerators should "just work" in PyObjC?  I should be
>  able to do...
>
>       for x in array.objectEnumerator():
>             print x
>
>  ... and it'll just work.    Oh, wait, that's 'for x in array:'.
>
>  We need to be able to do 'for x in anObject.objectEnumerator():', as
>  well.
>
>  Specifically, for table view:
>
>       for x in aTableView.rowEnumerator():
>             ... manipulate x ...
>
>  rowEnumerator() returns an enumerator that enumerates the selected row
>  indices.   Very handy.
>
>  (Trivial change in the bridge, I have zero time to do it now... I'll
>  get to this sometime soon unless someone [hopefully] beats me to it. 
> :-)
>
>  b.bum

Re: Broken build (was: Re: [Pyobjc-dev] constants for AddressBook Foundation?)

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

You have to install libffi, there is a useable copy in the files  
section on sourceforge.

Ronald

On Wednesday, Feb 26, 2003, at 00:01 Europe/Amsterdam, Bob Pasker wrote:

> just did a checkout and a setup.py build, which didn't work:
>
> gcc -DNDEBUG -O3 -Wall -Wstrict-prototypes -I/sw/include/python2.2 -c  
> Modules/objc/libffi_support.m -o  
> build/temp.darwin-6.4-PowerMacintosh-2.2/libffi_support.o  
> -DOBJC_PARANOIA_MODE -DOC_WITH_LIBFFI -Ilibffi/include  
> -DOC_USE_FFI_SHORTCUTS -DMACOSX -no-cpp-precomp -Wno-long-double -O0  
> -g -IInclude/
> Modules/objc/libffi_support.m:30:17: ffi.h: No such file or directory
> Modules/objc/libffi_support.m:35:6: #error "Need FFI_CLOSURES!"
> Modules/objc/libffi_support.m: In function `free_type':
> Modules/objc/libffi_support.m:67: `ffi_type' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:67: (Each undeclared identifier is  
> reported only once
> Modules/objc/libffi_support.m:67: for each function it appears in.)
> Modules/objc/libffi_support.m:67: parse error before ')' token
> Modules/objc/libffi_support.m: At top level:
> Modules/objc/libffi_support.m:71: parse error before '*' token
> Modules/objc/libffi_support.m:71: warning: type defaults to `int' in  
> declaration of `signature_to_ffi_type'
> Modules/objc/libffi_support.m:71: warning: data definition has no type  
> or storage class
> Modules/objc/libffi_support.m:73: parse error before '*' token
> Modules/objc/libffi_support.m:75: warning: return type defaults to  
> `int'
> Modules/objc/libffi_support.m: In function `struct_to_ffi_type':
> Modules/objc/libffi_support.m:78: `ffi_type' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:78: `type' undeclared (first use in this  
> function)
> Modules/objc/libffi_support.m:89: parse error before ')' token
> Modules/objc/libffi_support.m:109: `FFI_TYPE_STRUCT' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m: At top level:
> Modules/objc/libffi_support.m:152: parse error before '*' token
> Modules/objc/libffi_support.m:154: warning: return type defaults to  
> `int'
> Modules/objc/libffi_support.m: In function  
> `signature_to_ffi_return_type':
> Modules/objc/libffi_support.m:157: `ffi_type_sint' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:159: `ffi_type_uint' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m: At top level:
> Modules/objc/libffi_support.m:165: parse error before '*' token
> Modules/objc/libffi_support.m:167: warning: return type defaults to  
> `int'
> Modules/objc/libffi_support.m: In function `signature_to_ffi_type':
> Modules/objc/libffi_support.m:169: `ffi_type_void' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:170: `ffi_type_pointer' undeclared  
> (first use in this function)
> Modules/objc/libffi_support.m:173: `ffi_type_schar' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:174: `ffi_type_uchar' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:175: `ffi_type_sshort' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:176: `ffi_type_ushort' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:177: `ffi_type_sint' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:178: `ffi_type_uint' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:179: `ffi_type_slong' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:180: `ffi_type_ulong' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:181: `ffi_type_sint64' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:182: `ffi_type_uint64' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:183: `ffi_type_float' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:184: `ffi_type_double' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m: At top level:
> Modules/objc/libffi_support.m:212: parse error before '*' token
> Modules/objc/libffi_support.m:213: warning: function declaration isn't  
> a prototype
> Modules/objc/libffi_support.m: In function `method_stub':
> Modules/objc/libffi_support.m:215: `userdata' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:227: `args' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:302: `resp' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m: In function `ObjC_MakeIMPForSignature':
> Modules/objc/libffi_support.m:365: `ffi_cif' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:365: `cif' undeclared (first use in this  
> function)
> Modules/objc/libffi_support.m:366: `ffi_closure' undeclared (first use  
> in this function)
> Modules/objc/libffi_support.m:366: `cl' undeclared (first use in this  
> function)
> Modules/objc/libffi_support.m:367: `ffi_type' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:367: `cl_arg_types' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:368: `cl_ret_type' undeclared (first use  
> in this function)
> Modules/objc/libffi_support.m:369: `ffi_status' undeclared (first use  
> in this function)
> Modules/objc/libffi_support.m:369: parse error before "rv"
> Modules/objc/libffi_support.m:387: parse error before ')' token
> Modules/objc/libffi_support.m:417: `rv' undeclared (first use in this  
> function)
> Modules/objc/libffi_support.m:417: warning: implicit declaration of  
> function `ffi_prep_cif'
> Modules/objc/libffi_support.m:417: `FFI_DEFAULT_ABI' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:419: `FFI_OK' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:444: warning: implicit declaration of  
> function `ffi_prep_closure'
> Modules/objc/libffi_support.m:372: warning: unused variable `buf'
> Modules/objc/libffi_support.m: In function `ObjC_FFICaller':
> Modules/objc/libffi_support.m:507: `ffi_cif' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:507: parse error before "cif"
> Modules/objc/libffi_support.m:508: `ffi_type' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:508: `arglist' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:703: `ffi_type_pointer' undeclared  
> (first use in this function)
> Modules/objc/libffi_support.m:839: `cif' undeclared (first use in this  
> function)
> Modules/objc/libffi_support.m:839: `FFI_DEFAULT_ABI' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:840: `ffi_type_void' undeclared (first  
> use in this function)
> Modules/objc/libffi_support.m:845: `FFI_OK' undeclared (first use in  
> this function)
> Modules/objc/libffi_support.m:854: warning: implicit declaration of  
> function `ffi_call'
> Modules/objc/libffi_support.m:854: warning: implicit declaration of  
> function `FFI_FN'
> Modules/objc/libffi_support.m:516: warning: unused variable `tpBuf'
> error: command 'gcc' failed with exit status 1
>
>
>
>
> On Monday, February 24, 2003, at 10:55 PM, Ronald Oussoren wrote:
>
>>
>> On Tuesday, Feb 25, 2003, at 04:53 Europe/Amsterdam, Bob Pasker wrote:
>>
>>> trying to do this:
>>>
>>>         
>>> AddressBook.ABPerson.searchElementForProperty_label_key_value_compari 
>>> son_(
>>>                    kABLastNameProperty, None, None, "foo",  
>>> kABEqualCaseInsensitive)
>>>
>>> without any luck (global name 'kABLastNameProperty' is not defined)
>>
>> Works for me ;-) ;-). The constants were recently added to the  
>> version in CVS.
>>
>> Ronald
>>
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Broken build (was: Re: [Pyobjc-dev] constants for AddressBook Foundation?)

[<bo...@pa...>]

just did a checkout and a setup.py build, which didn't work:

gcc -DNDEBUG -O3 -Wall -Wstrict-prototypes -I/sw/include/python2.2 -c  
Modules/objc/libffi_support.m -o  
build/temp.darwin-6.4-PowerMacintosh-2.2/libffi_support.o  
-DOBJC_PARANOIA_MODE -DOC_WITH_LIBFFI -Ilibffi/include  
-DOC_USE_FFI_SHORTCUTS -DMACOSX -no-cpp-precomp -Wno-long-double -O0 -g  
-IInclude/
Modules/objc/libffi_support.m:30:17: ffi.h: No such file or directory
Modules/objc/libffi_support.m:35:6: #error "Need FFI_CLOSURES!"
Modules/objc/libffi_support.m: In function `free_type':
Modules/objc/libffi_support.m:67: `ffi_type' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:67: (Each undeclared identifier is  
reported only once
Modules/objc/libffi_support.m:67: for each function it appears in.)
Modules/objc/libffi_support.m:67: parse error before ')' token
Modules/objc/libffi_support.m: At top level:
Modules/objc/libffi_support.m:71: parse error before '*' token
Modules/objc/libffi_support.m:71: warning: type defaults to `int' in  
declaration of `signature_to_ffi_type'
Modules/objc/libffi_support.m:71: warning: data definition has no type  
or storage class
Modules/objc/libffi_support.m:73: parse error before '*' token
Modules/objc/libffi_support.m:75: warning: return type defaults to `int'
Modules/objc/libffi_support.m: In function `struct_to_ffi_type':
Modules/objc/libffi_support.m:78: `ffi_type' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:78: `type' undeclared (first use in this  
function)
Modules/objc/libffi_support.m:89: parse error before ')' token
Modules/objc/libffi_support.m:109: `FFI_TYPE_STRUCT' undeclared (first  
use in this function)
Modules/objc/libffi_support.m: At top level:
Modules/objc/libffi_support.m:152: parse error before '*' token
Modules/objc/libffi_support.m:154: warning: return type defaults to  
`int'
Modules/objc/libffi_support.m: In function  
`signature_to_ffi_return_type':
Modules/objc/libffi_support.m:157: `ffi_type_sint' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:159: `ffi_type_uint' undeclared (first  
use in this function)
Modules/objc/libffi_support.m: At top level:
Modules/objc/libffi_support.m:165: parse error before '*' token
Modules/objc/libffi_support.m:167: warning: return type defaults to  
`int'
Modules/objc/libffi_support.m: In function `signature_to_ffi_type':
Modules/objc/libffi_support.m:169: `ffi_type_void' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:170: `ffi_type_pointer' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:173: `ffi_type_schar' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:174: `ffi_type_uchar' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:175: `ffi_type_sshort' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:176: `ffi_type_ushort' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:177: `ffi_type_sint' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:178: `ffi_type_uint' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:179: `ffi_type_slong' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:180: `ffi_type_ulong' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:181: `ffi_type_sint64' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:182: `ffi_type_uint64' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:183: `ffi_type_float' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:184: `ffi_type_double' undeclared (first  
use in this function)
Modules/objc/libffi_support.m: At top level:
Modules/objc/libffi_support.m:212: parse error before '*' token
Modules/objc/libffi_support.m:213: warning: function declaration isn't  
a prototype
Modules/objc/libffi_support.m: In function `method_stub':
Modules/objc/libffi_support.m:215: `userdata' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:227: `args' undeclared (first use in this  
function)
Modules/objc/libffi_support.m:302: `resp' undeclared (first use in this  
function)
Modules/objc/libffi_support.m: In function `ObjC_MakeIMPForSignature':
Modules/objc/libffi_support.m:365: `ffi_cif' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:365: `cif' undeclared (first use in this  
function)
Modules/objc/libffi_support.m:366: `ffi_closure' undeclared (first use  
in this function)
Modules/objc/libffi_support.m:366: `cl' undeclared (first use in this  
function)
Modules/objc/libffi_support.m:367: `ffi_type' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:367: `cl_arg_types' undeclared (first use  
in this function)
Modules/objc/libffi_support.m:368: `cl_ret_type' undeclared (first use  
in this function)
Modules/objc/libffi_support.m:369: `ffi_status' undeclared (first use  
in this function)
Modules/objc/libffi_support.m:369: parse error before "rv"
Modules/objc/libffi_support.m:387: parse error before ')' token
Modules/objc/libffi_support.m:417: `rv' undeclared (first use in this  
function)
Modules/objc/libffi_support.m:417: warning: implicit declaration of  
function `ffi_prep_cif'
Modules/objc/libffi_support.m:417: `FFI_DEFAULT_ABI' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:419: `FFI_OK' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:444: warning: implicit declaration of  
function `ffi_prep_closure'
Modules/objc/libffi_support.m:372: warning: unused variable `buf'
Modules/objc/libffi_support.m: In function `ObjC_FFICaller':
Modules/objc/libffi_support.m:507: `ffi_cif' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:507: parse error before "cif"
Modules/objc/libffi_support.m:508: `ffi_type' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:508: `arglist' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:703: `ffi_type_pointer' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:839: `cif' undeclared (first use in this  
function)
Modules/objc/libffi_support.m:839: `FFI_DEFAULT_ABI' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:840: `ffi_type_void' undeclared (first  
use in this function)
Modules/objc/libffi_support.m:845: `FFI_OK' undeclared (first use in  
this function)
Modules/objc/libffi_support.m:854: warning: implicit declaration of  
function `ffi_call'
Modules/objc/libffi_support.m:854: warning: implicit declaration of  
function `FFI_FN'
Modules/objc/libffi_support.m:516: warning: unused variable `tpBuf'
error: command 'gcc' failed with exit status 1




On Monday, February 24, 2003, at 10:55 PM, Ronald Oussoren wrote:

>
> On Tuesday, Feb 25, 2003, at 04:53 Europe/Amsterdam, Bob Pasker wrote:
>
>> trying to do this:
>>
>>         
>> AddressBook.ABPerson.searchElementForProperty_label_key_value_comparis 
>> on_(
>>                    kABLastNameProperty, None, None, "foo",  
>> kABEqualCaseInsensitive)
>>
>> without any luck (global name 'kABLastNameProperty' is not defined)
>
> Works for me ;-) ;-). The constants were recently added to the version  
> in CVS.
>
> Ronald
>

[Pyobjc-dev] CVS: pyobjc/Modules/AppKit 00ReadMe.....

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

I'm not going to approve this one.... but forwarded this on as an FYI.  
The restructuring is done for the moment.  There are other cleanups I 
could think of, but I don't have time right now.

I tried to normalize everything to the framework name.  I left AppKit 
as AppKit because it'd be hell to change (and out of deference to 
history).

Ronald:  This proved to be a lot easier than I expected and I have you 
to thank for that... so, thank you.

b.bum

Begin forwarded message:

> From: pyo...@li...
> Date: Tue Feb 25, 2003  13:36:15 US/Eastern
> To: bb...@us...
> Subject: Your message to pyobjc-checkins awaits moderator approval
>
> Your mail to 'pyobjc-checkins' with the subject
>
>     CVS: pyobjc/Modules/AppKit 00ReadMe.txt,NONE,1.1
> _AppKit.m,NONE,1.1 _AppKitMapping.m,NONE,1.1
> _App_Enum.GNUstep.inc,NONE,1.1 _App_Enum.inc,NONE,1.1
> _App_Functions.GNUstep.inc,NONE,1.1 _App_Functions.inc,NONE,1.1
> _App_Str.GNUstep.inc,NONE,1.1 _App_Str.inc,NONE,1.1
> _App_Var.GNUstep.inc,NONE,1.1 _App_Var.inc,NONE,1.1
>
> Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
>     Message body is too big: 184853 bytes but there's a limit of 100
> KB
>
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.
>
If tyranny and oppression come to this land,
it will be in the guise of fighting a foreign enemy.
	- James Madison, as US congressman.

[Pyobjc-dev] CVS restructure on the way

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

(CVS problem fixed -- it was a PBKAC)

I'm in the midst of restructuring everything in Modules/.   Will commit 
shortly.  If you are working with anything in Modules/ outside of 
Modules/objc/, hold off for a moment...

b.bum

Re: [Pyobjc-dev] constants for AddressBook Foundation?

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

On Tuesday, Feb 25, 2003, at 04:53 Europe/Amsterdam, Bob Pasker wrote:

> trying to do this:
>
>         
> AddressBook.ABPerson.searchElementForProperty_label_key_value_compariso 
> n_(
>                    kABLastNameProperty, None, None, "foo",  
> kABEqualCaseInsensitive)
>
> without any luck (global name 'kABLastNameProperty' is not defined)

Works for me ;-) ;-). The constants were recently added to the version  
in CVS.

Ronald

[Pyobjc-dev] constants for AddressBook Foundation?

[<bo...@pa...>]

trying to do this:

         
AddressBook.ABPerson.searchElementForProperty_label_key_value_comparison 
_(
                    kABLastNameProperty, None, None, "foo",  
kABEqualCaseInsensitive)

without any luck (global name 'kABLastNameProperty' is not defined)

can someone help?

thanks.

--bob

[Pyobjc-dev] CVS repos seems hosed...

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

[bumbox:pyobjc/Scripts/CodeGenerators] bbum% cvs add *.txt *.py
cvs [server aborted]: "add" requires write access to the repository

Re: [Pyobjc-dev] pickled Objective-C objects

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

bb...@ma... wrote:

> On Monday, Feb 24, 2003, at 13:29 US/Eastern, Just van Rossum wrote:
> > Is objc._convenience the right place for this? I guess not since it
> > currently doesn't even import Foundation.
> 
> Maybe, maybe not.   Likely, the correct approach would be to test the
> object to see if it responds to the NSCoding protocol.  If it does,
> then NSArchiver/NSUnarchiver can be used to archive/unarchive
> instances of the class and, hence, the class is pickle compatible.

Well, I assume if you try the NSConding protocol on an object that
doesn't support it, an exception is raised. This would be entirely
correct behavior and I don't see why we would have to check in the first
place.

> > PS: It seems NSData doesn't support the buffer protocol; you can't
> > pass a string where an NSData is expected, and
> > str(anNSDataInstance) doesn't do the right thing.
> 
> Can the buffer protocol be implemented entirely on the Python side of 
> the bridge?   Is so, it should be easy to support?

Not sure.

> If not, then the ObjC->Python proxy would have to be extended to offer 
> buffer protocol features *only* if appropriate. 

Meaning? When would it not be appropriate? Are there situations where
str(anNSDataInstance) would not be meaningful? Same for the reverse;
it's just annoying to have to do

    NSUnarchiver.unarchiveObjectWithData_(
            NSData.dataWithBytes_length_(data, len(data)))

instead of simply

    NSUnarchiver.unarchiveObjectWithData_(data)

> Given the way this is 
> implemented, I believe the implication is that we would need to 
> effectively create a second proxy class [python C-API type class] that 
> contains non-NULL entries for the buffer protocol support?

I'm not following, but then again, I'm not familiar with the
implementation.

Just

Re: [Pyobjc-dev] pickled Objective-C objects

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

On Monday, Feb 24, 2003, at 13:29 US/Eastern, Just van Rossum wrote:
> Is objc._convenience the right place for this? I guess not since it
> currently doesn't even import Foundation.

Maybe, maybe not.   Likely, the correct approach would be to test the 
object to see if it responds to the NSCoding protocol.  If it does, 
then NSArchiver/NSUnarchiver can be used to archive/unarchive instances 
of the class and, hence, the class is pickle compatible.

> PS: It seems NSData doesn't support the buffer protocol; you can't pass
> a string where an NSData is expected, and str(anNSDataInstance) doesn't
> do the right thing.

Can the buffer protocol be implemented entirely on the Python side of 
the bridge?   Is so, it should be easy to support?

If not, then the ObjC->Python proxy would have to be extended to offer 
buffer protocol features *only* if appropriate.  Given the way this is 
implemented, I believe the implication is that we would need to 
effectively create a second proxy class [python C-API type class] that 
contains non-NULL entries for the buffer protocol support?

b.bum

Re: [Pyobjc-dev] pickled Objective-C objects

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

I managed to add pickle support to (as a test) NSBezierPath by adding a
__reduce__ method to a __subclass__. I'm now trying to figure out how to
add __reduce__ to all objects, and was hoping to add it to
objc._convenience, but I'm stuck. Here's what I have so far:


def _unpickleNSObject(data):
    from Foundation import NSUnarchiver, NSData
    return NSUnarchiver.unarchiveObjectWithData_(
        NSData.dataWithBytes_length_(data, len(data)))

def __reduce__NSObject(obj):
    from Foundation import NSArchiver
    return _unpickleNSObject, (str(
        NSArchiver.archivedDataWithRootObject_(self).bytes()),)

# XXX now add __reduce__NSObject as __reduce__ to all objects

Hm, it seems this would work:

NSObject.__reduce__ = __reduce__NSObject

Is objc._convenience the right place for this? I guess not since it
currently doesn't even import Foundation.

Just

PS: It seems NSData doesn't support the buffer protocol; you can't pass
a string where an NSData is expected, and str(anNSDataInstance) doesn't
do the right thing.

Re: [Pyobjc-dev] A bit of a mess....

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

On Monday, Feb 24, 2003, at 16:27 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Sunday, Feb 23, 2003, at 03:59 US/Eastern, Ronald Oussoren wrote:
>> On Saturday, Feb 22, 2003, at 23:39 Europe/Amsterdam, Bill Bumgarner 
>> wrote:
>>> This seems like a big mess and is only going to get worse over time. 
>>>   It also-- I would think-- hampers GnuStep support in that not all 
>>> of the frameworks are available under GnuStep or, if there, are 
>>> completely different.
>>
>> The current situation doesn't really hamper GNUstep support, setup.py 
>> checks if frameworks are present before building the support modules. 
>> The right solution would probably be to move the scripts in 
>> Modules/Cocoa/scripts to the toplevel scripts directory and integrate 
>> them into setup.py. That way we'd automaticly wrap only those items 
>> that are supported on a system.
>>
>> Let's move the script first and worry about the side-effects of 
>> calling them from setup.py later.
>
> OK;  will do.   I'm going to move the scripts, make sure everything 
> works, then commit.
>
> At some point, I would like to move to invoking the scripts that 
> generate the various *.inc files to within setup.py.   This would make 
> supporting 10.1 easier and will make supporting 10.3 easier, assuming 
> new API (safe assumption).

Great. Of course this only works if the new functions were not manually 
wrapped. As an example, if 10.1 didn't have NSCountWindows rebuilding 
the .inc files won't help. We can probably work around this by making 
use of MAC_OS_X_VERSION_MAX_ALLOWED and simular definitions.

>
> It is also probably time to go with FFI only support?   As you have 
> noted, there are still differences between FFI and non-FFI bridge 
> behavior and the lot of us has had difficulty keeping the two 
> straight.   There are also FFI only features now [classAddMethods()] 
> and will likely be more in the future.

Is anyone using non-FFI builds (except the poor souls stuck with 0.8 
(-; )?. I seldomly use or test non-FFI builds, mostly only when I want 
to make sure if a bug is caused by libffi or not.

I'm in favor of dropping the non-FFI support, first only register.m and 
when test_methods.py is more complete I'd even drop 
execute_and_pythonify_objc_method.

>
> I don't know if it is possible to support libFFI with GCC 2.95 [on X 
> 10.1]... at the same time, it seems like we have largely punted on 
> ever supporting 10.1?

I think 10.1 support is simular to GNUstep support: Unless someone 
steps up to actually implement and maintain the support it is highly 
unlikely that we'll ever get around to doing it.

>
>>> If we are going to fix this, we should do it now.  Preferably, the 
>>> various framework specific modules should be encapsulated in their 
>>> own directories.   Some of the framework support should potentially 
>>> even be moved out of the pyobjc root source as it is less about 
>>> bridging to the core of ObjC and more about bridging a specific 
>>> framework's worth of functionality.
>>
>> Just like in Lib there should be one directory for every supported 
>> framework in Modules. I don't want to move frameworks from the pyobjc 
>> source tree unless supporting them cost too much time or someone 
>> steps up to maintain them in a seperate distribution.
>
> Ok -- I would also like to pull the stuff in AppKit/ into two new 
> directories;  Cocoa/ and Foundation/.   AppKit *really* should be 
> renamed Cocoa.  Even if Cocoa is only a cosmetic name in OS X [try 
> class-dumping the Cocoa.framework -- it contains nothing], we ought to 
> stick w/Apple's nomenclature as much as possible...

The documentation still refers to AppKit, I don't think that calling 
the wrapper for AppKit.framework Cocoa would be very helpfull. If we do 
add a Cocoa module it should basicly be just this:
	from Foundation import *
	from AppKit import *

Ronald

Re: [Pyobjc-dev] A bit of a mess....

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

On Sunday, Feb 23, 2003, at 03:59 US/Eastern, Ronald Oussoren wrote:
> On Saturday, Feb 22, 2003, at 23:39 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> This seems like a big mess and is only going to get worse over time.  
>>  It also-- I would think-- hampers GnuStep support in that not all of 
>> the frameworks are available under GnuStep or, if there, are 
>> completely different.
>
> The current situation doesn't really hamper GNUstep support, setup.py 
> checks if frameworks are present before building the support modules. 
> The right solution would probably be to move the scripts in 
> Modules/Cocoa/scripts to the toplevel scripts directory and integrate 
> them into setup.py. That way we'd automaticly wrap only those items 
> that are supported on a system.
>
> Let's move the script first and worry about the side-effects of 
> calling them from setup.py later.

OK;  will do.   I'm going to move the scripts, make sure everything 
works, then commit.

At some point, I would like to move to invoking the scripts that 
generate the various *.inc files to within setup.py.   This would make 
supporting 10.1 easier and will make supporting 10.3 easier, assuming 
new API (safe assumption).

It is also probably time to go with FFI only support?   As you have 
noted, there are still differences between FFI and non-FFI bridge 
behavior and the lot of us has had difficulty keeping the two straight. 
   There are also FFI only features now [classAddMethods()] and will 
likely be more in the future.

I don't know if it is possible to support libFFI with GCC 2.95 [on X 
10.1]... at the same time, it seems like we have largely punted on ever 
supporting 10.1?

>> If we are going to fix this, we should do it now.  Preferably, the 
>> various framework specific modules should be encapsulated in their 
>> own directories.   Some of the framework support should potentially 
>> even be moved out of the pyobjc root source as it is less about 
>> bridging to the core of ObjC and more about bridging a specific 
>> framework's worth of functionality.
>
> Just like in Lib there should be one directory for every supported 
> framework in Modules. I don't want to move frameworks from the pyobjc 
> source tree unless supporting them cost too much time or someone steps 
> up to maintain them in a seperate distribution.

Ok -- I would also like to pull the stuff in AppKit/ into two new 
directories;  Cocoa/ and Foundation/.   AppKit *really* should be 
renamed Cocoa.  Even if Cocoa is only a cosmetic name in OS X [try 
class-dumping the Cocoa.framework -- it contains nothing], we ought to 
stick w/Apple's nomenclature as much as possible...

> For me as a *user* of PyObjC the most interesting part are the bridged 
> frameworks, the objc module just happens to be the most usefull way to 
> bridge these frameworks.

Agreed.

> BTW. Feel free to move files around, I'd like to concentrate on fixing 
> some bugs in libffi_support.m: structure returns aren't working at the 
> moment.

Will do.

b.bum

Re: [Pyobjc-dev] pickled Objective-C objects

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

On Monday, Feb 24, 2003, at 04:48 US/Eastern, Just van Rossum wrote:
>>> __init__/tp_init method. Calling an ObjC class will then still
>>> result in that exception, while still properly supporting __new__.
>>>
>> Class clusters may be problematic here (in combination with pickling).
>> If you create an NSArray you actually end up with a subclass of
>> NSArray. This should be pickled as if it is an NSArray (Apple might
>> replace the classes implementing NSArray by a completely different set
>> of classes).
>
> Yes, it abviously need to support classForCoder. But I would expect  
> that
> NSArray.alloc().initWithCoder() is the right thing, no? If so, aliasing
> __new__ to alloc() is quite natural.

While I can't find the reference in the documentation, I'm fairly  
certain you are not supposed to directly invoke -initWithCoder:.

file:///Developer/Documentation/Cocoa/TasksAndConcepts/ 
ProgrammingTopics/Archiving/index.html#//apple_ref/doc/uid/10000047i

Somewhere in there, an NSArchiver/NSUnarchiver must be used to  
recompose the archived object graph.  That is, you would use  
NSUnarchiver's..

+ unarchiveObjectWithData:fp12;
+ unarchiveObjectWithFile:fp12;

... methods to unarchive the data.   This takes care of all of the  
potential referential cycles that may be present in the object graph  
(example:  if an array contains the same object three times, it'll be  
decoded as one instance with three references / retains in the array).

b.bum
(Who hadn't been paying close enough attention to the conversation to  
know whether or not the above is 100% relevant).

Re: [Pyobjc-dev] pickled Objective-C objects

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

Ronald Oussoren wrote:

> > __init__/tp_init method. Calling an ObjC class will then still
> > result in that exception, while still properly supporting __new__.
> >
> Class clusters may be problematic here (in combination with pickling). 
> If you create an NSArray you actually end up with a subclass of 
> NSArray. This should be pickled as if it is an NSArray (Apple might 
> replace the classes implementing NSArray by a completely different set 
> of classes).

Yes, it abviously need to support classForCoder. But I would expect that
NSArray.alloc().initWithCoder() is the right thing, no? If so, aliasing
__new__ to alloc() is quite natural.

> BTW. I just tried to pickle some Cocoa objects using protocol version 
> 2, and that didn't crash. It also didn't work correctly (of course): 
> the Objective-C state isn't saved.

I noticed that too ;-)

Just

Re: [Pyobjc-dev] pickled Objective-C objects

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

On Sunday, Feb 23, 2003, at 22:13 Europe/Amsterdam, Just van Rossum 
wrote:

> A couple of quick thoughts.
>
[...]

> I noticed that unpickling a new style object causes cls.__new__ to be
> called. This currently does not work for ObjC classes as they insist on
> being allocated with alloc(). However, ObjC's alloc/init protocol is in
> many ways equivalent to Python's __new__/__init__ protocol, so as a
> first step towards supporting pickling, I propose to make __new__ an
> alias for alloc, and move the "TypeError: Use class methods to
> instantiate new Objective-C objects" exception to the __init__/tp_init
> method. Calling an ObjC class will then still result in that exception,
> while still properly supporting __new__.
>
Class clusters may be problematic here (in combination with pickling). 
If you create an NSArray you actually end up with a subclass of 
NSArray. This should be pickled as if it is an NSArray (Apple might 
replace the classes implementing NSArray by a completely different set 
of classes).

BTW. I just tried to pickle some Cocoa objects using protocol version 
2, and that didn't crash. It also didn't work correctly (of course): 
the Objective-C state isn't saved.

Ronald

Re: [Pyobjc-dev] pickled Objective-C objects

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

A couple of quick thoughts.

Guido and Tim Peters have been doing a lot of work on pickle very
recently (for 2.3, it's in 2.3a2). I don't know the details but it has
to do with new style classes, so probably affects PyObjC (in a good way,
hopefully ;-). The original boolean dump flag denoting text/binary has
been upgraded to mean the protocol version: protocol 0 is the text
version, 1 is the original binary protocol, 2 is a new binary protocol,
which apparently has better (more efficient) support for new style
objects. I'm not sure how it all works, but if it would make things
easier, I would be happy with a 2.3-only solution.

I noticed that unpickling a new style object causes cls.__new__ to be
called. This currently does not work for ObjC classes as they insist on
being allocated with alloc(). However, ObjC's alloc/init protocol is in
many ways equivalent to Python's __new__/__init__ protocol, so as a
first step towards supporting pickling, I propose to make __new__ an
alias for alloc, and move the "TypeError: Use class methods to
instantiate new Objective-C objects" exception to the __init__/tp_init
method. Calling an ObjC class will then still result in that exception,
while still properly supporting __new__.

Just

Re: [Pyobjc-dev] pickled Objective-C objects

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

Ronald Oussoren wrote:

> I noticed the other day that our unicode subclass doesn't support
> pickling. Should we add support for pickling, and if so how? Should
> instances of our subclass be pickled just like 'normal' unicode
> objects (although I have no idea how to do that), or as NSString
> values?

I wouldn't care much either way, although I don't see much use in
pickling the NSString portion; might as well convert to a unicode
object. But ditto: I have no idea how to do that...

> Normal Objective-C classes also don't support pickling, [ ... ]

Synchronicity! I was thinking about that today. I have written a little
app that constructs hundreds of NSBezierPaths at app startup time; I
gather it would save a lot of time if I could just load them from a
pickle. Would be way cool. For now I think I'll play with
NS[Un]Archiver. I don't have a use case, but the reverse would also be
very cool: the ObjC wrappers/proxies for Python objects could map the
NSCoding protocol to the pickle protocol.

> should we add
> a reduce method to the proxy that calculates the object state using
> NSCoder (where possible)?

That sounds fine.

> It might also be possible to provide a
> default implementation of initWithCoder: and encodeWithEncoder: if
> the parent class implements those.

> The default encodeWithEncoder: implementation would call the
> superclass implementatation, then a NSDictionary containing the
> Objective-C instance variables and python __slots__ and then an
> NSDictionary containing the python __dict__.
> 
> The __reduce__ method would use the result of [self
> encodeWithEncoder:] as the object state, and the restore function
> would use that state to restore the object using initWithCoder:.
> 
> Does this look like a valid approach? If it is I'll probably file a
> bug report containing this scheme (I don't think I'll get around to
> implementing this anytime soon).

The __reduce__ part of the pickle protocol is completely new to me, so I
can't offer any advice at the moment. I'll try to find the time to look
into it. Opening a feature-request-bug is definitely a good idea.

Just

[Pyobjc-dev] pythonify_c_value oddities

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

I noticed values of type 'char' are translated into integers when going 
from Objective-C to python. I'd expect a string of length 1.

IMHO depythonify_c_value is a bit to strict in the values it accepts. 
As an example: when translating to an Objective-C int it won't accept a 
Python long. Should we use PyArg_Parse to convert Python objects to 
basic C types? This would at least make us consistent with other 
extension modules, even though PyArg_Parse doesn't deal (yet?) with 
unsigned types.

I've currently dealt with this adding more code: We now accept python 
longs where we accepts ints (and the other way around).

While I was busy I also adding some range-checking code: Conversions to 
Objective-C only succeed if the Python number is within the range 
accepted by the C type. The checks are currently very strict, if this 
proves to be too strict we can relax the rules a little (at least for 
unsigned native types).

There is no range checking for floating point numbers, I'll leave that 
for someone who's knows more about the issues around floating point 
calculations.

Ronald

[Pyobjc-dev] pickled Objective-C objects

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

I noticed the other day that our unicode subclass doesn't support 
pickling. Should we add support for pickling, and if so how? Should 
instances of our subclass be pickled just like 'normal' unicode objects 
(although I have no idea how to do that), or as NSString values?

Normal Objective-C classes also don't support pickling, should we add a 
reduce method to the proxy that calculates the object state using 
NSCoder (where possible)? It might also be possible to provide a 
default implementation of initWithCoder: and encodeWithEncoder: if the 
parent class implements those.

The default encodeWithEncoder: implementation would call the superclass 
implementatation, then a NSDictionary containing the Objective-C 
instance variables and python __slots__ and then an NSDictionary 
containing the python __dict__.

The __reduce__ method would use the result of [self encodeWithEncoder:] 
as the object state, and the restore function would use that state to 
restore the object using initWithCoder:.

Does this look like a valid approach? If it is I'll probably file a bug 
report containing this scheme (I don't think I'll get around to 
implementing this anytime soon).

Ronald

Re: [Pyobjc-dev] A bit of a mess....

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

On Saturday, Feb 22, 2003, at 23:39 Europe/Amsterdam, Bill Bumgarner 
wrote:

> The Cocoa directory now contains the bridging of Foundation, AppKit, 
> Preference Panes, and InterfaceBuilder.
>
> Why?

History? It's mostly because of the scripts in Modules/Cocoa/scripts, 
but your right this should be cleaned up.

>
> This seems like a big mess and is only going to get worse over time.   
> It also-- I would think-- hampers GnuStep support in that not all of 
> the frameworks are available under GnuStep or, if there, are 
> completely different.

The current situation doesn't really hamper GNUstep support, setup.py 
checks if frameworks are present before building the support modules. 
The right solution would probably be to move the scripts in 
Modules/Cocoa/scripts to the toplevel scripts directory and integrate 
them into setup.py. That way we'd automaticly wrap only those items 
that are supported on a system.

Let's move the script first and worry about the side-effects of calling 
them from setup.py later.


>
> If we are going to fix this, we should do it now.  Preferably, the 
> various framework specific modules should be encapsulated in their own 
> directories.   Some of the framework support should potentially even 
> be moved out of the pyobjc root source as it is less about bridging to 
> the core of ObjC and more about bridging a specific framework's worth 
> of functionality.

Just like in Lib there should be one directory for every supported 
framework in Modules. I don't want to move frameworks from the pyobjc 
source tree unless supporting them cost too much time or someone steps 
up to maintain them in a seperate distribution.

For me as a *user* of PyObjC the most interesting part are the bridged 
frameworks, the objc module just happens to be the most usefull way to 
bridge these frameworks.

BTW. Feel free to move files around, I'd like to concentrate on fixing 
some bugs in libffi_support.m: structure returns aren't working at the 
moment.

Ronald

[Pyobjc-dev] A bit of a mess....

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

The Cocoa directory now contains the bridging of Foundation, AppKit, 
Preference Panes, and InterfaceBuilder.

Why?

This seems like a big mess and is only going to get worse over time.   
It also-- I would think-- hampers GnuStep support in that not all of 
the frameworks are available under GnuStep or, if there, are completely 
different.

If we are going to fix this, we should do it now.  Preferably, the 
various framework specific modules should be encapsulated in their own 
directories.   Some of the framework support should potentially even be 
moved out of the pyobjc root source as it is less about bridging to the 
core of ObjC and more about bridging a specific framework's worth of 
functionality.

b.bum

Re: [Pyobjc-dev] Subclassing in Interface Builder

[Tony L. <to...@lo...>]

At 11:51 AM -0500 2/21/03, bb...@ma... wrote:
>On Friday, Feb 21, 2003, at 11:45 US/Eastern, Just van Rossum wrote:
>>I'm just guessing, but perhaps you need to override awakeFromNib
>>instead?
>
>Right.  This is one of the more subtle aspects of IB based 
>programming.  The objects are archived within the NIB and, upon nib 
>loading, are reconstituted from the archive, not instantiated. 
>Hence, the designated initializer will not be called.
>
>-awakFromNib is one possibility -- very useful because all 
>connections have been made.
>
>I beliver this is also an initWithCoder: or something like it that 
>can be used earlier.

awakeFromNib: works perfectly. Thanks all.

While we're talking about subtle aspects of IB programming... I have 
a few NSImageView controls on my window. The controls all have a 
custom class so that they can accept drag and drop operations.

I would like to use the "target" outlet so I can make connections in 
IB between my view and actions on my controller. I can make the 
connection, but actually invoking it doesn't seem to work.

Here is what I have tried:


     def performDragOperation_(self, sender):
         pasteboard = sender.draggingPasteboard()
         self._extract_pasteboard_info(pasteboard)
         try:
              print "action:", self.action(), "target:", self.target()
              self.sendAction_to_(self.action(), self.target())
         except:
             import traceback
             traceback.print_exc()
         return YES

The action() and target() accessors return None despite being hooked up in IB.

The one bit of sample Objective C code I found used instance 
variables, not accessors, and those instance variables are not 
available to PyObjC:

/Developer/Examples/InterfaceBuilder/bMoviePalette/SoundFileWell.m:

92:        [self sendAction:_action to:_target];

-Tony

Re: [Pyobjc-dev] Subclassing in Interface Builder

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

On Friday, Feb 21, 2003, at 11:45 US/Eastern, Just van Rossum wrote:
>> class MyImageView(AutoBaseClass):
>>      def initWithFrame_(self, frame):
>>          self = NSImageView.initWithFrame_(self, frame)
>>          print "never gets here"
>>          return self
>>
>> Has anyone seen this before?
>
> I'm just guessing, but perhaps you need to override awakeFromNib
> instead?

Right.  This is one of the more subtle aspects of IB based programming. 
  The objects are archived within the NIB and, upon nib loading, are 
reconstituted from the archive, not instantiated.  Hence, the 
designated initializer will not be called.

-awakFromNib is one possibility -- very useful because all connections 
have been made.

I beliver this is also an initWithCoder: or something like it that can 
be used earlier.

b.bum

Re: [Pyobjc-dev] Subclassing in Interface Builder

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

Tony Lownds wrote:

> Hi,
> 
> I am making a subclass of NSImageView in interface builder. The 
> subclass does get made but overrided initializers don't seem to get 
> called:
> 
> class MyImageView(AutoBaseClass):
>      def initWithFrame_(self, frame):
>          self = NSImageView.initWithFrame_(self, frame)
>          print "never gets here"
>          return self
> 
> Has anyone seen this before?

I'm just guessing, but perhaps you need to override awakeFromNib
instead?

Just