pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Three issues with PyObjC under Snow Leopard

[David E. <dav...@gm...>]

Great, thanks! I very much appreciate your finding the bug in the
code, but I suspect your advice to make exceptions verbose will be
more useful in the long run. This app is actually more of a test for a
larger app that I care more about that also broke when I moved to Snow
Leopard (and that I'd happy to share once I get working again — it
manages BibTeX databases — but due to the size of the code I didn't
want to even hint that anyone else try debugging). So with the verbose
exceptions in hand I can have some hope of finding out what's wrong
with that one, too, assuming it isn't just the same thing.

I've copied the setup.py I was using below, in answer to your other
email requesting it — I had a partial plist copied from the text one
in my xcode project (was intending to copy of the plist entries
eventually until I got stuck), so perhaps something in there is
confusing py2app.

"""
Script for building LaTeX Unicodifier
D. Eppstein, October 2009

Usage:
 python setup.py py2app
"""

from distutils.core import setup
import py2app

plist = {
    'CFBundleDevelopmentRegion': 'English',
    'CFBundleExecutable': 'LaTeX Unicodifier',
    'CFBundleIconFile': 'LaTeX Unicodifier.icns',
}

setup(
    app = ['Latex.py', 'LaTeX_Unicodifier.py'],
    data_files = ['English.lproj', 'LaTeX Unicodifier.icns'],
    options = { 'py2app': {'plist': plist} }
)

On Tue, Oct 6, 2009 at 6:04 AM, Ronald Oussoren <ron...@ma...> wrote:
>
> On 5 Oct, 2009, at 5:59, David Eppstein wrote:
>>
>> (2) I have some apps I wrote using pyobjc under Leopard that broke
>> when I moved to Snow Leopard. The simplest is the one in
>> http://www.ics.uci.edu/~eppstein/LaTeX_Unicodifier.dmg.gz (that's the
>> app bundle but because it's Python the source is inside, and is quite
>> short). I don't want to ask anyone to debug my code for me, but I'm at
>> a bit of a loss: when I run it (either the app as I built it for 10.5,
>> or the same xcode project recompiled for a 10.6 intel target) I get a
>> mysterious message "10/4/09 8:28:13 PM  LaTeX Unicodifier[13914]
>>  <type
>> 'exceptions.TypeError'>: Need 0 arguments, got 1" on the console and
>> it doesn't work: the UI appears, cmd-Q quits, but the actual app
>> that's supposed to be running the UI isn't there. I imagine that
>> somewhere there's a method that needs a signature and doesn't have
>> one, or something simple like that, but I can't seem to figure out how
>> to get xcode to show me who's raising the uncaught exception...
>
> There is an easy way to find the source of the exception: add
> 'objc.setVerbose(1)' to your 'main.py' file, just after the import of
> 'objc'. This will print exception tracebacks whenever exceptions cross the
> Python<->ObjC boundary.
>
> The problem is in the class Transformer, and in particular in the way you
> call the superclass initializer. Your code currently is:
>
> class Transformer (NSFormatter):
>     def initWithSource_target_(self, source, target):
>          self = NSFormatter.init(self)
>          ...
>
> This is bad style, and furthermore doesn't work in 10.6 because
> 'NSFormatter.init' refers to the init method of the NSTransformer class
> (that is the classmethod '+init'). It happens to work in 10.5 because
> NSFormatter (or NSObject) doesn't have a +init method there.
>
> The right way to call a superclass method is using the super() function:
>
> class Transformer(NSFormatter):
>
>    def initWithSource_target_(self,source,target):
>        self = super(Transformer, self).init()
>        if self is None:
>            return None
>
> The call to super() isn't very pretty, but is the standard Python way of
> calling superclass methods in new-style classes. In Python 3.x the interface
> was cleaned up ("self = super().init()"), but until PyObjC supports Python
> 3.x we'll have to live with the current syntax.
>
> BTW.  According to Apple the tests for 'self is None' is necesary, the
> superclass init might fail and return None.
>
> Ronald
>
>

Re: [Pyobjc-dev] Three issues with PyObjC under Snow Leopard

[Ronald O. <ron...@ma...>]

On 5 Oct, 2009, at 5:59, David Eppstein wrote:
>
> (2) I have some apps I wrote using pyobjc under Leopard that broke
> when I moved to Snow Leopard. The simplest is the one in
> http://www.ics.uci.edu/~eppstein/LaTeX_Unicodifier.dmg.gz (that's the
> app bundle but because it's Python the source is inside, and is quite
> short). I don't want to ask anyone to debug my code for me, but I'm at
> a bit of a loss: when I run it (either the app as I built it for 10.5,
> or the same xcode project recompiled for a 10.6 intel target) I get a
> mysterious message "10/4/09 8:28:13 PM	LaTeX Unicodifier[13914]	<type
> 'exceptions.TypeError'>: Need 0 arguments, got 1" on the console and
> it doesn't work: the UI appears, cmd-Q quits, but the actual app
> that's supposed to be running the UI isn't there. I imagine that
> somewhere there's a method that needs a signature and doesn't have
> one, or something simple like that, but I can't seem to figure out how
> to get xcode to show me who's raising the uncaught exception...

