pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] CLLocationManager

[Stefan S. <st....@go...>]

Hi,

I'm trying to use CLLocationManager from Python. Althoug I don't get an
error, I also do not get any output.

Does someone have some experience with this?

Brgds,
Stefan

<python>
import objc
from Foundation import *
import time


objc.loadBundle("CoreLocation", globals(),
"/System/Library/Frameworks/CoreLocation.framework")


class LocationDelegate(NSObject):
def locationManager_didUpdateToLocation_fromLocation_(self, manager,
newlocation, oldlocation):
print manager
print newlocation
print oldlocation
def didFailWithError_(self, error):
print error

delegate = LocationDelegate.alloc().init()
print (delegate)
myLocMgr = CLLocationManager.alloc().init()
print (myLocMgr)
myLocMgr.setDelegate_(delegate)
accuracy = -1.0
myLocMgr.setDesiredAccuracy_(accuracy)
myLocMgr.startUpdatingLocation()
#time.sleep(10)
myLoc = myLocMgr.location()
print (myLoc)
</python>

[Pyobjc-dev] [ pyobjc-Bugs-2982093 ] Mouse event locations broken for 64 bit

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

Bugs item #2982093, was opened at 2010-04-05 16:04
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=2982093&group_id=14534

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Pepijn de Vos ()
Assigned to: Nobody/Anonymous (nobody)
Summary: Mouse event locations broken for 64 bit

Initial Comment:
When PyObjC is ran in 64 bit mode(which is the default) on Snow Leopard creating a mouse event returns a garbage location.
When I run this code, everything goes back to normal:

defaults write com.apple.versioner.python Prefer-32-Bit -bool yes

This is an example code, note the returned NSPoint.

>>> from Quartz import *
>>> event = CGEventCreateMouseEvent(None, kCGEventLeftMouseDown, (200, 200), 0)
>>> CGEventGetLocation(event)
<NSPoint x=13510801139695616.0 y=6.953222975628442e-310>

Events captured from an event tap instead of generated do have a correct position, as do separate NSPoint objects.
The problem is really with creating an event in 64 bit Python.

I'm using Python 2.6 and PyObjC 2.2

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

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

[Pyobjc-dev] PyObjC status for Python 3.x

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

Hi,

This is a quick status-update for the Py3k support in PyObjC: pyobjc-core and the framework wrappers can be build with Python 3.2 and most tests pass. I haven't looked at py2app yet, that probably requires some work to get it to work propertly, although with some luck it will work as is.

I'm not entirely happy yet though,   the Python-compatible interface for NSDictionary and other collection classes don't conform to the interface of the corresponding python types yet (that is, "anNSDictionary.keys()" is not a view object but returns a list just as in Python 2.x).   My plan to fix this is to first write unittests for this and then implement the required support code.

PyObjC also don't do anything with the Abstract Base Class machinery yet (see <http://docs.python.org/py3k/library/abc.html>). I plan to add that later on, both by registering Cocoa subclasses with the ABCs and by looking at the ABCs to see how a class should be proxied.

BTW. A side-effect of the py3k port is that the version of pyobjc in the repository requires python 2.6 because I use byte literals ( b"hello") to tweak the output from the 2to3 tool. I have no plans to reintroduce support for python 2.5, especially because I'd like to make some changes to the bridge that will require python 2.6. 

Ronald

Re: [Pyobjc-dev] PyObjC CGPoint error in CGEventCreateMouseEvent

[Ratko J. <rja...@gm...>]

I ran across the same problem back in September and there were a few bugs in
the C code. I reported the bugs and they were fixed so I guess the Macports
version includes those fixes. Don't know about the version numbers.
CGEventTapCreate should take 6 parameters, as it does in carbon.


What do you mean by "breaks the location"?
"*When I run Python26 and PyObjC from Macports the event system works fine,
but making an event breaks the location.*"


Ratko



On Sun, Apr 4, 2010 at 10:27 AM, Pepijn de Vos <pep...@gm...>wrote:

> Hi all,
>
> I finally managed to get listening to events working, the code is at
> http://github.com/pepijndevos/PyMouse/blob/master/mac.py#L30
> I don't know what made the difference, but after a lot of trying it
> suddenly worked.
>
> Now I have another strange issue.
> When I run the default Python and PyObjC version that came with Mac OS X
> 10.6, Python segfaults while creating an event tap.
> When I run Python26 and PyObjC from Macports the event system works fine,
> but making an event breaks the location.
>
> Stock Python:
>
> >>> from Quartz import *
> >>> def test(*args):
> ...     print args
> ...
> >>> tap = CGEventTapCreate(
> ...             kCGSessionEventTap,
> ...             kCGHeadInsertEventTap,
> ...             kCGEventTapOptionDefault,
> ...             CGEventMaskBit(kCGEventMouseMoved) |
> ...             CGEventMaskBit(kCGEventLeftMouseDown) |
> ...             CGEventMaskBit(kCGEventLeftMouseUp) |
> ...             CGEventMaskBit(kCGEventRightMouseDown) |
> ...             CGEventMaskBit(kCGEventRightMouseUp) |
> ...             CGEventMaskBit(kCGEventOtherMouseDown) |
> ...             CGEventMaskBit(kCGEventOtherMouseUp),
> ...             test)
> Segmentation fault
>
> Macports Python:
>
> >>> from Quartz import *
> >>> event = CGEventCreateMouseEvent(None, 3, CGPoint(200, 200), 1)
> >>> CGEventGetLocation(event)
> <NSPoint x=13510801139695616.0 y=6.953222975623699e-310>
>
> Also the stock version of CGEventTapCreate needs 5 parameters while the
> Macports version needs 6.
>
> Macports version of PyObjC is 2.2
> Included version should be 2.2b3 according to a blog I found.
>
> Groeten,
> Pepijn de Vos
> --
> Sent from my iPod Shuffle
> http://pepijndevos.nl
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] PyObjC CGPoint error in CGEventCreateMouseEvent

