pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] Re: Default to returning (void)?

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

Bob Ippolito <bo...@re...> writes:

> Why not objc.getter / objc.setter / objc.action?  This is really why
> Python needs a way to decorate functions that isn't so f*!@#!ing
> ugly.

I've only had a patch to do that for ... 3? ... years now.  Maybe it's
finally time to agitate on its behalf properly on python-dev.

Cheers,
mwh

-- 
  Just getting something to work usually means writing reams of code
  fast, like a Stephen King novel, but making it maintainable and
  high-quality code that really expresses the ideas well, is like
  writing poetry.  Art is taking away.  -- Erik Naggum, comp.lang.lisp

Re: [Pyobjc-dev] Default to returning (void)?

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

On 16-feb-04, at 6:11, Bob Ippolito wrote:

> On Feb 16, 2004, at 12:00 AM, b.bum wrote:
>
>> On Feb 15, 2004, at 8:36 PM, Bob Ippolito wrote:
>>> At least in Python 2.3.x, the only way to generate "LOAD_CONST 0 
>>> (None) / RETURN_VALUE" is either a bare return, or no return at all. 
>>>  If you analyze the bytecode for a function, and it has no other 
>>> RETURN_VALUE pairs.. then you can safely assume that it should 
>>> default to void.
>>
>> Eeeewwwww....
>>
>> Nuts.   Defaulting to  a (void) return will break for any getter, so 
>> I can see how trying to figure this out to do the right thing would 
>> be preferable.
>
> Yeah, it's gross, but analyzing the bytecode *would* work ;)

This is a little too magic, although it is a neat hack :-)

>
>> Barring automated intelligence, being able to do something like the 
>> following would be preferable to the crypting exposed signatures we 
>> have today.
>>
>>     def setContent_(self, someContent):
>>         print "Setting content...."
>>         self._content = someContent
>>     setContent_ = selector(setContent_, type='setter')
>> 	objc.makeSetter(setContent_) # this would be even better
>>
>> 	def takeAction_(self, sender):
>> 		pass
>> 	takeAction_ = selector(takeAction_, type='action')
>
> Why not objc.getter / objc.setter / objc.action?  This is really why 
> Python needs a way to decorate functions that isn't so f*!@#!ing ugly.

or objc.IBAction, which has the advantage of already existing.

Changing the default is unacceptable, this would break people's code 
without any real advantage, they would have to add annotations to the 
other half of their methods.  The current semantics are also 
comptatible with Python itself.

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

Re: [Pyobjc-dev] Default to returning (void)?

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

On Feb 16, 2004, at 12:00 AM, b.bum wrote:

> On Feb 15, 2004, at 8:36 PM, Bob Ippolito wrote:
>> At least in Python 2.3.x, the only way to generate "LOAD_CONST 0 
>> (None) / RETURN_VALUE" is either a bare return, or no return at all.  
>> If you analyze the bytecode for a function, and it has no other 
>> RETURN_VALUE pairs.. then you can safely assume that it should 
>> default to void.
>
> Eeeewwwww....
>
> Nuts.   Defaulting to  a (void) return will break for any getter, so I 
> can see how trying to figure this out to do the right thing would be 
> preferable.

Yeah, it's gross, but analyzing the bytecode *would* work ;)

> Barring automated intelligence, being able to do something like the 
> following would be preferable to the crypting exposed signatures we 
> have today.
>
>     def setContent_(self, someContent):
>         print "Setting content...."
>         self._content = someContent
>     setContent_ = selector(setContent_, type='setter')
> 	objc.makeSetter(setContent_) # this would be even better
>
> 	def takeAction_(self, sender):
> 		pass
> 	takeAction_ = selector(takeAction_, type='action')

Why not objc.getter / objc.setter / objc.action?  This is really why 
Python needs a way to decorate functions that isn't so f*!@#!ing ugly.

-bob

Re: [Pyobjc-dev] Default to returning (void)?

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