There is an easy way to find the source of the exception: add  
'objc.setVerbose(1)' to your 'main.py' file, just after the import of  
'objc'. This will print exception tracebacks whenever exceptions cross  
the Python<->ObjC boundary.

The problem is in the class Transformer, and in particular in the way  
you call the superclass initializer. Your code currently is:

class Transformer (NSFormatter):
      def initWithSource_target_(self, source, target):
           self = NSFormatter.init(self)
           ...

This is bad style, and furthermore doesn't work in 10.6 because  
'NSFormatter.init' refers to the init method of the NSTransformer  
class (that is the classmethod '+init'). It happens to work in 10.5  
because NSFormatter (or NSObject) doesn't have a +init method there.

The right way to call a superclass method is using the super() function:

class Transformer(NSFormatter):

     def initWithSource_target_(self,source,target):
         self = super(Transformer, self).init()
         if self is None:
             return None

The call to super() isn't very pretty, but is the standard Python way  
of calling superclass methods in new-style classes. In Python 3.x the  
interface was cleaned up ("self = super().init()"), but until PyObjC  
supports Python 3.x we'll have to live with the current syntax.

BTW.  According to Apple the tests for 'self is None' is necesary, the  
superclass init might fail and return None.

Ronald

Re: [Pyobjc-dev] Patch for py2app - copying another Python framework version than used to run py2app

[Ronald O. <ron...@ma...>]

On 4 Oct, 2009, at 22:52, Dirk Stoop wrote:

> Not sure if this is a good spot for py2app patches, if not please  
> let me know.
>
> This fixes an issue with copying a different version of Python over  
> to an app/plugin bundle than the one used to run py2app with.
>
> Before this patch you could run into situations where if you run  
> py2app under Python 2.6, and it tried to copy the Python 2.5  
> framework over to the app bundle, it would be at some point try to  
> copy a path like:
>
> '/Library/Frameworks/Python.framework/Versions/2.5/include/python2.6/ 
> pyconfig.h'
>
> Because it used sys.version instead of the version number in the  
> framework info passed in, to figure out what the last folder in the  
> path should be, this simple patch fixes it.

Thanks. I've pushed the patch to the repository.

Ronald

>
> <multi-py-versions-patch.txt>
>
>
> -  
> Dirk 
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Three issues with PyObjC under Snow Leopard

[Ronald O. <ron...@ma...>]

On 5 Oct, 2009, at 5:59, David Eppstein wrote:

> (1) `http://pyobjc.sourceforge.net/downloads.html tells me that I can
> update my pyobjc (currently the one that came with the Snow Leopard
> install DVD) to 2.2b1 with the command line "easy_install
> pyobjc=2.2b1". But when I try it I get the error message "error: Not a
> URL, existing file, or requirement spec: 'pyobjc=2.2b1'". Are the
> update instructions misleading or do I have a misconfiguration
> somewhere?

Don't upgrade the system version of PyObjC. It is already a fairly  
recent version, and furthermore I'm unsure it the current version is  
100% backwards compatible with the one in the system.

>
> (2) I have some apps I wrote using pyobjc under Leopard that broke
> when I moved to Snow Leopard. The simplest is the one in
> http://www.ics.uci.edu/~eppstein/LaTeX_Unicodifier.dmg.gz (that's the
> app bundle but because it's Python the source is inside, and is quite
> short). I don't want to ask anyone to debug my code for me, but I'm at
> a bit of a loss: when I run it (either the app as I built it for 10.5,
> or the same xcode project recompiled for a 10.6 intel target) I get a
> mysterious message "10/4/09 8:28:13 PM	LaTeX Unicodifier[13914]	<type
> 'exceptions.TypeError'>: Need 0 arguments, got 1" on the console and
> it doesn't work: the UI appears, cmd-Q quits, but the actual app
> that's supposed to be running the UI isn't there. I imagine that
> somewhere there's a method that needs a signature and doesn't have
> one, or something simple like that, but I can't seem to figure out how
> to get xcode to show me who's raising the uncaught exception...

I'll have a look later this week.

>
> (3) In an attempt to get around (2), I tried making a setup.py
> following the example of
> http://pyobjc.sourceforge.net/examples/pyobjc-framework-Cocoa/AppKit/CocoaBindings/CurrencyConvBinding/source--setup.py.html
> in order to create an app using py2app instead of xcode. But this,
> too, fails, with an error message
> ...
> creating build/bdist.macosx-10.6-universal/python2.6-standalone/app/ 
> lib-dynload
> creating build/bdist.macosx-10.6-universal/python2.6-standalone/app/ 
> Frameworks
> error: Multiple targets not currently supported
>
> Is there some parameter I need to set to get py2app to work or is this
> also irredeemably broken?

That's very odd, I haven't seen this error before. Another item on my  
todo list for the week...

Ronald

>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register  
> now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Three issues with PyObjC under Snow Leopard

[David E. <dav...@gm...>]

(1) `http://pyobjc.sourceforge.net/downloads.html tells me that I can
update my pyobjc (currently the one that came with the Snow Leopard
install DVD) to 2.2b1 with the command line "easy_install
pyobjc=2.2b1". But when I try it I get the error message "error: Not a
URL, existing file, or requirement spec: 'pyobjc=2.2b1'". Are the
update instructions misleading or do I have a misconfiguration
somewhere?