[Pepijn de V. <pep...@gm...>]

Hi all,

I finally managed to get listening to events working, the code is at http://github.com/pepijndevos/PyMouse/blob/master/mac.py#L30
I don't know what made the difference, but after a lot of trying it suddenly worked.

Now I have another strange issue.
When I run the default Python and PyObjC version that came with Mac OS X 10.6, Python segfaults while creating an event tap.
When I run Python26 and PyObjC from Macports the event system works fine, but making an event breaks the location.

Stock Python:

>>> from Quartz import *
>>> def test(*args):
...     print args
... 
>>> tap = CGEventTapCreate(
...             kCGSessionEventTap,
...             kCGHeadInsertEventTap,
...             kCGEventTapOptionDefault,
...             CGEventMaskBit(kCGEventMouseMoved) |
...             CGEventMaskBit(kCGEventLeftMouseDown) |
...             CGEventMaskBit(kCGEventLeftMouseUp) |
...             CGEventMaskBit(kCGEventRightMouseDown) |
...             CGEventMaskBit(kCGEventRightMouseUp) |
...             CGEventMaskBit(kCGEventOtherMouseDown) |
...             CGEventMaskBit(kCGEventOtherMouseUp),
...             test)
Segmentation fault

Macports Python:

>>> from Quartz import *
>>> event = CGEventCreateMouseEvent(None, 3, CGPoint(200, 200), 1)
>>> CGEventGetLocation(event)
<NSPoint x=13510801139695616.0 y=6.953222975623699e-310>

Also the stock version of CGEventTapCreate needs 5 parameters while the Macports version needs 6.

Macports version of PyObjC is 2.2
Included version should be 2.2b3 according to a blog I found.

Groeten,
Pepijn de Vos
--
Sent from my iPod Shuffle
http://pepijndevos.nl

Re: [Pyobjc-dev] PyObjC and OSX versions

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

On 3 Apr, 2010, at 15:41, Aahz wrote:

> On Thu, Apr 01, 2010, Ronald Oussoren wrote:
>> 
>> W.r.t. 10.4 support in general: I'd say that it is more worthwhile to
>> work on porting PyObjC 2.2 to 10.4 than to try to create a workflow
>> using both PyObjC 1.4 and 2.2.  For the most part this entails adding
>> #ifdef guards in the C modules to ensure that the wrappers for APIs
>> that aren't available on 10.4 get excluded from the build when
>> building using the 10.4 SDK.
> 
> That still means it's going to be tricky writing an app that uses
> FSEvents on 10.5+ that works without FSEvents on 10.4 -- instead of
> maintaining separate installs of PyObjC 1.4 and 2.2, I'll need to have
> separate installs of 2.2 and 2.2, and keeping track of which is which
> will be more difficult.
> 
> Perhaps I'm missing something?  Would it be possible to build PyObjC 2.2
> on 10.5 in a way that works on 10.4, just with FSEvents disabled?

That's pretty easy to do, although I don't recall if I have prepared the code for it.  This basicly requires weak-linking to any symbols that aren't available on 10.4 and dealing with the NULL pointers that you might get because of that.

An example of this is Modules/posixmodule.c in the python tree.  That uses weaklinking to ensure that os.lchown (and several other symbols) are present on OSX releases that have it while still working on older OSX releases. 

> 
> There's a reasonably good chance we're going to switch to kauth due to
> FSEvents' limitations, which would sidestep the issue another way.  Does
> anyone have any experience using kauth?

What's kauth?

> 
> Before someone asks, kqueue is not sufficient for our needs (monitoring
> directory systems that might have a million files), and pnotify has
> languished for so long without update that I'm not willing to take a
> chance with it.  I think that pretty much exhausts the available options.

Ronald


> -- 
> Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/
> 
> Why is this newsgroup different from all other newsgroups?  
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] PyObjC and OSX versions

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

On Thu, Apr 01, 2010, Ronald Oussoren wrote:
>
> W.r.t. 10.4 support in general: I'd say that it is more worthwhile to
> work on porting PyObjC 2.2 to 10.4 than to try to create a workflow
> using both PyObjC 1.4 and 2.2.  For the most part this entails adding
> #ifdef guards in the C modules to ensure that the wrappers for APIs
> that aren't available on 10.4 get excluded from the build when
> building using the 10.4 SDK.

That still means it's going to be tricky writing an app that uses
FSEvents on 10.5+ that works without FSEvents on 10.4 -- instead of
maintaining separate installs of PyObjC 1.4 and 2.2, I'll need to have
separate installs of 2.2 and 2.2, and keeping track of which is which
will be more difficult.

Perhaps I'm missing something?  Would it be possible to build PyObjC 2.2
on 10.5 in a way that works on 10.4, just with FSEvents disabled?

There's a reasonably good chance we're going to switch to kauth due to
FSEvents' limitations, which would sidestep the issue another way.  Does
anyone have any experience using kauth?

Before someone asks, kqueue is not sufficient for our needs (monitoring
directory systems that might have a million files), and pnotify has
languished for so long without update that I'm not willing to take a
chance with it.  I think that pretty much exhausts the available options.
-- 
Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/

Why is this newsgroup different from all other newsgroups?  

