pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Re: Structs, tuples and instances

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

On 31 Oct 2003, at 15:14, Michael Hudson wrote:

> Ronald Oussoren <ous...@ci...> writes:
>
>> On 31 okt 2003, at 11:54, Jack Jansen wrote:
>>
>>> Hmm, even if it isn't available from Python the objc core could make
>>> it available. Using structmember for the various toolbox structures
>>> is something that's also on my to-do list, but I haven't done
>>> anything about it yet so I don't know how feasible this approach is.
>>
>> Do you mean the new PyStructSequence_Type as used by os.stat and
>> time.localtime?
>
> Ah, that would be more likely than what he actually said :-)

Right:-)

>> Those "structures" are (sadly) read-only. I'm thinking of ...
>
> If you do do something about this, it might be worth offering a patch
> to Python itself; tcgetattr at least could use such functionality.

I'd love that... As I said I could put it to good use for the various 
Mac toolbox objects.
--
Jack Jansen        <Jac...@cw...>        http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma 
Goldman

[Pyobjc-dev] Re: Structs, tuples and instances

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

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

> On 31 okt 2003, at 11:54, Jack Jansen wrote:
>
>> Hmm, even if it isn't available from Python the objc core could make
>> it available. Using structmember for the various toolbox structures
>> is something that's also on my to-do list, but I haven't done
>> anything about it yet so I don't know how feasible this approach is.
>
> Do you mean the new PyStructSequence_Type as used by os.stat and
> time.localtime?

Ah, that would be more likely than what he actually said :-)

> Those "structures" are (sadly) read-only. I'm thinking of ...

If you do do something about this, it might be worth offering a patch
to Python itself; tcgetattr at least could use such functionality.

Cheers,
mwh

-- 
  I'm not particularly fond of singing GSTQ because she stands for
  some things I don't, but it's not really worth letting politics
  getting in the way of a good bawling.     -- Dan Sheppard, ucam.chat

Re: [Pyobjc-dev] Structs, tuples and instances

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

On 31 okt 2003, at 11:54, Jack Jansen wrote:

>
> On 30 Oct 2003, at 10:36, Dinu Gherman wrote:
>
>> Hi,
>>
>> I'm trying to fake some kind of a solution which is more struct-like
>> than plain Python tuples for things like NSPoint, NSSize, etc. Here's
>> a simple one:
>>
>> class NSPoint:
>
> I don't have a real reason for it, but my gut feeling is that the 
> Pythonic way to do this is the other way around: use a list as the 
> baseclass, and subclass that. Actually, what you really want (I think) 
> is something based on structmember, but I don't know whether that 
> allows read/write access, and whether it's available from Python code.
>
> Hmm, even if it isn't available from Python the objc core could make 
> it available. Using structmember for the various toolbox structures is 
> something that's also on my to-do list, but I haven't done anything 
> about it yet so I don't know how feasible this approach is.

Do you mean the new PyStructSequence_Type as used by os.stat and 
time.localtime? Those "structures" are (sadly) read-only. I'm thinking 
of adding a generic method for creating struct-like types, which could 
then be used to define NSPoint, NSRect, ... as a type.

Something like this:

	def struct_type(name, signature, *fieldnames):
		"""
		implemented in C, return a new type

		the signature is used to type-check assignments, could be left out.
		"""
		pass

	
	NSPoint = objc.struct_type("NSPoint", "{_NSPoint=ff}", "x", "y")

	val = NSPoint(1.0, 2.0)
	x = val.x
	x = val[0]
	y = val.y
	y = val[1]

	val.x = 2.0
	val[1] = 3

There would also be a C-level API for creating types and instances of 
it, this would be used to make sure that ObjC API's returning an 
NSPoint would actually create an instance of the NSPoint type defined 
earlier, instead of a tuple.

Ronald
> --
> Jack Jansen        <Jac...@cw...>        http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma 
> Goldman
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?   SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] Re: Structs, tuples and instances

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

Jack Jansen <Jac...@cw...> writes:

> On 30 Oct 2003, at 10:36, Dinu Gherman wrote:
>
>> Hi,
>>
>> I'm trying to fake some kind of a solution which is more struct-like
>> than plain Python tuples for things like NSPoint, NSSize, etc.