(2) I have some apps I wrote using pyobjc under Leopard that broke
when I moved to Snow Leopard. The simplest is the one in
http://www.ics.uci.edu/~eppstein/LaTeX_Unicodifier.dmg.gz (that's the
app bundle but because it's Python the source is inside, and is quite
short). I don't want to ask anyone to debug my code for me, but I'm at
a bit of a loss: when I run it (either the app as I built it for 10.5,
or the same xcode project recompiled for a 10.6 intel target) I get a
mysterious message "10/4/09 8:28:13 PM	LaTeX Unicodifier[13914]	<type
'exceptions.TypeError'>: Need 0 arguments, got 1" on the console and
it doesn't work: the UI appears, cmd-Q quits, but the actual app
that's supposed to be running the UI isn't there. I imagine that
somewhere there's a method that needs a signature and doesn't have
one, or something simple like that, but I can't seem to figure out how
to get xcode to show me who's raising the uncaught exception...

(3) In an attempt to get around (2), I tried making a setup.py
following the example of
http://pyobjc.sourceforge.net/examples/pyobjc-framework-Cocoa/AppKit/CocoaBindings/CurrencyConvBinding/source--setup.py.html
in order to create an app using py2app instead of xcode. But this,
too, fails, with an error message
...
creating build/bdist.macosx-10.6-universal/python2.6-standalone/app/lib-dynload
creating build/bdist.macosx-10.6-universal/python2.6-standalone/app/Frameworks
error: Multiple targets not currently supported

Is there some parameter I need to set to get py2app to work or is this
also irredeemably broken?

Re: [Pyobjc-dev] PyObjC and OSX 10.4

[Dirk S. <dir...@ma...>]

On Sep 30, 2009, at 11:12 PM, Ronald Oussoren wrote:

> Hi,
>
> Is anyone still interested in PyObjC on OSX 10.4?  I haven't done  
> any development on 10.4 in a long time and while having 10.4 support  
> would be nice to have I don't think I'll ever get around to  
> finishing 10.4 support in PyObjC 2.x.
>

We dropped Tiger support for Checkout with the latest major release  
(3.x) which is based on PyObjC 2.2, Checkout 2.x is still and will  
always remain based on PyObjC 1.4.

So we really wouldn't miss it.

- Dirk

[Pyobjc-dev] Patch for py2app - copying another Python framework version than used to run py2app

[Dirk S. <dir...@ma...>]

Not sure if this is a good spot for py2app patches, if not please let  
me know.

This fixes an issue with copying a different version of Python over to  
an app/plugin bundle than the one used to run py2app with.

Before this patch you could run into situations where if you run  
py2app under Python 2.6, and it tried to copy the Python 2.5 framework  
over to the app bundle, it would be at some point try to copy a path  
like:

'/Library/Frameworks/Python.framework/Versions/2.5/include/python2.6/ 
pyconfig.h'

Because it used sys.version instead of the version number in the  
framework info passed in, to figure out what the last folder in the  
path should be, this simple patch fixes it.

Re: [Pyobjc-dev] Initial memory usage

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

On Oct 1, 2009, at 2:26 PM, Samantha Atkins wrote:

> I am curious about this.  These tables in Objective C runtime don't take a lot of space.  What sort of overhead is introduced converting the information to pyobjc equivalents?   On the face of it I don't see why this would take a lot of memory or be all that computationally expensive.    Isn't this information needed not just for dir() but for sending any message to an objc object?  So why not pay the scan cost once at class/bundle load time and then forget about it?  Assuming it can be made reasonably efficient of course.   I guess I should finally get around to looking in the guts of this bridge.  It is somewhere on my bloated todo list.

It isn't the ObjC metadata directly, but a combination of that and the bridge support XML files;   all that XML is dragged in, shoved into data structures and kept around.

b.bum