Re: [Pyobjc-dev] Listening for mouse events

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

On 30 Mar, 2010, at 21:22, Pepijn de Vos wrote:

> Hey,
> 
> For my mouse control project I want to add the ability to listen to mouse events.
> My lib is at http://github.com/pepijndevos/PyMouse
> 
> To do this on Mac I turned to PyObjC.
> While PyObjC served me well for the clicking and moving part of my lib, listening to events has proven problematic.
> 
> First it just crashed, but since I installed a newer version of PyObjC it simply runs in an endless loop without the callback getting called.
> 
> Here is a snippet of code... Can anyone see what is wrong with it?
> http://gist.github.com/349472
> 
> I would be very grateful if anyone could help me to get this working, I've been looking all over the internet for weeks now.

I don't have time to look into this right now, but will have some time over the weekend.

Ronald
> 
> Groeten,
> Pepijn de Vos
> --
> Sent from my iPod Shuffle
> http://pepijndevos.nl
> 
> 
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] PyObjC and OSX versions

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

On 30 Mar, 2010, at 21:33, David Bolen wrote:

> Ronald Oussoren <ron...@ma...> writes:
> 
>> NibClassBuilder shouldn't be used in code that's developed on OSX
>> 10.5 or later, the latest tools no longer generate the metadata that
>> is used by this module.  Futhermore Xcode on OSX 10.5 or later knows
>> enough of Python and PyObjC to take away the need for
>> NibClassBuilder.
> 
> Hmm - it sounds like you're saying not just take away the need for but
> preclude the use of.  I assumed that if I'm developing on 10.5, but
> still using PyObjC 1.4 to target a 10.4 client that I still need to
> use the older approach and include NibClassBuilder.

You don't. NibClassBuilder is just a nifty trick to avoid having to define classes, outlets and actions manually in two places. On OSX 10.4 Interface Builder doesn't know anything about Python, which means you have to declare all classes you want to use in that version of IB inside the NIB file.   NibClassBuilder.AutoBaseClass is magic base class that reads information about the class from the NIB file and sets up the right superclass and outlets (as defined in the NIB).

In OSX 10.5 (or later) Interface Builder does know how to read Python files, which means you can define the classes in Python and read the definitions in IB. IMHO that results in much easier to understand code because you don't have to hunt down information when you read the code.    

As an additional snag (sp?) IB on 10.5 won't even create the file that NibClassBuilder uses to determine the superclass and outlets, which means that NibClassBuilder cannot work there.   IB might write the additional metadata when you use .nib files instead of .xib files on OSX 10.5, but both will be compiled to a more compact .nib file by Xcode when you build the application bundle.

Note that all of this is just a matter of developer convenience: if you want to develop on both platforms you can always define the classes both in IB and the python code. That works just fine, but means you have to do a little more work when changing classes.

W.r.t. 10.4 support in general: I'd say that it is more worthwhile to work on porting PyObjC 2.2 to 10.4 than to try to create a workflow using both PyObjC 1.4 and 2.2.   For the most part this entails adding #ifdef guards in the C modules to ensure that the wrappers for APIs that aren't available on 10.4 get excluded from the build when building using the 10.4 SDK.     

Ronald

[Pyobjc-dev] Unknown option: -p

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

Greetings,

I'm trying to fix a *very* weird bug in the latest version of Miro 3.0 which in certain circumstances prevents it to be launched more than once. So far the problem only seems to occur on Intel machines running OS X 10.5.8, and is the following one: the user can launch the application exactly once and then any attempt to launch the application after this first time fails, with this message being logged to the console:

Unknown option: -p
usage: /Applications/Miro.app/Contents/MacOS/python [option] ... [-c cmd | -m mod | file | -] [arg] ...
Try 'python -h' for more information.

The unknown -p option is most likely the infamous -psn_X_Y parameter passed by LaunchServices to applications double clicked from the Finder. What doesn't make sense *at all* is that the bundle executable is *not* the python executable which, while being present in the application bundle, is *not* what should be run (and is not what is run at least the first time). The Info.plist explictely specifies Miro to be the CFBundleExecutable.

The application bundle looks like this (irrelevant parts omitted):
Miro.app
Miro.app/Contents
Miro.app/Contents/Components
Miro.app/Contents/Frameworks
Miro.app/Contents/Frameworks/Python.framework (python 2.4)
Miro.app/Contents/Info.plist
Miro.app/Contents/MacOS/Miro
Miro.app/Contents/MacOS/python
Miro.app/Contents/Resources

As you can see, there are two executable binaries, the correct one (Miro) is launched the first time and the wrong one (python, which is used internally by the app to run other scripts) is launched the next times, for some very weird and unknown reasons.

FWIW, architecture infos:

% lipo -info Miro.app/Contents/MacOS/Miro
Architectures in the fat file: Miro are: i386 ppc
% lipo -info Miro.app/Contents/MacOS/python
Architectures in the fat file: python are: ppc i386

Architectures aren't in the same order, I have no idea why this would matter but I'm open to any suggestion a this point.

Miro is based on PyObjC 1.4 and built on a 10.4.10 machine so it can run on 10.4, 10.5 and 10.6.

This latest version of Miro is available here: http://getmiro.com
Sources are visible and available for anyone here: https://git.participatoryculture.org/miro/


If anyone has *any* idea or already had this problem, I'd love to hear from you :)

Thanks.

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

Re: [Pyobjc-dev] Listening for mouse events

[Pepijn de V. <pep...@gm...>]

Hi Ratko,

I'm sorry to hear Carbon mouse events ere not working for you either.
Did you find an alternative solution?