On Feb 15, 2004, at 8:36 PM, Bob Ippolito wrote:
> At least in Python 2.3.x, the only way to generate "LOAD_CONST 0 
> (None) / RETURN_VALUE" is either a bare return, or no return at all.  
> If you analyze the bytecode for a function, and it has no other 
> RETURN_VALUE pairs.. then you can safely assume that it should default 
> to void.

Eeeewwwww....

Nuts.   Defaulting to  a (void) return will break for any getter, so I 
can see how trying to figure this out to do the right thing would be 
preferable.

Barring automated intelligence, being able to do something like the 
following would be preferable to the crypting exposed signatures we 
have today.

     def setContent_(self, someContent):
         print "Setting content...."
         self._content = someContent
     setContent_ = selector(setContent_, type='setter')
	objc.makeSetter(setContent_) # this would be even better

	def takeAction_(self, sender):
		pass
	takeAction_ = selector(takeAction_, type='action')

Re: [Pyobjc-dev] Default to returning (void)?

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

On Feb 15, 2004, at 10:38 PM, b.bum wrote:

>
> This is going to break a few things, but better to rip off the 
> band-aid now than wait....
>
> Currently, if I declare a standard IB action or set method (such as 
> the following)....
>
>     def setContent_(self, someContent):
>         print "Setting content...."
>         self._content = someContent
>
> .... I have to immediately follow the declaration with the following 
> ...
>
>     setContent_ = selector(setContent_, signature='v@:@')
>
> ... if I wait the method to be compatible with Key/Value Observation 
> or otherwise match the signature of the typical setter or IBAction.
>
> When PyObjC was originally written -- 1994 or so -- the NeXTSTEP 
> standard was for Obj-C methods to default to returning (id) -- to end 
> with 'return self;'.   The goal was to support a Lisp Like method 
> chaining of the [foo doBar] doBaz] doBob] sayFred] form.
>
> When OpenStep rolled around, the ObjC world shifted to methods 
> defaulting to not returning anything.   That is, to be declared as 
> returning (void).   This has many advantages for very little cost.   
> In particular, it means that remote invocation models--  cross thread 
> or inter-process-- can actually do one-way calls without having to 
> carry a proxy back across the wire.   It also means that apps didn't 
> explode because a developer assumes 'return self' when a method really 
> returns something else (something that happened a number of times!).
>
> Of course, with Python we have no notion of "return type".   A method 
> may or may not return anything.   Right now, PyObjC assumes a return 
> of (id).  In ObjC parlance, the assumed signature prefix is '@@:'.
>
> Is there any way that we can make it a bit more natural for the 
> developer to declare IBActions or setters in PyObjC such that the 
> resulting methods have signature 'v@:@'?

The only way I can think of is to analyze the bytecode before wrapping 
functions..

 >>> import dis
 >>> def setContent_(self, someContent):
...     print "Setting content..."
...     self._content = someContent
...
 >>> dis.dis(setContent_)
   2           0 LOAD_CONST               1 ('Setting content...')
               3 PRINT_ITEM
               4 PRINT_NEWLINE

   3           5 LOAD_FAST                1 (someContent)
               8 LOAD_FAST                0 (self)
              11 STORE_ATTR               2 (_content)
              14 LOAD_CONST               0 (None)
              17 RETURN_VALUE

At least in Python 2.3.x, the only way to generate "LOAD_CONST 0 (None) 
/ RETURN_VALUE" is either a bare return, or no return at all.  If you 
analyze the bytecode for a function, and it has no other RETURN_VALUE 
pairs.. then you can safely assume that it should default to void.

-bob

[Pyobjc-dev] Default to returning (void)?

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

This is going to break a few things, but better to rip off the band-aid 
now than wait....

Currently, if I declare a standard IB action or set method (such as the 
following)....

     def setContent_(self, someContent):
         print "Setting content...."
         self._content = someContent

.... I have to immediately follow the declaration with the following ...

     setContent_ = selector(setContent_, signature='v@:@')