Re: [Pyobjc-dev] PyObjC and OSX 10.4

[David B. <db3...@gm...>]

Ronald Oussoren <ron...@ma...> writes:

> Is anyone still interested in PyObjC on OSX 10.4?  I haven't done any
> development on 10.4 in a long time and while having 10.4 support would
> be nice to have I don't think I'll ever get around to finishing 10.4
> support in PyObjC 2.x.

Yes, for my part.  It would finally allow me to move a significant
application I'm maintaining off of PyObjC 1.4 and yet still support
existing older client machines.

Currently, I'm using 1.4 and generating 10.4 compatible installations
because of client need, and in fact have had to not only keep a
separate 10.4 development system, but hold back on the 10.4.11 system
update since it contains the webkit interface change that didn't work
properly with the PyObjC 1.4 wrapper.

I'm sure there are ways[*] to manually maintain two builds, but the
current discontinuity between PyObjC 1.4 on a 10.4 system for 10.4
clients, versus PyObjC 2.x on 10.5+ systems for 10.5+ clients is
unfortunate from a maintenance perspective, and something I had hoped
would eventually disappear.

I suppose an alternative to supporting 2.x under 10.4 would be to
officially declare it never to be supported, since that would at least
force the issue for me to figure out a different approach rather than
waiting for such support.

-- David

[*] I've only seen fairly complex approaches to try to have a single
development system (whether 10.4 generating 10.5+ compatible binaries,
or 10.5+ generating 10.4 compatible binaries), so in this main case
I've just frozen things in the 10.4 environment to help manage
maintenance, but I had hoped that was a near term thing until a
migration path was available.

[Pyobjc-dev] NSCreateMapTable - NSObjectMapKeyCallBacks

[Lukas P. | D. V. <lu...@dr...>]

Hi!

I was wondering if there is a way to use MapTables in PyObjC. It seems  
that NSCreateMapTable does exist
but even though the NSObjectMapKeyCallBacks constants are defined in  
the PyObjC.bridgesupport file
for the Foundation framework, the constants are not available in python.

Is there any solution to that already or any other way to use MapTables?

Lukas

Re: [Pyobjc-dev] PyObjC and OSX 10.4

[Luc H. <lu...@ho...>]

On 30 sept. 2009, at 23:12, Ronald Oussoren wrote:

> Is anyone still interested in PyObjC on OSX 10.4?  I haven't done  
> any development on 10.4 in a long time and while having 10.4 support  
> would be nice to have I don't think I'll ever get around to  
> finishing 10.4 support in PyObjC 2.x.

There are few things I would enjoy most than dropping 10.4 support in  
Miro, but we are still making our release builds of it using PyObjC  
1.4 because 15% of our users are still running 10.4. We are definitely  
getting close to a limit where dropping 10.4 support is possible but  
we're not quite there yet.

That said, our codebase is compatible with both PyObjC 1.4 and 2.x and  
since we already consider dropping 10.4 support in the not so distant  
future I probably won't push very hard for a 10.4 support of PyObjC 2  
like I would have some time ago.

Your call Ronald, obviously ;)

-- 
Luc Heinrich - lu...@ho...

Re: [Pyobjc-dev] PyObjC and OSX 10.4

[Greg E. <gre...@ca...>]

Ronald Oussoren wrote:

> Is anyone still interested in PyObjC on OSX 10.4?

Yes, I'm still using 10.4, and will be for a while
yet.

-- 
Greg

Re: [Pyobjc-dev] PyObjC and OSX 10.4

[Aahz <aa...@py...>]

On Wed, Sep 30, 2009, Ronald Oussoren wrote:
>
> Is anyone still interested in PyObjC on OSX 10.4?  I haven't done any  
> development on 10.4 in a long time and while having 10.4 support would  
> be nice to have I don't think I'll ever get around to finishing 10.4  
> support in PyObjC 2.x.

Lacking 10.4 support would be painful for me, I would probably have to
switch to making two separate builds unless PyObjC 1.4 works with Snow
Leopard.  My company has already given up on PPC support, but I think
that dropping 10.4 support will not be an option.

I note that Tiger's initial release was four years ago and that the most
recent update was two years ago.  That seems rather recent to just drop
support.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

"....Normal is what cuts off your sixth finger and your tail..."  --Siobhan

[Pyobjc-dev] PyObjC and OSX 10.4

[Ronald O. <ron...@ma...>]

Hi,

Is anyone still interested in PyObjC on OSX 10.4?  I haven't done any  
development on 10.4 in a long time and while having 10.4 support would  
be nice to have I don't think I'll ever get around to finishing 10.4  
support in PyObjC 2.x.

Ronald

Re: [Pyobjc-dev] Initial memory usage

[Ronald O. <ron...@ma...>]

On 30 Sep, 2009, at 21:58, Bill Bumgarner wrote:

>
> On Sep 30, 2009, at 11:32 AM, Arif Amirani wrote:
>
>> Thanks for the info Bill. How do I figure out if the memory usage  
>> is high due to allocations or mm stuff? I tried instruments but  
>> couldn't make out what I was seeing.
>
> vmmap will typically do the trick.

Most of the memory is in allocations, and the difference with  
rubycocoa seems to be due to parsing of bridgesupport files.

The "Live Bytes" column value for "All Allocations" using the "Object  
Allocator" instrument shrinks from about 24 MByte to about 12 MByte  
when I remove parsing of the bridgesupport files from a test program.  
This means that there is either a memory leak in parsing bridgesupport  
files, or PyObjC's representation of the parsed bridgesupport  
datafiles is too inefficient.   The leaks instrument points to the  
latter explaination, there are no serious leaks accoring to that  
instrument.

Our representation of the parsed brigesupport files uses fairly  
regular Python datastructures, it is likely that we can improve on that.

I'm adding this to my todo-list for a future release, the  
unnecessarily hight initial memory usage is annoying but not something  
that is trivial to fix which makes it unlikely that I'll be able to  
fix it before the next non-beta release. I really need to get PyObjC  
2.2 final out soonish.

I've also checked in a quick-win: Intern all strings loaded from the  
XML files. That doesn't help a lot, but every bit helps.

Another reason for high memory usage is that we scan the entire method  
table for a class when it is touched for the first time (basically, a  
method is called from Python). That used to be necessary to allow  
introspection using dir(), but that comes at a cost. Recent versions  
of Python have a hook for dir() that should allow for introspection  
without always scanning the entire class. This should give us a  
performance boost as well.

Ronald

Re: [Pyobjc-dev] Initial memory usage

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

On Sep 30, 2009, at 11:32 AM, Arif Amirani wrote:

> Thanks for the info Bill. How do I figure out if the memory usage is  
> high due to allocations or mm stuff? I tried instruments but  
> couldn't make out what I was seeing.

vmmap will typically do the trick.

b.bum

Re: [Pyobjc-dev] Initial memory usage

[Ronald O. <ron...@ma...>]

On 30 Sep, 2009, at 20:32, Arif Amirani wrote:

> Thanks for the info Bill. How do I figure out if the memory usage is  
> high due to allocations or mm stuff? I tried instruments but  
> couldn't make out what I was seeing.

I'm looking with instruments as well, I'm using the basic TableModel  
example from pyobjc-framework-Cocoa to test.