For the moving and clicking, I suggest you have a look at http://github.com/pepijndevos/PyMouse/blob/master/mac.py
It should be quite simple to follow.
I took a long time to figure out though.

Groeten,
Pepijn de Vos
--
Sent from my iPod Shuffle
http://pepijndevos.nl

On Mar 30, 2010, at 11:10 PM, Ratko Jagodic wrote:

> I have had similar issues with capturing mouse events using carbon and PyObjC. My app works in the beginning but then for no apparent reason stops capturing events at random. On some machines it runs for a very long time, on some it stops quickly. No difference in machines either... go figure. Unfortunately I haven't been able to resolve any of them after months of intermittently looking at it.
> 
> I would also be interesting in hearing if someone has experience with this.
> 
> Pepijn, you said it served you well for the moving and clicking part. Could you explain a bit more what you were doing and how?
> 
> 
> Ratko
> 
> 
> 
> On Tue, Mar 30, 2010 at 2:22 PM, Pepijn de Vos <pep...@gm...> wrote:
> Hey,
> 
> For my mouse control project I want to add the ability to listen to mouse events.
> My lib is at http://github.com/pepijndevos/PyMouse
> 
> To do this on Mac I turned to PyObjC.
> While PyObjC served me well for the clicking and moving part of my lib, listening to events has proven problematic.
> 
> First it just crashed, but since I installed a newer version of PyObjC it simply runs in an endless loop without the callback getting called.
> 
> Here is a snippet of code... Can anyone see what is wrong with it?
> http://gist.github.com/349472
> 
> I would be very grateful if anyone could help me to get this working, I've been looking all over the internet for weeks now.
> 
> Groeten,
> Pepijn de Vos
> --
> Sent from my iPod Shuffle
> http://pepijndevos.nl
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 

Re: [Pyobjc-dev] Listening for mouse events

[Ratko J. <rja...@gm...>]

I have had similar issues with capturing mouse events using carbon and
PyObjC. My app works in the beginning but then for no apparent reason stops
capturing events at random. On some machines it runs for a very long time,
on some it stops quickly. No difference in machines either... go figure.
Unfortunately I haven't been able to resolve any of them after months of
intermittently looking at it.

I would also be interesting in hearing if someone has experience with this.

Pepijn, you said it served you well for the moving and clicking part. Could
you explain a bit more what you were doing and how?


Ratko



On Tue, Mar 30, 2010 at 2:22 PM, Pepijn de Vos <pep...@gm...>wrote:

> Hey,
>
> For my mouse control project I want to add the ability to listen to mouse
> events.
> My lib is at http://github.com/pepijndevos/PyMouse
>
> To do this on Mac I turned to PyObjC.
> While PyObjC served me well for the clicking and moving part of my lib,
> listening to events has proven problematic.
>
> First it just crashed, but since I installed a newer version of PyObjC it
> simply runs in an endless loop without the callback getting called.
>
> Here is a snippet of code... Can anyone see what is wrong with it?
> http://gist.github.com/349472
>
> I would be very grateful if anyone could help me to get this working, I've
> been looking all over the internet for weeks now.
>
> Groeten,
> Pepijn de Vos
> --
> Sent from my iPod Shuffle
> http://pepijndevos.nl
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] PyObjC and OSX versions

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

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

> NibClassBuilder shouldn't be used in code that's developed on OSX
> 10.5 or later, the latest tools no longer generate the metadata that
> is used by this module.  Futhermore Xcode on OSX 10.5 or later knows
> enough of Python and PyObjC to take away the need for
> NibClassBuilder.

Hmm - it sounds like you're saying not just take away the need for but
preclude the use of.  I assumed that if I'm developing on 10.5, but
still using PyObjC 1.4 to target a 10.4 client that I still need to
use the older approach and include NibClassBuilder.

It sounds like you're saying that building a UI with 10.5+ tools no
longer works with NibClassBuilder at all, so if I need to change the
UI, for the application to continue working on 10.4, I need to edit
the UI using 10.4 tools?  Or will a nib generated with 10.5+ tools
still be usable under PyObjC 1.4 just without the need for
NibClassBuilder?

I made a small test change to an existing nib file while on 10.6 and
it seemed to continue to work, but I didn't test it exhaustively.
Existing nibs built under 10.4 are fine, but obviously they would have
the meta data.

-- David

[Pyobjc-dev] Listening for mouse events

[Pepijn de V. <pep...@gm...>]

Hey,

For my mouse control project I want to add the ability to listen to mouse events.
My lib is at http://github.com/pepijndevos/PyMouse

To do this on Mac I turned to PyObjC.
While PyObjC served me well for the clicking and moving part of my lib, listening to events has proven problematic.

First it just crashed, but since I installed a newer version of PyObjC it simply runs in an endless loop without the callback getting called.

Here is a snippet of code... Can anyone see what is wrong with it?
http://gist.github.com/349472

I would be very grateful if anyone could help me to get this working, I've been looking all over the internet for weeks now.

Groeten,
Pepijn de Vos
--
Sent from my iPod Shuffle
http://pepijndevos.nl

Re: [Pyobjc-dev] PyObjC and OSX versions

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

On 25 Mar, 2010, at 21:28, David Bolen wrote:
> 
> For anyone else reading this down the road who may be interested, I
> ran into various strange failures initially trying to use the older
> tool versions with more recent Python interpreters and libraries under
> 10.6.  Backing off to PyObjC 1.4 alone generated errors from
> NibClassBuilder.extractClasses() trying to load my main nib (something
> Aahz also remarked on in his post).