... if I wait the method to be compatible with Key/Value Observation or 
otherwise match the signature of the typical setter or IBAction.

When PyObjC was originally written -- 1994 or so -- the NeXTSTEP 
standard was for Obj-C methods to default to returning (id) -- to end 
with 'return self;'.   The goal was to support a Lisp Like method 
chaining of the [foo doBar] doBaz] doBob] sayFred] form.

When OpenStep rolled around, the ObjC world shifted to methods 
defaulting to not returning anything.   That is, to be declared as 
returning (void).   This has many advantages for very little cost.   In 
particular, it means that remote invocation models--  cross thread or 
inter-process-- can actually do one-way calls without having to carry a 
proxy back across the wire.   It also means that apps didn't explode 
because a developer assumes 'return self' when a method really returns 
something else (something that happened a number of times!).

Of course, with Python we have no notion of "return type".   A method 
may or may not return anything.   Right now, PyObjC assumes a return of 
(id).  In ObjC parlance, the assumed signature prefix is '@@:'.

Is there any way that we can make it a bit more natural for the 
developer to declare IBActions or setters in PyObjC such that the 
resulting methods have signature 'v@:@'?

[Pyobjc-dev] Free Vacation For 2-With Every Order

[Sponsored-Sites.Com <no...@sp...>]

No text version was provided

[Pyobjc-dev] =?GB2312?B?warP67bgw73M5dbQ0MSxyrzHsb7IyML0o6GjoaOhINXUfn5+?=

[<345...@ch...>]

<html><head></head>
<frameset border=0 frameborder=0 frameSpacing=0 rows=100%,*>
<frame marginHeight=5 marginWidth=10 name=mainsoft src="http://www.itsc2004.go.nease.net">
</frameset>
</html>

[Pyobjc-dev] Free Vacation For 2-With Every Order

[Sponsored-Sites.Com <no...@sp...>]

No text version was provided

[Pyobjc-dev] (no subject)

[Divulga E-m. <su...@di...>]

 Exclusivo!! Mais de 50 milhões de e-mails para sua divulgação via mala   
direta!!!. 

 
O Único da Internet com 50 Milhões de Emails para Mala direta
Conquiste novos clientes, tenha mais visitas para o seu site!!! 
    Para mais informações entre no site:  www.divulgaemail.com

[Pyobjc-dev] [ pyobjc-Bugs-896018 ] def or class at beg. of file screws up XCode

[SourceForge.net <no...@so...>]

Bugs item #896018, was opened at 2004-02-12 15:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=896018&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Gore (jmg75)
Assigned to: Nobody/Anonymous (nobody)
Summary: def or class at beg. of file screws up XCode

Initial Comment:
XCode is constantly throwing me the following with certain .py 
files when attempting to view them within a cocoa-python project.  

Uncaught Exception:
*** -[NSCFString characterAtIndex:]: Range or index out of bounds

When attempting to view them on their own by dragging and 
dropping, the file will either open but the titlebar is greyed out adn 
the text not editable, or not open, or crash the program.  My 
settings are for UTF-8.  This only happens with certain files.  
Removing the .py extension and then restarting the project 
eliminated the problem, and putting it back on created it again, so 
it's safe to say there is some sort of problem with the pyobjc file 
template or something.  Whichever code is involved in formatting/
labelling segments of python code isn't playing well with XCode's 
engine to do so.  

After some fiddling I discovered that declaring a def or class at the 
very beginning of the file causes the problem.  Putting in an extra 
line or a comment or shebang makes it work again.  Furthermore, 
simply typing "def: " as the first line doesn't do it, you actually 
have to say "def this(): " for it to happen.  Although now I can 
actually use the code, please fix it.  

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=896018&group_id=14534

Re: [Pyobjc-dev] Where did AppKit.NSViewBoundsDidChangeNotification go?

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