The bulk of memory usage is due to PyMem_Malloc, which is Python's  
memory allocator. Python has its own allocator build on top of malloc  
to get better performance (malloc()/free() are not fast enough on most  
platforms, and there's also a risk for memory fragmentation).  The  
next question is: is the memory usage real, or is most of it just the  
memory arena's for PyMem_Malloc.

To be continued,

   Ronald

>
> Thanks,
> Arif
>
> On Wed, Sep 30, 2009 at 11:03 PM, Bill Bumgarner <bb...@ma...> wrote:
>
> On Sep 30, 2009, at 6:38 AM, Arif Amirani wrote:
>
> A small update. I tried the same with a Ruby Cocoa bridge and the  
> exact single window app started off with only 9M+ memory usage. I'll  
> try a few more tests but otherwise this looks like a huge difference  
> between native cocoa - ruby cocoa and pyobjc apps.
>
> Is it allocations or is it memory mapped gunk?
>
> If it is allocations, that is a problem.
>
> If it is memory mapped stuff -- shared libraries, etc -- you  
> shouldn't care.
>
> b.bum
>
>

Re: [Pyobjc-dev] Initial memory usage

[Arif A. <ari...@gm...>]

Thanks for the info Bill. How do I figure out if the memory usage is high
due to allocations or mm stuff? I tried instruments but couldn't make out
what I was seeing.
Thanks,
Arif

On Wed, Sep 30, 2009 at 11:03 PM, Bill Bumgarner <bb...@ma...> wrote:

>
> On Sep 30, 2009, at 6:38 AM, Arif Amirani wrote:
>
>  A small update. I tried the same with a Ruby Cocoa bridge and the exact
>> single window app started off with only 9M+ memory usage. I'll try a few
>> more tests but otherwise this looks like a huge difference between native
>> cocoa - ruby cocoa and pyobjc apps.
>>
>
> Is it allocations or is it memory mapped gunk?
>
> If it is allocations, that is a problem.
>
> If it is memory mapped stuff -- shared libraries, etc -- you shouldn't
> care.
>
> b.bum
>
>

Re: [Pyobjc-dev] Initial memory usage

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

On Sep 30, 2009, at 6:38 AM, Arif Amirani wrote:

> A small update. I tried the same with a Ruby Cocoa bridge and the  
> exact single window app started off with only 9M+ memory usage. I'll  
> try a few more tests but otherwise this looks like a huge difference  
> between native cocoa - ruby cocoa and pyobjc apps.

Is it allocations or is it memory mapped gunk?

If it is allocations, that is a problem.

If it is memory mapped stuff -- shared libraries, etc -- you shouldn't  
care.

b.bum

Re: [Pyobjc-dev] Initial memory usage

[Arif A. <ari...@gm...>]

Hi all,

A small update. I tried the same with a Ruby Cocoa bridge and the exact
single window app started off with only 9M+ memory usage. I'll try a few
more tests but otherwise this looks like a huge difference between native
cocoa - ruby cocoa and pyobjc apps.

Thanks,
Arif
http://blog.tripmeter.in

On Wed, Sep 30, 2009 at 3:32 PM, Arif Amirani <ari...@gm...>wrote:

> Hi Ronald,
> I've tried this with Activity Monitor, top and some 3rd party tool. I get a
> consistent usage of 30+M for the single window app.
>
> Is there a more robust way of determining app memory usage?
>
> Thanks,
> Arif Amirani
> http://blog.tripmeter.in
>
>
> On Wed, Sep 30, 2009 at 2:08 AM, Ronald Oussoren <ron...@ma...>wrote:
>
>>
>> On 21 Sep, 2009, at 10:39, Arif Amirani wrote:
>>
>> Hi all,
>> I've recently started developing PyObjC apps and my app memory usage shot
>> off to 75MB. So I created a small Hello World app with just one NSWindow and
>> the initial memory was 36MB. I'd assume this would be expected since the
>> entire Python interpreter is running within the app it might take that much.
>> So is it safe to assume that all PyObjC apps need a minimum of 30+M to work?
>>
>>
>> I guess so. I haven't done serious measuments of PyObjC memory usage
>> beyond checking that PyObjC doesn't leak memory.
>>
>> How did you measure the memory usage?
>>
>> Ronald
>>
>>
>> Versions:
>> Mac OS X 10.5.8
>>
>> >>> print objc.__version__
>> 2.2b2
>>
>> Thanks,
>> Arif Amirani
>>
>> Blog: http://blog.tripmeter.in
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9&#45;12, 2009. Register
>> now&#33;
>> http://p.sf.net/sfu/devconf_______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
>>
>

Re: [Pyobjc-dev] Initial memory usage

[Arif A. <ari...@gm...>]

Hi Ronald,
I've tried this with Activity Monitor, top and some 3rd party tool. I get a
consistent usage of 30+M for the single window app.

Is there a more robust way of determining app memory usage?

Thanks,
Arif Amirani
http://blog.tripmeter.in

On Wed, Sep 30, 2009 at 2:08 AM, Ronald Oussoren <ron...@ma...>wrote:

>
> On 21 Sep, 2009, at 10:39, Arif Amirani wrote:
>
> Hi all,
> I've recently started developing PyObjC apps and my app memory usage shot
> off to 75MB. So I created a small Hello World app with just one NSWindow and
> the initial memory was 36MB. I'd assume this would be expected since the
> entire Python interpreter is running within the app it might take that much.
> So is it safe to assume that all PyObjC apps need a minimum of 30+M to work?
>
>
> I guess so. I haven't done serious measuments of PyObjC memory usage beyond
> checking that PyObjC doesn't leak memory.
>
> How did you measure the memory usage?
>
> Ronald
>
>
> Versions:
> Mac OS X 10.5.8
>
> >>> print objc.__version__
> 2.2b2
>
> Thanks,
> Arif Amirani
>
> Blog: http://blog.tripmeter.in
>
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
>

Re: [Pyobjc-dev] Exceptions on calling super

[Dirk S. <dir...@ma...>]

Hi Ronald,

I recently moved our app to PyObjC HEAD / Python 2.6.2 (from the dmg  
installer from python.org) on Leopard and have not seen these  
exceptions since, so I'm also pretty sure the underlying issue is fixed.

Before making this move I've tried to isolate the issue but had no  
luck in figuring out a way to consistently reproduce it.  If I ever  
run into it again on a recent revision of PyObjC, I'll let you know.

thx,
- Dirk

On Sep 29, 2009, at 10:36 PM, Ronald Oussoren wrote:

> Dirk,
>
> I cannot reproduce this with Python 2.6 and PyObjC HEAD, or with / 
> usr/bin/python on SL with its version of PyObjC.
>
> I've used the following scriptlet to test:
>
> #BEGIN
> from Cocoa import *
>
> NSApplication.sharedApplication()
>
> class SFWindow(NSWindow):
>    def initWithContentRect_styleMask_backing_defer_(self,
>            contentRect, styleMask, backing, defer):
>        print "init"
>        self = super(SFWindow,  
> self).initWithContentRect_styleMask_backing_defer_(
>                contentRect,  styleMask, backing, defer)
>        if self:
>            pass # do stuff
>        return self
>
> v = SFWindow.alloc().init()
> # EOF
>
> This prints "init" when run.
>
> Ronald
>
> On 20 Sep, 2009, at 13:16, Dirk Stoop wrote:
>
>>>> We recently moved our app from PyObjC 1.4 to 2.2 and now get a  
>>>> lot of
>>>> exceptions like this:
>>>>
>>>> TypeError??: super(type, obj): obj must be an instance or subtype  
>>>> of
>>>> type
>>>>
>>>> These happen in any Python subclass of a Cocoa superclass, but only
>>>> occasionally.  I'm not completely clear how to reproduce the issue,
>>>> but it only happens when we override an initializer and have a call
>>>> to:
>>>>
>>>> super(classNameOfOurSubClass, self).init() # or any other
>>>> initializer.
>>>>
>>>> Does anyone have a clue what might be going on?
>>>
>>> That message pretty clearly means that a classic class is getting
>>> injected somehow.  Consider this::
>>>
>>>  class C:
>>>      def foo(self):
>>>          super(C, self)
>>>
>>>  C().foo()
>>>
>>> Which version of Python?
>>
>>
>> Thanks for your reply :)
>>
>> We're using Python 2.5.4 and we don't have classic classes anywhere  
>> in
>> our app.
>>
>> The error message I get from the example you wrote is also different
>> from the one we're getting..
>>
>> TypeError: super() argument 1 must be type, not classobj
>>
>> The one I get seems to explicitely state that the second argument is
>> not the type or a subtype of the first argument, yet the one I get
>> when I run your example just tells me that the second type can't be
>> 'the' old-style classobj.
>>
>> To get our app to stop crashing on this, I'll replace e.g.
>>
>> class SFWindow(NSWindow):
>>    def initWithContentRect_styleMask_backing_defer_(self,
>> contentRect, styleMask, backing, defer):
>>        self = super(SFWindow,
>> self).initWithContentRect_styleMask_backing_defer_(contentRect,
>> styleMask, backing, defer)
>>        if self:
>>            pass # do stuff
>>        return self
>>
>> with:
>>
>> class SFWindow(NSWindow):
>>    def initWithContentRect_styleMask_backing_defer_(self,
>> contentRect, styleMask, backing, defer):
>>        self =
>> NSWindow.initWithContentRect_styleMask_backing_defer_(self,
>> contentRect, styleMask, backing, defer)
>>        if self:
>>            pass # do stuff
>>        return self
>> 	
>> for now.  I'm not planning on changing the superclasses of any of
>> these classes anyway, so the extra burden of maintaining this code is
>> well worth getting rid of these occasional crashes.
>>
>> Still very weird that this happens, I've tried to isolate the issue  
>> to
>> a particular situation, but all my efforts so far have failed and I
>> don't have time now to do more research.  I'll post again here if/ 
>> when
>> I've figured out the exact regression of this problem.
>>
>> - Dirk
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry® Developer Conference in SF,  
>> CA
>> is the only developer event you need to attend this year. Jumpstart  
>> your
>> developing skills, take BlackBerry mobile applications to market  
>> and stay
>> ahead of the curve. Join us from November 9-12, 2009. Register  
>> now!
>> http://p.sf.net/sfu/devconf
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] PyObjcC class method swizzling