NibClassBuilder shouldn't be used in code that's developed on OSX 10.5 or later, the latest tools no longer generate the metadata that is used by this module.  Futhermore Xcode on OSX 10.5 or later knows enough of Python and PyObjC to take away the need for NibClassBuilder.

Ronald

Re: [Pyobjc-dev] PyObjC and OSX versions

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

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

> Building pyobjc for running on various OS releases is too hard at
> the moment. PyObjC 2.2 build on 10.6 won't work on 10.5 at the
> moment due to a dependency on libxml. I have removal of that
> dependency on my todo list, but haven't gotten around to doing that
> yet.

Thanks, that's helpful to know.  And thanks also to Aahz for some
offline pointers to his recent posts.  Sounds like the safest thing,
if using current releases of PyObjC and especially without a full
complement of test machines, is just to assume that something built on
system 10.w.x will only work on 10.y.z where y.z>=w.x.  So continuing
to build with PyObjC 1.4 for 10.4 seems safest for supporting any of
10.4-10.6 clients for now.

For anyone else reading this down the road who may be interested, I
ran into various strange failures initially trying to use the older
tool versions with more recent Python interpreters and libraries under
10.6.  Backing off to PyObjC 1.4 alone generated errors from
NibClassBuilder.extractClasses() trying to load my main nib (something
Aahz also remarked on in his post).  After also backing off to py2app
0.3.6, it then failed to run when python 2.5.4 couldn't find a config
header that hadn't been included in the bundle.  So the older py2app
solved the nib problem but clearly was missing a change in bundling
needed by the later Python.

I also ran into different behavior for existing code when building
with PyObjC 2.2 directly for 10.6 execution.  I'd have dismissed it as
expected API changes across two major OSX releases, except that
applications built under PyObjC 1.4 - even when built on the same 10.6
system - didn't exhibit any of the issues.  So there must be something
different in how the later PyObjC/py2app tools bundle things or
identify the bundle to the OS that affects runtime behavior.

For example, some key/observer calls - deprecated as of 10.5, but the
only option when running on 10.4 - seem to stop working, but only when
built with PyObjC 2.2.  The same code/calls when running the bundle
created with PyObjC 1.4 (whether previously or on the same 10.6
system) work fine.  And even under 10.6, the call is documented as
being supported, albeit deprecated, for backwards compatibility.
Similarly for the issue recently posted about on 10.6 where
QTMovie.movieWithAttributes_() requires an NSDictionary and not just a
Python dict - but my 10.4 bundle which uses a Python dict continues to
run fine on the same 10.6 system.

Clearly there's night and day differences between PyObjC 1.4 and 2.2
so I can't claim to be completely surprised, but I do find it
intriguing that the issues a 2.2-built bundle exhibit aren't present
when running on the same system with bundles built with 1.4.

Anyway, I finally resorted to restoring the entire private Python
framework tree (including Python 2.5.1) I had been using on my 10.4
system onto my 10.6 system and am using that.  It appears to build my
application properly such that it still runs on 10.4 and behaves the
same with respect to the API calls as it always has.  So the
combination of Python 2.5.1, PyObjC 1.4, and py2app 0.3.6 seems to work
even when the host environment is 10.6.

It's unfortunate that there are so many version requirements amongst
OSX and PyObjC releases (and fuzziness in terms of knowing what those
requirements are) with respect to host and target OSX environments.
Given my experience running the 10.4-built bundles on later systems,
the backwards compatibility in OSX itself is quite good, but clearly
using a later system to create something an earlier system can run (or
even to build legacy code) is harder to lock down.

Then again, I'd hate not to have PyObjC even with these constraints,
so don't wish to sound like I'm complaining too much - I really
appreciate all the hard work that has gone into PyObjC.

-- David

Re: [Pyobjc-dev] PyObjC and OSX versions

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

On 23 Mar, 2010, at 7:53, David Bolen wrote:
> 
> In looking around though, I'm not having a lot of luck trying to find
> a decent explanation of how to best serve a varied customer base from
> a 10.6 development system.  I know I need PyObjC 1.4 to target Tiger,
> but can I build/use that on my 10.6 system?  And will my PyObjC 2.2
> build under 10.6.2 work under 10.5 systems (I don't have any handy to
> test)?

Building pyobjc for running on various OS releases is too hard at the moment. PyObjC 2.2 build on 10.6 won't work on 10.5 at the moment due to a dependency on libxml. I have removal of that dependency on my todo list, but haven't gotten around to doing that yet.

I hope to find time to do that once current cleanup and py3k work is finished, I want to look into the 10.4 port then as well. Last time I checked PyObjC 2.2 mostly, but not entirely, worked on 10.4.

Ronald

Re: [Pyobjc-dev] Python 3.x for FSEvents in OS X 10.6

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

On 22 Mar, 2010, at 13:05, Kingsley Reuben wrote:

> Hi all,
> 
> Am using OS X 10.6 (Snow Leopard). 
> 
> Just wanted to know whether Python 3.x is supported for FSEvents through PyObjC.

Not yet.

I've started on a python 3.x port of PyObjC but that's not finished yet and the FSEvents wrappers haven't been ported yet.

Ronald
> 
> regards,
> Kings
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] PyObjC and OSX versions

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

I originally developed an application when Tiger was mainstream and
PyObjC 1.x still current.  For a long time now I've mastered my
distributions on a 10.4.10 Tiger system with PyObjC 1.4, and had no
problem with people running them on 10.4, 10.5, and even 10.6 systems.
I even prevented the 10.4.11 update from installing on my build
machine since it would have broken a WebKit interface I used.
Realizing that there were issues using PyObjC 2.x and trying to have
something that could run on Tiger, I didn't plan on changing the
process any time soon, and just watched the various threads here about
those issues pass by.