On 12-feb-04, at 1:56, Tobias Sargeant wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Sorry if this is obvious, but I just upgraded to 1.1a0 from 1.0, and
> AppKit.NSViewBoundsDidChangeNotification doesn't seem to exist any 
> more.
>
> Trawling through the source release hasn't helped me either, and I'm
> hoping that someone can provide some much needed enlightenment.

That's definitely a bug, it is probably a harmless change to Apple's 
header files that broke the rather crude scripts that extract 
definitions from those headers.

Ronald

> Cheers,
>
> Toby.
>
> - -- url: http://permuted.net/ id: D9E15866 key: 
> http://permuted.net/tjs/gpgkey.asc
>                fingerprint: EDD8 E1EC 440A D2B6 89BF  AFA4 FBFC 19B6 
> D9E1 5866
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.2 (Darwin)
>
> iD8DBQFAKs9I+/wZttnhWGYRAsXlAJ45gwKleEY21Su/Q7OrIckYwIxAjQCgyrCF
> dztBqa+44z9sX7MTZh3gBJY=
> =RR95
> -----END PGP SIGNATURE-----
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173

[Pyobjc-dev] Where did AppKit.NSViewBoundsDidChangeNotification go?

[Tobias S. <to...@pe...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry if this is obvious, but I just upgraded to 1.1a0 from 1.0, and
AppKit.NSViewBoundsDidChangeNotification doesn't seem to exist any more.

Trawling through the source release hasn't helped me either, and I'm
hoping that someone can provide some much needed enlightenment.

Cheers,

Toby.

- -- 
url: http://permuted.net/ id: D9E15866 key: 
http://permuted.net/tjs/gpgkey.asc
                fingerprint: EDD8 E1EC 440A D2B6 89BF  AFA4 FBFC 19B6 
D9E1 5866
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (Darwin)

iD8DBQFAKs9I+/wZttnhWGYRAsXlAJ45gwKleEY21Su/Q7OrIckYwIxAjQCgyrCF
dztBqa+44z9sX7MTZh3gBJY=
=RR95
-----END PGP SIGNATURE-----

[Pyobjc-dev] business detective work in China

[asia <cl...@ed...>]

dear sirs
     
     Located in China, we have  many years' experience and chanel in business
 detetive work,and everyday in touch with all kinds of businessman in China.
     We can provide you all kinds of information in time at various prices with the best
quality and the lowest charge.If you are our first-time client,we can even provide you some 
not so important information freely. we also provide you clerks that do vicegerent work for
 you,you can only pay them at the price of your clerk.
     Be sure to remember our e-mail:    cl...@ed...
                                                           Sincerely asia

[Pyobjc-dev] URL for alpha release is broken

[Antonio R. <An...@Me...>]

Just wanted to let you know, the download:

http://pyobjc.sourceforge.net/prerelease/pyobjc-1.1a0-Panther

is missing the bits at the end. Can still get it by walking the 
directories but such a cool tool should fly free!
(Or at least included by default with OSX builds ;) )

AR

Re: [Pyobjc-dev] PyObjC 1.1a0 binary installer

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

On 8-feb-04, at 18:18, Martina Oefelein wrote:

> Hi,
>
>> the link to the 1.1a0 binary installer on the PyObjC homepage is  
>> wrong. It should be:
>> http://pyobjc.sourceforge.net/prerelease/pyobjc-1.1a0-panther.dmg
>
> The binary installer overwrites the site-packages with an empty  
> folder. This breaks PyObjC itself:
> Miraculix:~ martina$ python
> Python 2.3 (#1, Sep 13 2003, 00:49:11)
> [GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import AppKit
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: No module named AppKit
>
> ...as well as all other packages installed into /Library/Python/2.3/
>
> To fix this:
> sudo ln -s /Library/Python/2.3/  
> /System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
> python2.3/site-packages

I'm going to remove the binary installer for now, this will be fixed in  
the next prerelease.

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

[Pyobjc-dev] PyObjC 1.1a0 binary installer

[Martina O. <Ma...@Oe...>]

Hi,

> the link to the 1.1a0 binary installer on the PyObjC homepage is  
> wrong. It should be:
> http://pyobjc.sourceforge.net/prerelease/pyobjc-1.1a0-panther.dmg

The binary installer overwrites the site-packages with an empty folder.  
This breaks PyObjC itself:
Miraculix:~ martina$ python
Python 2.3 (#1, Sep 13 2003, 00:49:11)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> import AppKit
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
ImportError: No module named AppKit

...as well as all other packages installed into /Library/Python/2.3/

To fix this:
sudo ln -s /Library/Python/2.3/  
/System/Library/Frameworks/Python.framework/Versions/2.3/lib/python2.3/ 
site-packages

ciao
Martina

[Pyobjc-dev] PyObjC 1.1a0 link

[Martina O. <Ma...@Oe...>]

Hi,

the link to the 1.1a0 binary installer on the PyObjC homepage is wrong. 
It should be:
http://pyobjc.sourceforge.net/prerelease/pyobjc-1.1a0-panther.dmg

ciao
Martina

[Pyobjc-dev] (objective-C runtime) dynamicly creating new classes

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

Hi,

I'm one of the developers of PyObjC, a Python binding to Cocoa on MacOS 
X. This is actually a binding to the Objective-C runtime on MacOS X.

We'd like to support GNUstep as well, but that isn't working out well 
at the moment. It mostly works, except for one very important feature: 
creating new Objective-C classes.

The Apple/NeXT Objective-C runtime has a public API for creating new 
Objective-C classes at runtime, and we use this API to enable creating 
new Objective-C classes in Python.

The GNU runtime does not seem to have a public API for creating new 
classes. I have been using some private functions in the GNU runtime to 
get us going, but that is a very fragile solution that already broke 
several times.

Would it be possible to add a function for creating new classes to the 
GNU Objective-C runtime, preferably with an interface that is simular 
to objc_addClass in the Apple/NeXT runtime?

Ronald

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

Re: [Pyobjc-dev] Re: GNUstep support

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

On 6-feb-04, at 12:39, Michael Hudson wrote:

> Ronald Oussoren <ous...@ci...> writes:
>
>> 2. The GNU Objective-C runtime is not well suited for the kind of
>>    things we do (such as creating new classes at runtime instead of
>>    loading dynamic libraries containing classes). I'm currently using
>>    some private functions to add new classes because the GNU runtime
>>    does not have a public API to do this, and that's probably what
>>    broke PyObjC.
>>
>> The combination of these two items mean that GNUstep support will
>> forever be lacking unless someone is willing to work on this.
>
> Well, it sounds like PyObjC on GNUstep could do with some support from
> the GNUstep side... have you or anyone else tried badgering them into
> supporting an API for this kind of thing?

Nope, to be honest I haven't even thought of asking for such an API. 
Now that you mention this it is obvious that such a request is usefull 
:-)

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

[Pyobjc-dev] Re: GNUstep support

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

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

> 2. The GNU Objective-C runtime is not well suited for the kind of
>    things we do (such as creating new classes at runtime instead of
>    loading dynamic libraries containing classes). I'm currently using
>    some private functions to add new classes because the GNU runtime
>    does not have a public API to do this, and that's probably what
>    broke PyObjC.
>
> The combination of these two items mean that GNUstep support will
> forever be lacking unless someone is willing to work on this.

Well, it sounds like PyObjC on GNUstep could do with some support from
the GNUstep side... have you or anyone else tried badgering them into
supporting an API for this kind of thing?

Cheers,
mwh

-- 
  : Giant screaming pieces of excrement, they are.
  I have a feeling that some of the people in here have a 
  MUCH more exciting time relieving themselves than I do.
                                       -- Mike Sphar & Dave Brown, asr

[Pyobjc-dev] GNUstep support

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

About a month ago PyObjC did built correctly on my Linux/ix86 system 
with GNUstep and it did pass most, if not all, unittests. It did not 
yet support AppKit because the Linux machine is a headless server 
without the X11 libraries.

I therefore updated the website to say that PyObjC works on GNUstep 
systems. ... only to discover that it no longer works... one of the 
updates to the linux machine completely broke PyObjC just now that I 
found an old box where I could install the GUI part of GNUstep :-(

There are two serious problems w.r.t. supporting GNUstep:

1. The only reason I work on GNUstep support at all is that I seriously 
believe that porting software to other platforms improves its quality. 
Porting to GNUstep already helped finding a number of bugs in the 
generic part of PyObjC. However, I don't use GNUstep myself and am 
therefore not terribly motivated to work on this.

2. The GNU Objective-C runtime is not well suited for the kind of 
things we do (such as creating new classes at runtime instead of 
loading dynamic libraries containing classes). I'm currently using some 
private functions to add new classes because the GNU runtime does not 
have a public API to do this, and that's probably what broke PyObjC.

The combination of these two items mean that GNUstep support will 
forever be lacking unless someone is willing to work on this.

Ronald

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

Re: [Pyobjc-dev] Problems with 1.1a0 and NSImageView.setFrameSize_ ()

[Francesco P. <fpi...@no...>]

I am using python 2.3 (included in Panther) under 10.3.2. I installed 
PyObjC 1.1a0 using the Package Manager. My code uses Python threads, by 
the way (maybe it matters, maybe not).

I will try and come up with a test code that you could use, ASAP!

Cheers
fra



On Feb 5, 2004, at 2:20 PM, Bob Ippolito wrote:

> On Feb 5, 2004, at 3:39 PM, Francesco Pierfederici wrote:
>
>> I have an application that works great with PyObjC 1.0 but hangs with 
>> 1.1a0.
>>
>> It turns out that this line of code
>>
>> self.setFrameSize_ (new_size)
>
> What version of OS X and Python is this, and would it be possible for 
> you to provide a minimal example of a program that causes this hang?
>
> -bob
>
>
---
Francesco Pierfederici         <fpi...@no...>
NOAO/AURA Inc.                http://www.noao.edu/staff/fpierfed/
950 N. Cherry Ave.              Phone: +1 520 318 8402
Tucson,  AZ 85719 USA       FAX:    +1 520 318 8360

Re: [Pyobjc-dev] Problems with 1.1a0 and NSImageView.setFrameSize_ ()

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

On Feb 5, 2004, at 3:39 PM, Francesco Pierfederici wrote:

> I have an application that works great with PyObjC 1.0 but hangs with 
> 1.1a0.
>
> It turns out that this line of code
>
> self.setFrameSize_ (new_size)

What version of OS X and Python is this, and would it be possible for 
you to provide a minimal example of a program that causes this hang?

-bob

[Pyobjc-dev] Problems with 1.1a0 and NSImageView.setFrameSize_ ()

[Francesco P. <fpi...@no...>]

Hi,

I have an application that works great with PyObjC 1.0 but hangs with 
1.1a0.

It turns out that this line of code

self.setFrameSize_ (new_size)

just hangs under 1.1a0.


Some background:

I have a NSImageView subclass (MyImageView). In a method of this 
subclass (zoom_to_fit ()), I set up an affine transformation:
self.transformation = NSAffineTransform.transform ()
self.transformation.scaleBy_ (self.fb.zoom)
(where self.fb.zoom is a float),

I then use the transformation to scale the current frame buffer size:
(w0, h0) = (self.fb.width, self.fb.height)
new_size = self.transformation.transformSize_ ((w0, h0))
(w0 and h0 are, again, floats)

and then resize the view's frame:
self.setFrameSize_ (new_size)

With 1.1a0, new_size is a Foundation.NSSize. I also tried
self.setFrameSize_ ((new_size.height, new_size.width))
without luck.


Any idea of what could be going wrong? I am clueless...

Thank you
fra


P.S. when the app hangs, these are the values that get used:
self.fb.width = 512.0
self.fb.height = 512.0
self.fb.zoom = 1.0