[Ronald O. <ron...@ma...>]

On 19 Sep, 2009, at 14:02, Lukas Pitschl | Dressy Vagabonds wrote:

> Hi everyone!
>
> I've just recently started to explore the power of PyObjC by rewriting
> the GPGMail plugin and I'm more than impressed.
> A big compliment to the developers!
>
> Unfortunately at the moment I'm stuck with class method swizzling.
> I've found a very nice decorator which can be used
> to swizzle instance methods:
>
> def swizzle(*args):
>     cls, SEL = args
>     def decorator(func):
>         oldIMP      = cls.instanceMethodForSelector_(SEL)
>         def wrapper(self, *args, **kwargs):
>             return func(self, oldIMP, *args, **kwargs)
>         newMethod   = objc.selector(wrapper,
>                                     selector  = oldIMP.selector,
>                                     signature = oldIMP.signature)
>         objc.classAddMethod(cls, SEL, newMethod)
>         return wrapper
>     return decorator
>
> My poor attempt to convert this into a decorator which swizzles class
> methods looks like the one below, but unfortunately doesn't
> work.
>
> def swizzleClassMethod(*args):
>     cls, SEL = args
>     def decorator(func):
>         oldIMP      = cls.methodForSelector_(SEL)
>         def wrapper(klass, *args, **kwargs):
>             return func(klass, oldIMP, *args, **kwargs)
>         newMethod   = objc.selector(wrapper,
>                                     selector  = oldIMP.selector,
>                                     signature = oldIMP.signature)
>         objc.classAddMethod(cls, SEL, newMethod)
>         return wrapper
>     return decorator