However, my build system's disk died a horrible death last week.
While I'm in the process of rebuilding, I took it as a sign and
figured I should bite the bullet and start experimenting with more
recent build tools.  So I've got a 10.6.2 Snow Leopard system that
I've been testing as my next build system.

In looking around though, I'm not having a lot of luck trying to find
a decent explanation of how to best serve a varied customer base from
a 10.6 development system.  I know I need PyObjC 1.4 to target Tiger,
but can I build/use that on my 10.6 system?  And will my PyObjC 2.2
build under 10.6.2 work under 10.5 systems (I don't have any handy to
test)?

Is there is reasonable summary of the pieces and host platforms needed
to support clients with a mixture of 10.4-10.6 systems?  Is it easier
if I exclude 10.4, or is 10.5 just as hard if you're using a 10.6
build system?  I assume sticking with 32-bit is best (and not an issue
for me).

In some initial trials, I'm sticking with the system Python 2.5.4,
32-bit mode.  Looks like the system PyObjC is 2.2b3.  I expect that in
a final setup, to maintain better control, I'd install a local python
(probably still prefer 2.5.x for now due to other libraries) and my
own PyObjC/py2app.

Aside from running into an issue with QtKit - wish I had caught up to
this list sooner since it was the same movieWithAttributes parameter
issue where it had to be an NSDictionary mentioned recently - things
seem fine on 10.6 systems.  As expected, it doesn't even get off the
ground on a 10.4 system.  Not sure about 10.5 (don't have one to test
on).

Just wondering what best practices are to create an application that
has the ability to run on as many client OS releases as possible, or
at least know how many different builds I have to create.

Thanks for any pointers or information.

-- David

[Pyobjc-dev] Python 3.x for FSEvents in OS X 10.6

[Kingsley R. <kin...@gm...>]

Hi all,

Am using OS X 10.6 (Snow Leopard).

Just wanted to know whether Python 3.x is supported for FSEvents through
PyObjC.

regards,
Kings

Re: [Pyobjc-dev] Finding memory leaks?

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

On 9 Mar, 2010, at 23:00, Orestis Markou wrote:

> Hi all,
> 
> just wondering if there is a simple workflow around for finding memory leaks in PyObjC/Cocoa apps.
> 
> Running with instruments/Leaks is not very helpful (or perhaps I don't know how to set it up correctly).

Instruments and leaks aren't  very useful because because those tools don't know about Python objects, and more importantly the Python memory manager.  I tend to use a combination of leaks and Python's gc module to find sources of unexpected memory usage.

What also can help is to create a separate python build using  '--without-pymalloc'.  This results in a slower binary, but one that uses straight malloc/free instead of Python's memory manager. This makes using Apple's tools more productive.

Ronald

Re: [Pyobjc-dev] Patch for py2app -A on 64-bit Snow Leopard (was Re: Fwd: PyObjC and NSOpenGLView)

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

On 10 Mar, 2010, at 14:26, James R Eagan wrote:

> 
> Le 5 janv. 2010 à 11:43, Ronald Oussoren a écrit :
> 
>> "py2app -A" doesn't work at the moment on SL, IIRC someone has sent me a fix for that.
>> 
>> You should be able to run the example using 'python setup.py py2app' without the -A.
> 
> I know I've submitted other py2app-related patches before, but mine didn't fix a bug related to alias builds on 64-bit Snow Leopard systems (I'm still in 32-bit land, so I never noticed before).  (You might have also been talking someone else, but Carly Simon did once write a song about me.)  
> 
> For some reason, Carbon.File.Alias on 64-bit only has the FS* functions, but not their aliases with the FS prefix removed.  This is probably a bug in Python-mac rather than in py2app or pyobjc.  But here's a workaround for it in py2app, made off of PyObjC trunk/py2app :

Good catch. I've applied your patch to the repository (r89).  someAlias.ResolveAlias and someAlias.FSResolveAlias map onto C functions with the same name, and the ones without 'FS' prefix aren't available in 64-bit code (not just in Python, but in C as well). 

Have I mentioned yet that the 'Carbon' wrappers in the stdlib suck?  <0.5 wink>

Ronald

[Pyobjc-dev] Patch for py2app -A on 64-bit Snow Leopard (was Re: Fwd: PyObjC and NSOpenGLView)

[James R E. <Jam...@lr...>]

Le 5 janv. 2010 à 11:43, Ronald Oussoren a écrit :

> "py2app -A" doesn't work at the moment on SL, IIRC someone has sent me a fix for that.
> 
> You should be able to run the example using 'python setup.py py2app' without the -A.

I know I've submitted other py2app-related patches before, but mine didn't fix a bug related to alias builds on 64-bit Snow Leopard systems (I'm still in 32-bit land, so I never noticed before).  (You might have also been talking someone else, but Carly Simon did once write a song about me.)  

For some reason, Carbon.File.Alias on 64-bit only has the FS* functions, but not their aliases with the FS prefix removed.  This is probably a bug in Python-mac rather than in py2app or pyobjc.  But here's a workaround for it in py2app, made off of PyObjC trunk/py2app :

Re: [Pyobjc-dev] Pyobjc-dev Digest, Vol 44, Issue 2

[Fabzter <fab...@gm...>]

Thanks for your quick answers. (:

On Tue, Mar 9, 2010 at 8:25 AM,
<pyo...@li...> wrote:
> Send Pyobjc-dev mailing list submissions to
>        pyo...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> or, via email, send a message with subject or body 'help' to
>        pyo...@li...
>
> You can reach the person managing the list at
>        pyo...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Pyobjc-dev digest..."
>
>
> Today's Topics:
>
>   1. Build hell resolved: 10.4/10.5/10.6 (Aahz)
>   2. About linux Support. (Fabzter)
>   3. Re: About linux Support. (Mani Ghasemlou)
>   4. Re: About linux Support. (Ronald Oussoren)
>   5. Re: About linux Support. (Ronald Oussoren)
>   6. Re: About linux Support. (Virgil Dupras)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 4 Mar 2010 11:00:50 -0800
> From: Aahz <aa...@py...>
> Subject: [Pyobjc-dev] Build hell resolved: 10.4/10.5/10.6
> To: pyt...@py..., pyo...@li...
> Message-ID: <201...@pa...>
> Content-Type: text/plain; charset=us-ascii
>
> [cross-posted to both pythonmac-sig and pyobjc-dev for max audience,
> Reply-To set to pyobjc-dev for discussion]
>
> I finally figured out how to build my app:
>
> Turns out that in order to use PyObjC 2.2 you need py2app 0.4.3 -- but
> PyObjC 1.4 needs py2app 0.3.6.  (PyObjC 1.4 is for the main app running
> on 10.4/10.5/10.6; PyObjC 2.2 is used for FSEvents on 10.5/10.6,
> previously PyObjC 2.2b2 for 10.5 only, but 2.2b2 doesn't work on 10.6)
>
> I built PyObjC 2.2 on 10.5 from source.  It's a right royal pain (partly
> because PyPI has no mechanism for downloading *source* dependencies), and
> I really hope that the next release of PyObjC makes it much easier to
> build from source.  (Or that binaries for 10.5 get included.)
>
> My clue that py2app was the issue was when I figured out that
>
> from Foundation import NSAutoreleasePool, NSMutableArray, NSString
>
> causing
>
> ValueError: Don't know CF type for typestr '^{__CFAllocator=}', cannot create special wrapper
>
> only and always occurred in a build, not from plain Python, even on 10.6,
> meaning that PyObjC wasn't the problem.
>
> Incidentally, using py2app 0.4.3 with PyObjC 1.4 resulted in some error
> about corrupted NIB file that I didn't record exactly.
>
> Before someone asks how I can use both PyObjC 1.4 and PyObjC 2.2, I'm
> playing games with ~/Library/Python/2.6 being a symlink that gets swapped
> during the build process.  (Obviously, I end up with two different apps
> built.)
> --
> Aahz (aa...@py...)           <*>         http://www.pythoncraft.com/
>
> "Many customs in this life persist because they ease friction and promote
> productivity as a result of universal agreement, and whether they are
> precisely the optimal choices is much less important." --Henry Spencer
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 7 Mar 2010 21:39:26 -0600
> From: Fabzter <fab...@gm...>
> Subject: [Pyobjc-dev] About linux Support.
> To: pyo...@li...
> Message-ID:
>        <cc9...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Today I found about pyobjc, and I'm pretty interested on it just
> because i like learning about different programming languages.
> Now, I want to learn objective c and to do it I'll write a very simple
> 2d game with it. The problem is I'm a linux user. I _know_ pyobjc is
> mac focused, but maybe you have some kind of support to linux?
>
> Or maybe you can tell me where is the subset of the code (maybe the
> core?) that let objective-c and python  interact with each other. I'm
> only interested in that part, nothing about the cocoa and mac-only
> stuff. Please don't think I am too lazy; I'm rather TOO stupid, and
> I'll get quickly lost if I dive into pyobjc source. So any help, or
> pointers are really apreciated.
>
> Thank you.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 7 Mar 2010 23:20:20 -0500
> From: Mani Ghasemlou <ma...@tu...>
> Subject: Re: [Pyobjc-dev] About linux Support.
> To: pyo...@li...
> Message-ID:
>        <d2a...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi Fabzter,
>
> On Sun, Mar 7, 2010 at 10:39 PM, Fabzter <fab...@gm...> wrote:
>> Today I found about pyobjc, and I'm pretty interested on it just
>> because i like learning about different programming languages.
>
> Curiosity is as good a reason as any!
>
>> Now, I want to learn objective c and to do it I'll write a very simple
>> 2d game with it. The problem is I'm a linux user. I _know_ pyobjc is
>> mac focused, but maybe you have some kind of support to linux?
>>
>
> I believe at one point PyObjC supported GNUStep
> (http://www.gnustep.org), but it does not anymore. In other words,
> PyObjC will unfortunately not be very useful to a Linux user. The
> value proposition for PyObjC, for better or worse, is entirely to the
> benefit of MacOS X developers who wish to interact with Cocoa using
> Python.
>
> I think for making a 2d game using Python, you'll have a lot of great
> (read: better) options:
> http://wiki.python.org/moin/PythonGameLibraries
>
>> Or maybe you can tell me where is the subset of the code (maybe the
>> core?) that let objective-c and python ?interact with each other. I'm
>
> This is a huge departure from making a simple 2d game. :) Can't help
> with this one, sorry ...
>
> Best of luck,
> Mani
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 09 Mar 2010 14:49:01 +0100
> From: Ronald Oussoren <ron...@ma...>
> Subject: Re: [Pyobjc-dev] About linux Support.
> To: Fabzter <fab...@gm...>
> Cc: pyo...@li...
> Message-ID: <E74...@ma...>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On 8 Mar, 2010, at 4:39, Fabzter wrote:
>
>> Today I found about pyobjc, and I'm pretty interested on it just
>> because i like learning about different programming languages.
>> Now, I want to learn objective c and to do it I'll write a very simple
>> 2d game with it. The problem is I'm a linux user. I _know_ pyobjc is
>> mac focused, but maybe you have some kind of support to linux?
>>
>> Or maybe you can tell me where is the subset of the code (maybe the
>> core?) that let objective-c and python  interact with each other. I'm
>> only interested in that part, nothing about the cocoa and mac-only
>> stuff. Please don't think I am too lazy; I'm rather TOO stupid, and
>> I'll get quickly lost if I dive into pyobjc source. So any help, or
>> pointers are really apreciated.
>
> PyObjC does not support linux, and probably never will.  The core part of PyObjC is a bridge that translates Python method calls into Objective-C calls (and the other way around). This bridge uses the Objective-C runtime and the API for that is not standardized in any way, the GNU runtime (used by GNUstep on Linux) has a different API  than the one on OSX.
>
> Adding support for GNUstep on Linux is possible, but I'm not interested in doing the work.
>
> Ronald
>>
>> Thank you.
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 3567 bytes
> Desc: not available
>
> ------------------------------
>
> Message: 5
> Date: Tue, 09 Mar 2010 14:53:47 +0100
> From: Ronald Oussoren <ron...@ma...>
> Subject: Re: [Pyobjc-dev] About linux Support.
> To: Mani Ghasemlou <ma...@tu...>
> Cc: pyo...@li...
> Message-ID: <C7B...@ma...>
> Content-Type: text/plain; charset="us-ascii"
>
>
> On 8 Mar, 2010, at 5:20, Mani Ghasemlou wrote:
>
>> Hi Fabzter,
>>
>> On Sun, Mar 7, 2010 at 10:39 PM, Fabzter <fab...@gm...> wrote:
>>> Today I found about pyobjc, and I'm pretty interested on it just
>>> because i like learning about different programming languages.
>>
>> Curiosity is as good a reason as any!
>>
>>> Now, I want to learn objective c and to do it I'll write a very simple
>>> 2d game with it. The problem is I'm a linux user. I _know_ pyobjc is
>>> mac focused, but maybe you have some kind of support to linux?
>>>
>>
>> I believe at one point PyObjC supported GNUStep
>> (http://www.gnustep.org), but it does not anymore. In other words,
>> PyObjC will unfortunately not be very useful to a Linux user. The
>> value proposition for PyObjC, for better or worse, is entirely to the
>> benefit of MacOS X developers who wish to interact with Cocoa using
>> Python.
>
> PyObjC had very limited support for GNUstep, but that never worked properly and because nobody was interested in finishing the port I ripped that support out.
>
> If someone really wants gnustep support and is willing to support that I'm willing to merge a patch to that effect. However, that person will have to do all the work, I'm will not merge partial patches or even run tests on Linux (which means a linux maintainer will have to fix the linux port from time to time because development on OSX broke linux support).
>
> Ronald
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: smime.p7s
> Type: application/pkcs7-signature
> Size: 3567 bytes
> Desc: not available
>
> ------------------------------
>
> Message: 6
> Date: Tue, 9 Mar 2010 15:00:58 +0100
> From: Virgil Dupras <hs...@ha...>
> Subject: Re: [Pyobjc-dev] About linux Support.
> To: Ronald Oussoren <ron...@ma...>
> Cc: pyo...@li...
> Message-ID:
>        <2a7...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> In other words, it's probably easier to for PyObjC and convert it into
> a GNUStep bridge :)
> --
> Virgil Dupras
>
>
> On Tue, Mar 9, 2010 at 2:53 PM, Ronald Oussoren <ron...@ma...> wrote:
>>
>> On 8 Mar, 2010, at 5:20, Mani Ghasemlou wrote:
>>
>>> Hi Fabzter,
>>>
>>> On Sun, Mar 7, 2010 at 10:39 PM, Fabzter <fab...@gm...> wrote:
>>>> Today I found about pyobjc, and I'm pretty interested on it just
>>>> because i like learning about different programming languages.
>>>
>>> Curiosity is as good a reason as any!
>>>
>>>> Now, I want to learn objective c and to do it I'll write a very simple
>>>> 2d game with it. The problem is I'm a linux user. I _know_ pyobjc is
>>>> mac focused, but maybe you have some kind of support to linux?
>>>>
>>>
>>> I believe at one point PyObjC supported GNUStep
>>> (http://www.gnustep.org), but it does not anymore. In other words,
>>> PyObjC will unfortunately not be very useful to a Linux user. The
>>> value proposition for PyObjC, for better or worse, is entirely to the
>>> benefit of MacOS X developers who wish to interact with Cocoa using
>>> Python.
>>
>> PyObjC had very limited support for GNUstep, but that never worked properly and because nobody was interested in finishing the port I ripped that support out.
>>
>> If someone really wants gnustep support and is willing to support that I'm willing to merge a patch to that effect. However, that person will have to do all the work, I'm will not merge partial patches or even run tests on Linux (which means a linux maintainer will have to fix the linux port from time to time because development on OSX broke linux support).
>>
>> Ronald
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel&#174; Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
>
>
>
> ------------------------------
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
>
> ------------------------------
>
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
> End of Pyobjc-dev Digest, Vol 44, Issue 2
> *****************************************
>

[Pyobjc-dev] Finding memory leaks?

[Orestis M. <or...@or...>]

Hi all,

just wondering if there is a simple workflow around for finding memory leaks in PyObjC/Cocoa apps.

Running with instruments/Leaks is not very helpful (or perhaps I don't know how to set it up correctly).

Thanks,
Orestis