This I can certainly sympathise with; I have some code like

   v1.setFrameOrigin_((0, v2.frame()[0][1] + v3.frame()[1][1]))

which isn't especially clear.

>> Here's a simple one:
>>
>> class NSPoint:
>
> I don't have a real reason for it, but my gut feeling is that the
> Pythonic way to do this is the other way around: use a list as the
> baseclass, and subclass that.

Sounds reasonable.

> Actually, what you really want (I think)
> is something based on structmember, but I don't know whether that
> allows read/write access, 

Yes.

> and whether it's available from Python code.

No.

> Hmm, even if it isn't available from Python the objc core could make
> it available. Using structmember for the various toolbox structures is
> something that's also on my to-do list, but I haven't done anything
> about it yet so I don't know how feasible this approach is.

Well, I think the modern way is to define tp_members (think it's that
one) which uses structmember under the hood rather than using
structmember directly.

I'm not sure what "available from Python" would really mean in this
context.

Cheers,
mwh

-- 
  The only problem with Microsoft is they just have no taste.
              -- Steve Jobs, (From _Triumph of the Nerds_ PBS special)
                                and quoted by Aahz on comp.lang.python

Re: [Pyobjc-dev] Structs, tuples and instances

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

On 30 Oct 2003, at 10:36, Dinu Gherman wrote:

> Hi,
>
> I'm trying to fake some kind of a solution which is more struct-like
> than plain Python tuples for things like NSPoint, NSSize, etc. Here's
> a simple one:
>
> class NSPoint:

I don't have a real reason for it, but my gut feeling is that the 
Pythonic way to do this is the other way around: use a list as the 
baseclass, and subclass that. Actually, what you really want (I think) 
is something based on structmember, but I don't know whether that 
allows read/write access, and whether it's available from Python code.

Hmm, even if it isn't available from Python the objc core could make it 
available. Using structmember for the various toolbox structures is 
something that's also on my to-do list, but I haven't done anything 
about it yet so I don't know how feasible this approach is.
--
Jack Jansen        <Jac...@cw...>        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] No need to migrate list?

[Dinu G. <gh...@da...>]

Zachery Bir:

> Does this change anyone's preference for list migration?

Having triggered this topic, I'm fine with waiting for the next
distribution outage to come! ;-) Apart from the delays I had also
reasoned about downloadable archives, but if I'm the only one who
cares, just ignore me!

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"There are causes worth dying for, but none worth killing for."
(Albert Camus)

Re: [Pyobjc-dev] No need to migrate list?

[Zachery B. <zb...@ur...>]

On Oct 30, 2003, at 1:40 PM, Just van Rossum wrote:

> Zachery Bir wrote:
>
>>> See also
>>> https://sourceforge.net/tracker/? 
>>> func=detail&atid=200001&aid=828759&group_id=1
>>
>> Does this change anyone's preference for list migration?
>>
>> Just checking.
>
> Well, if it works ok now, why bother?

That's all I was wondering :) I've got no preference, either way. I was  
just a facilitator.

Zac

Re: [Pyobjc-dev] No need to migrate list?

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

Zachery Bir wrote:

> > See also
> > https://sourceforge.net/tracker/? 
> > func=detail&atid=200001&aid=828759&group_id=1
> 
> Does this change anyone's preference for list migration?
> 
> Just checking.

Well, if it works ok now, why bother?

Just

[Pyobjc-dev] No need to migrate list?

[Zachery B. <zb...@ur...>]

Just van Rossum wrote:

> Ronald Oussoren wrote:
>
>> BTW. The list seems to be a lot faster now that we've decided to move
>> elsewhere :-).
>
> See also
> https://sourceforge.net/tracker/? 
> func=detail&atid=200001&aid=828759&group_id=1

Does this change anyone's preference for list migration?

Just checking.

Zac

P.S. I finally got around to implementing Preferences in my app. It was  
so fast and smooth to do. Simply amazing. Thanks so much to everyone!  
:)

Re: [Pyobjc-dev] Structs, tuples and instances

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> I've just checked in some fixes, including the one mentioned above.

Well, I still get the following error below using Python 2.2.3
and libffi-src-20030921.tar.gz. On SF.net I see another snapshot
of libffi: gcc-libffisnapshot20030705-patched.tar.gz but haven't
tried it in the absence of any information about it.

Dinu


...
In file included from Modules/AppKit/_AppKit.m:627:
Modules/AppKit/_AppKitMapping_NSOpenGLPixelFormat.m: In function 
`call_NSOpenGLPixelFormat_initWithAttributes_':
Modules/AppKit/_AppKitMapping_NSOpenGLPixelFormat.m:43: warning: 
implicit declaration of function `PyInt_AsUnsignedLongMask'
gcc -bundle -bundle_loader /usr/bin/python 
build/temp.darwin-6.8-Power_Macintosh-2.2/_AppKit.o -o 
build/lib.darwin-6.8-Power_Macintosh-2.2/AppKit/_AppKit.so -framework 
CoreFoundation -framework AppKit
ld: Undefined symbols:
_PyInt_AsUnsignedLongMask
error: command 'gcc' failed with exit status 1

Re: [Pyobjc-dev] Structs, tuples and instances

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

On Oct 30, 2003, at 10:34, Ronald Oussoren wrote:

> On 30 okt 2003, at 12:02, Dinu Gherman wrote:
>
>> Ronald Oussoren:
>>
>>> I noticed that too :-( Bob introduced a Python2.3-ism when he added
>>> support for OpenGL. It works with Python 2.3 and after my next 
>>> checkin
>>> it will also work with 2.2 again.
>>
>> Thanks, please let us know when it should work again!
>
> I've just checked in some fixes, including the one mentioned above.

Yeah, sorry about that.  I intended to fix it myself, but I didn't 
think that many people were still using 2.2 so I figured it'd be ok for 
a day or two.  Why haven't you upgraded to 2.3, Dinu?

Also, back to the NSPoint thing.. how come you don't just use a list 
subclass?  Just put x and y descriptors on it:

class NSPoint(list):
     def __init__(self, v=(0., 0.)):
         list.__init__(self, v)
         assert len(self) == 2
     x = property(lambda s:s[0], lambda s,v: s.__setitem__(0,v))
     y = property(lambda s:s[1], lambda s,v: s.__setitem__(1,v))

-bob

Re: [Pyobjc-dev] Structs, tuples and instances

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

On 30 okt 2003, at 12:02, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> I noticed that too :-( Bob introduced a Python2.3-ism when he added
>> support for OpenGL. It works with Python 2.3 and after my next checkin
>> it will also work with 2.2 again.
>
> Thanks, please let us know when it should work again!

I've just checked in some fixes, including the one mentioned above.

Ronald

Re: [Pyobjc-dev] Structs, tuples and instances

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> I noticed that too :-( Bob introduced a Python2.3-ism when he added
> support for OpenGL. It works with Python 2.3 and after my next checkin
> it will also work with 2.2 again.

Thanks, please let us know when it should work again!

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." (Benjamin Franklin)

Re: [Pyobjc-dev] Structs, tuples and instances

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

On 30 okt 2003, at 11:35, Dinu Gherman wrote:

> Ronald Oussoren:
>
>> This should work better with current CVS version, that uses
>> PySequence_Fast instead of requireing a tuple.
>
> Is it supposed to compile right now? I'm getting the following
> below. Or maybe I need a fresh libffi?
>
> Dinu
>
> ...
> gcc -bundle -bundle_loader /usr/bin/python 
> build/temp.darwin-6.8-Power_Macintosh-2.2/_AppKit.o -o 
> build/lib.darwin-6.8-Power_Macintosh-2.2/AppKit/_AppKit.so -framework 
> CoreFoundation -framework AppKit
> ld: Undefined symbols:
> _PyInt_AsUnsignedLongMask
> error: command 'gcc' failed with exit status 1

I noticed that too :-( Bob introduced a Python2.3-ism when he added 
support for OpenGL. It works with Python 2.3 and after my next checkin 
it will also work with 2.2 again.

Ronald

Re: [Pyobjc-dev] Structs, tuples and instances

[Dinu G. <gh...@da...>]

Ronald Oussoren:

> This should work better with current CVS version, that uses
> PySequence_Fast instead of requireing a tuple.

Is it supposed to compile right now? I'm getting the following
below. Or maybe I need a fresh libffi?

Dinu

...
gcc -bundle -bundle_loader /usr/bin/python 
build/temp.darwin-6.8-Power_Macintosh-2.2/_AppKit.o -o 
build/lib.darwin-6.8-Power_Macintosh-2.2/AppKit/_AppKit.so -framework 
CoreFoundation -framework AppKit
ld: Undefined symbols:
_PyInt_AsUnsignedLongMask
error: command 'gcc' failed with exit status 1

Re: [Pyobjc-dev] Structs, tuples and instances

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

This should work better with current CVS version, that uses 
PySequence_Fast instead of requireing a tuple.

Ronald

[Pyobjc-dev] Structs, tuples and instances

[Dinu G. <gh...@da...>]

Hi,

I'm trying to fake some kind of a solution which is more struct-like
than plain Python tuples for things like NSPoint, NSSize, etc. Here's
a simple one:

class NSPoint:
     """An experimental NSPoint class/struct hybrid.

     This is supposed to be usable with attribute names
     as well as indices.
     """

     def __init__(self, x, y):
         self.x, self.y = x, y

     def __getitem__(self, index):
         assert index in (0, 1)
         return (self.x, self.y)[index]

     def __setitem__(self, index, value):
         assert index in (0, 1)
         setattr(self, "xy"[index], value)

Doing anything like the following:

     view = NSView.alloc().init()
     #origin = (10, 20)
     origin = NSPoint(10, 20)
     origin.x = 11
     origin[1] = 22
     print origin[0], origin[1]
     print origin.x, origin.y
     view.setFrameOrigin_(origin)

then gives me a "ValueError: depythonifying 'struct', got 'instance'"
on the last line, so I assume the background checks test for the type
of the argument and reject an instance.

What about testing only for __getitem__ and __len__? Then, I could
probably really use the type of hack above, which would make a cer-
tain kind of code much more readable?

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"I never apologize for the United States of America, I don't care what
the facts are." (George Bush, Sr.)

Re: [Pyobjc-dev] Re: NSAnyEventMask as unsigned?

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

Ronald Oussoren wrote:

> BTW. The list seems to be a lot faster now that we've decided to move 
> elsewhere :-).

See also
https://sourceforge.net/tracker/?func=detail&atid=200001&aid=828759&
group_id=1

Just

[Pyobjc-dev] OpenGL in PyObjC -- works now!

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

I added the method to create an NSOpenGLPixelFormat.. so OpenGL works 
just fine inside PyObjC/Cocoa windows now, using the standard 
subclass-a-NSOpenGLView method.  You need current CVS, and PyOpenGL.  
I've only tested in 10.3.  A port of the Apple 
/Developer/Examples/OpenGL/Cocoa/CocoaGL example is in the Examples 
tree (named OpenGLDemo).

Have fun!

-bob

Re: [Pyobjc-dev] Re: NSAnyEventMask as unsigned?

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

On Oct 29, 2003, at 11:09 AM, Bob Ippolito wrote:
>> I'm currently updating the code generator script to detect 'Mask' 
>> values and convert those as 'unsigned int' values. That should take 
>> care of this problem.
>
> Excellent.

I just updated the generator script to handle class methods, btw...  
That may conflict with your extension to deal w/custom method 
signatures?

Re: [Pyobjc-dev] Re: NSAnyEventMask as unsigned?

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

BTW. The list seems to be a lot faster now that we've decided to move 
elsewhere :-).

Ronald

Re: [Pyobjc-dev] Re: NSAnyEventMask as unsigned?

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

On Oct 29, 2003, at 2:03 PM, Ronald Oussoren wrote:

>
> On 29 okt 2003, at 19:50, Bob Ippolito wrote:
>
>>
>> On Oct 29, 2003, at 1:43 PM, Ronald Oussoren wrote:
>>
>>>
>>> On 29 okt 2003, at 19:09, Bob Ippolito wrote:
>>>>
>>>> In any case, because this is Python, any sort of bit flag or mask=20=

>>>> really needs to treated as if it were unsigned or else bad things=20=

>>>> start happening and warnings get thrown all over the place (or=20
>>>> probably break in 2.4).
>>>
>>> There won't be warnings because we create the int/long objects from=20=

>>> C, but things might still break in 2.4.
>>
>> Before I committed the fix, I got an exception when I used=20
>> NSAnyEventMask
>
> That's probably because you used NSAnyEventMask as an unsigned, and=20
> PyObjC doesn't like that. That has nothing to do with the int/long=20
> integration process (e.g. the warning you get when typing 0xFFFFFFFF=20=

> in a python script).

No, I used NSAnyEventMask as-is from AppKit, which was -1 (signed). =20
The problem is that the signature of =96[NSApplication=20
nextEventMatchingMask:untilDate:inMode:dequeue:] says that=20
nextEventMatchingMask is an unsigned (as would be expected for a set of=20=

bit flags).  I meant to mention that in my last email, but I hit send=20
before I remembered.

> I'm currently updating the code generator script to detect 'Mask'=20
> values and convert those as 'unsigned int' values. That should take=20
> care of this problem.

Excellent.

-bob

Re: [Pyobjc-dev] Re: NSAnyEventMask as unsigned?

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

On 29 okt 2003, at 19:50, Bob Ippolito wrote:

>
> On Oct 29, 2003, at 1:43 PM, Ronald Oussoren wrote:
>
>>
>> On 29 okt 2003, at 19:09, Bob Ippolito wrote:
>>>
>>> In any case, because this is Python, any sort of bit flag or mask 
>>> really needs to treated as if it were unsigned or else bad things 
>>> start happening and warnings get thrown all over the place (or 
>>> probably break in 2.4).
>>
>> There won't be warnings because we create the int/long objects from 
>> C, but things might still break in 2.4.
>
> Before I committed the fix, I got an exception when I used 
> NSAnyEventMask

That's probably because you used NSAnyEventMask as an unsigned, and 
PyObjC doesn't like that. That has nothing to do with the int/long 
integration process (e.g. the warning you get when typing 0xFFFFFFFF in 
a python script).

I'm currently updating the code generator script to detect 'Mask' 
values and convert those as 'unsigned int' values. That should take 
care of this problem.

Ronald

Re: [Pyobjc-dev] Re: NSAnyEventMask as unsigned?

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

On Oct 29, 2003, at 1:43 PM, Ronald Oussoren wrote:

>
> On 29 okt 2003, at 19:09, Bob Ippolito wrote:
>>
>> In any case, because this is Python, any sort of bit flag or mask 
>> really needs to treated as if it were unsigned or else bad things 
>> start happening and warnings get thrown all over the place (or 
>> probably break in 2.4).
>
> There won't be warnings because we create the int/long objects from C, 
> but things might still break in 2.4.

Before I committed the fix, I got an exception when I used 
NSAnyEventMask

>> It would be awesome if you could write up some quick documentation as 
>> to how to run the code generators and how to make them respect manual 
>> overrides (for signatures, at least).  I took a quick look at them, 
>> but I didn't quite get it.
>
> Running Scripts/CodeGenerators/cocoa_generator.py from the top of the 
> PyObjC tree should work. This script is spawned by setup.py as well.
>
> The protocol generator in Scripts/gen_all_protocols.py must be started 
> manually. I've just hacked in a feature to override signatures.

Great!

-bob

Re: [Pyobjc-dev] Re: NSAnyEventMask as unsigned?

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

On 29 okt 2003, at 19:09, Bob Ippolito wrote:
>
> In any case, because this is Python, any sort of bit flag or mask 
> really needs to treated as if it were unsigned or else bad things 
> start happening and warnings get thrown all over the place (or 
> probably break in 2.4).

There won't be warnings because we create the int/long objects from C, 
but things might still break in 2.4.

>
> It would be awesome if you could write up some quick documentation as 
> to how to run the code generators and how to make them respect manual 
> overrides (for signatures, at least).  I took a quick look at them, 
> but I didn't quite get it.

Running Scripts/CodeGenerators/cocoa_generator.py from the top of the 
PyObjC tree should work. This script is spawned by setup.py as well.

The protocol generator in Scripts/gen_all_protocols.py must be started 
manually. I've just hacked in a feature to override signatures.

Ronald