Have you tried adding "isClassMethod=True" to the argument list of  
objc.selector?

Your current code creates an instance method.

Ronald

Re: [Pyobjc-dev] Initial memory usage

[Ronald O. <ron...@ma...>]

On 21 Sep, 2009, at 10:39, Arif Amirani wrote:

> Hi all,
>
> I've recently started developing PyObjC apps and my app memory usage  
> shot off to 75MB. So I created a small Hello World app with just one  
> NSWindow and the initial memory was 36MB. I'd assume this would be  
> expected since the entire Python interpreter is running within the  
> app it might take that much. So is it safe to assume that all PyObjC  
> apps need a minimum of 30+M to work?

I guess so. I haven't done serious measuments of PyObjC memory usage  
beyond checking that PyObjC doesn't leak memory.

How did you measure the memory usage?

Ronald

>
> Versions:
> Mac OS X 10.5.8
>
> >>> print objc.__version__
> 2.2b2
>
> Thanks,
> Arif Amirani
>
> Blog: http://blog.tripmeter.in
>
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Exceptions on calling super

[Ronald O. <ron...@ma...>]

Dirk,

I cannot reproduce this with Python 2.6 and PyObjC HEAD, or with /usr/ 
bin/python on SL with its version of PyObjC.

I've used the following scriptlet to test:

#BEGIN
from Cocoa import *

NSApplication.sharedApplication()

class SFWindow(NSWindow):
     def initWithContentRect_styleMask_backing_defer_(self,
             contentRect, styleMask, backing, defer):
         print "init"
         self = super(SFWindow,  
self).initWithContentRect_styleMask_backing_defer_(
                 contentRect,  styleMask, backing, defer)
         if self:
             pass # do stuff
         return self

v = SFWindow.alloc().init()
# EOF

This prints "init" when run.

Ronald

On 20 Sep, 2009, at 13:16, Dirk Stoop wrote:

>>> We recently moved our app from PyObjC 1.4 to 2.2 and now get a lot  
>>> of
>>> exceptions like this:
>>>
>>> TypeError??: super(type, obj): obj must be an instance or subtype of
>>> type
>>>
>>> These happen in any Python subclass of a Cocoa superclass, but only
>>> occasionally.  I'm not completely clear how to reproduce the issue,
>>> but it only happens when we override an initializer and have a call
>>> to:
>>>
>>> super(classNameOfOurSubClass, self).init() # or any other
>>> initializer.
>>>
>>> Does anyone have a clue what might be going on?
>>
>> That message pretty clearly means that a classic class is getting
>> injected somehow.  Consider this::
>>
>>   class C:
>>       def foo(self):
>>           super(C, self)
>>
>>   C().foo()
>>
>> Which version of Python?
>
>
> Thanks for your reply :)
>
> We're using Python 2.5.4 and we don't have classic classes anywhere in
> our app.
>
> The error message I get from the example you wrote is also different
> from the one we're getting..
>
> TypeError: super() argument 1 must be type, not classobj
>
> The one I get seems to explicitely state that the second argument is
> not the type or a subtype of the first argument, yet the one I get
> when I run your example just tells me that the second type can't be
> 'the' old-style classobj.
>
> To get our app to stop crashing on this, I'll replace e.g.
>
> class SFWindow(NSWindow):
>     def initWithContentRect_styleMask_backing_defer_(self,
> contentRect, styleMask, backing, defer):
>         self = super(SFWindow,
> self).initWithContentRect_styleMask_backing_defer_(contentRect,
> styleMask, backing, defer)
>         if self:
>             pass # do stuff
>         return self
>
> with:
>
> class SFWindow(NSWindow):
>     def initWithContentRect_styleMask_backing_defer_(self,
> contentRect, styleMask, backing, defer):
>         self =
> NSWindow.initWithContentRect_styleMask_backing_defer_(self,
> contentRect, styleMask, backing, defer)
>         if self:
>             pass # do stuff
>         return self
> 	
> for now.  I'm not planning on changing the superclasses of any of
> these classes anyway, so the extra burden of maintaining this code is
> well worth getting rid of these occasional crashes.
>
> Still very weird that this happens, I've tried to isolate the issue to
> a particular situation, but all my efforts so far have failed and I
> don't have time now to do more research.  I'll post again here if/when
> I've figured out the exact regression of this problem.
>
> - Dirk
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart  
> your
> developing skills, take BlackBerry mobile applications to market and  
> stay
> ahead of the curve. Join us from November 9-12, 2009. Register  
> now!
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev