pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] PyObjc supports XCode 5.0 and 10.9?

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

On 17 May 2014, at 16:42, Marc Van Olmen <ma...@ac...> wrote:

> Ronald,
> 
> Just switched our app over to PyObjc 3.0 and XCode 5.1.1
> 
> biggest change I had to do was to change super to pyobjc.super, and just fixed a few 10.8 warnings of deprecated methods.

objc.super is also needed on older versions of PyObjC, it is just much, much easier to trigger problems with PyObjC 3.0 due to the removal of some hacks from the bridge implementation :-)

> 
> One issue I notice that that PyObjc warnings is on in debug mode of the app:
> 
> and  I get a lot of these
> 
> 2014-05-17 10:35:59.072 Checkout[51943:303] *** ObjC exception 'NSRangeException' (reason: '*** -[__NSArrayM objectAtIndex:]: index 2 beyond bounds [0 .. 1]') discarded
> Stack trace (most recent call last):
>   PyObjCNativeSelector_Type (in _objc.so) + 0
>   objcsel_call (in _objc.so) + 228
>   PyObjCFFI_Caller (in _objc.so) + 3305
>   ffi_call (in _objc.so) + 125
>   ffi_call_SYSV (in _objc.so) (x86-darwin-Kjl12T.s:63)
>   -[__NSArrayM objectAtIndex:] (in CoreFoundation) + 251
>   objc_exception_throw (in libobjc.A.dylib) + 230
>   NSExceptionHandlerExceptionRaiser (in ExceptionHandling) + 211
> 
> this one for example is generated by this iterator:
> 
>         # Categorize devices
>         for keyboard in DDHidLib.DDHidKeyboard.allKeyboards():
>             # Don't recheck devices that have been categorized already
>             # NSLog(u'%@', unicode(keyboard.descriptionDictionary()))
> 
> Also this iterator is causing exceptions:
> 
>          for subview in self.tabView.subviews():
> 		if subview.isKindOfClass_(SFTabButton):
>   		          tabsByOriginXDict[Foundation.NSMinX(subview.frame())] = subview
> 
> 
> but I see a common issue for this.
> 
> I could add changes to this: (but I will wait for you input.)
> 
> def nsarray__getitem__(self, idx):
>     if isinstance(idx, slice):
>         start, stop, step = idx.indices(len(self))
>         return [self[i] for i in range(start, stop, step)]
> 
>     elif not isinstance(idx, INT_TYPES):
>         raise TypeError("index must be a number")
> 
>     if idx < 0:
>         idx += len(self)
>         if idx < 0:
>             raise IndexError("list index out of range")
> 
>     return container_unwrap(self.objectAtIndex_(idx), RuntimeError)

I can reproduce the problem with a simple script:

# t.py
import objc
from PyObjCTools import Debugging

NSArray = objc.lookUpClass('NSArray')
a = NSArray.arrayWithArray_(['a', 'b', 'c'])
print(list(iter(a)))

Debugging.installVerboseExceptionHandler()
print(list(iter(a)))
# EOF

$ python3 t.py
['a', 'b', 'c']
2014-05-30 11:34:11.195 Python[33077:d07] *** ObjC exception 'NSRangeException' (reason: '*** -[__NSArrayI objectAtIndex:]: index 3 beyond bounds [0 .. 2]') discarded
Stack trace (most recent call last):
  0x7fff5a67d190
  ffi_call_unix64 (in _objc.so) + 79
  -[__NSArrayI objectAtIndex:] (in CoreFoundation) + 175
  objc_exception_throw (in libobjc.A.dylib) + 43
  NSExceptionHandlerExceptionRaiser (in ExceptionHandling) + 172
['a', 'b', 'c']

The problem is twofold:

1) PyObjCTools.Debugging complains too much: there is a range exception, but it is caught and handled by Python code

    I don’t know yet what I can do about this.

2) NSArray no longer has an __iter__ method, that got lost in the PyObjC 3.0 cleanup. I’m re-adding this method later today.

The __iter__ method got lost due to a fairly major change in how Cocoa classes are handled by PyObjC: before 3.0 I scanned the method table of Cocoa classes as soon as they were touched and used the list of methods to determine which informal protocols the class appeared to implement and used that information to add a Python interface to classes (e.g. add __getitem__ when a class implements “objectForKey:”). That  code was fairly expensive because it effectively got called every time a Cocoa object was touched from Python because Cocoa classes can be updated at runtime and there is no way to get notified when a class is changed. Therefore PyObjC 3.0 only looks for names that are explicitly used from Python, and specials methods are added to specific classes only.  The NSArray.__iter__ method got lost during the transition to this new implementation :-(

Ronald

> 
> 
> marc
> 
> 
> 
> On Mar 7, 2014, at 11:34 AM, Marc Van Olmen <ma...@ac...> wrote:
> 
>> 
>> On Mar 4, 2014, at 6:50 AM, Ronald Oussoren <ron...@ma...> wrote:
>> 
>>> I guess it really time to push out a new release.
>>> 
>>> The PyObjC version in the repository (a 3.0 prerelease) builds cleanly with Xcode 5 on OSX 10.9. To be honest I’m not sure if the current public release builds cleanly on 10.9 because I haven’t used it in a long time.
>> 
>> 
>> That would be nice, we are planning a major release of Checkout 4.0 in upcoming weeks, would be nice to go beta with PyObjc 3.0 release)
>> 
>> Marc
>> 
>> 
> 

Re: [Pyobjc-dev] PyObjc supports XCode 5.0 and 10.9?

[Marc V. O. <ma...@ac...>]

Ronald,

Just switched our app over to PyObjc 3.0 and XCode 5.1.1

biggest change I had to do was to change super to pyobjc.super, and just fixed a few 10.8 warnings of deprecated methods.

One issue I notice that that PyObjc warnings is on in debug mode of the app:

and  I get a lot of these

2014-05-17 10:35:59.072 Checkout[51943:303] *** ObjC exception 'NSRangeException' (reason: '*** -[__NSArrayM objectAtIndex:]: index 2 beyond bounds [0 .. 1]') discarded
Stack trace (most recent call last):
  PyObjCNativeSelector_Type (in _objc.so) + 0
  objcsel_call (in _objc.so) + 228
  PyObjCFFI_Caller (in _objc.so) + 3305
  ffi_call (in _objc.so) + 125
  ffi_call_SYSV (in _objc.so) (x86-darwin-Kjl12T.s:63)
  -[__NSArrayM objectAtIndex:] (in CoreFoundation) + 251
  objc_exception_throw (in libobjc.A.dylib) + 230
  NSExceptionHandlerExceptionRaiser (in ExceptionHandling) + 211

this one for example is generated by this iterator:

        # Categorize devices
        for keyboard in DDHidLib.DDHidKeyboard.allKeyboards():
            # Don't recheck devices that have been categorized already
            # NSLog(u'%@', unicode(keyboard.descriptionDictionary()))

Also this iterator is causing exceptions:

         for subview in self.tabView.subviews():
		if subview.isKindOfClass_(SFTabButton):
  		          tabsByOriginXDict[Foundation.NSMinX(subview.frame())] = subview


but I see a common issue for this.

I could add changes to this: (but I will wait for you input.)

def nsarray__getitem__(self, idx):
    if isinstance(idx, slice):
        start, stop, step = idx.indices(len(self))
        return [self[i] for i in range(start, stop, step)]

    elif not isinstance(idx, INT_TYPES):
        raise TypeError("index must be a number")

    if idx < 0:
        idx += len(self)
        if idx < 0:
            raise IndexError("list index out of range")

    return container_unwrap(self.objectAtIndex_(idx), RuntimeError)


marc



On Mar 7, 2014, at 11:34 AM, Marc Van Olmen <ma...@ac...> wrote:

> 
> On Mar 4, 2014, at 6:50 AM, Ronald Oussoren <ron...@ma...> wrote:
> 
>> I guess it really time to push out a new release.
>> 
>> The PyObjC version in the repository (a 3.0 prerelease) builds cleanly with Xcode 5 on OSX 10.9. To be honest I’m not sure if the current public release builds cleanly on 10.9 because I haven’t used it in a long time.
> 
> 
> That would be nice, we are planning a major release of Checkout 4.0 in upcoming weeks, would be nice to go beta with PyObjc 3.0 release)
> 
> Marc
> 
> 

Re: [Pyobjc-dev] PyObjc supports XCode 5.0 and 10.9?

[Marc V. O. <ma...@ac...>]

On Mar 4, 2014, at 6:50 AM, Ronald Oussoren <ron...@ma...> wrote:

> I guess it really time to push out a new release.
> 
> The PyObjC version in the repository (a 3.0 prerelease) builds cleanly with Xcode 5 on OSX 10.9. To be honest I’m not sure if the current public release builds cleanly on 10.9 because I haven’t used it in a long time.


That would be nice, we are planning a major release of Checkout 4.0 in upcoming weeks, would be nice to go beta with PyObjc 3.0 release)

Marc

Re: [Pyobjc-dev] PyObjc supports XCode 5.0 and 10.9?

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

On 27 Feb 2014, at 18:04, Marc Van Olmen <ma...@ac...> wrote:

> hi,
> 
> if I would set up a fresh machine with Xcode 5.0 and 10.9 should this support PyObc?
> 
> I tried this a few months ago and failed to make it work, just wondering if anyone else tried it lately.
> 
> I'm  currently on Xcode 4.6.3 and 10.8.5 and build pyobjc from source code.

I guess it really time to push out a new release.

The PyObjC version in the repository (a 3.0 prerelease) builds cleanly with Xcode 5 on OSX 10.9. To be honest I’m not sure if the current public release builds cleanly on 10.9 because I haven’t used it in a long time.

Ronald

[Pyobjc-dev] PyObjc supports XCode 5.0 and 10.9?

[Marc V. O. <ma...@ac...>]

hi,

if I would set up a fresh machine with Xcode 5.0 and 10.9 should this support PyObc?

I tried this a few months ago and failed to make it work, just wondering if anyone else tried it lately.

I'm  currently on Xcode 4.6.3 and 10.8.5 and build pyobjc from source code.

marc

Re: [Pyobjc-dev] NSObject, doctest

[Erik v. B. <er...@le...>]

On 19 dec. 2013, at 13:42, Ronald Oussoren <ron...@ma...> wrote:
>> 
>> Is there something in the nature of pyobjc objects that makes them confuse dockets?
> 
> Not sure if the class repr at the top of the traceback is relevant, but if it is this might be due to doctest trying to test some PyObjC classes.
> 
> BTW. I’m moving away from “from AppKit import *” towards just importing what I need. That leads to code that’s slightly easier to check with linting tools, and in recent versions of PyObjC is faster as well because the framework wrappers now try to do as little work as possible (and that doesn’t work when you import everything).

I finally got around to rewriting the tests, for completeness' sake I can confirm that switching
	from AppKit import *
to just the items I need allows the doctests to run. Thanks!

E

Re: [Pyobjc-dev] Proper way to expose custom Obj-C classes to Python?

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

On 19 Feb 2014, at 00:23, Ian McCullough <ip...@po...> wrote:

> Hi,
> 
> I'm trying to determine the best way to expose custom, application-specific, non-system-framework (i.e. not in one of the framework wrappers provided with PyObjC) classes written in Objective-C to python across the PyObjC bridge. My eventual hope is to develop a "hybrid" application in which some portions of the app are in Objective-C and others are in python, with the two side integrating via the PyObjC bridge. Most of the documentation I've been able to find seems to focus on situations where the goal is to have all the app-specific code be in python, and to have the python call out to AppKit classes, etc via the bridge and the pre-packaged system framework wrappers.
> 
> I've not seen any indication that it's possible to expose classes from an app. But I did find this web page: https://pythonhosted.org/pyobjc/dev/wrapping.html which makes it sound like the best way would be for me to move any classes that need to be visible to python out of my application, and into a framework (which I can embed in my application), and then to adapt an existing framework wrapper to wrap this newly-created framework. So far, the wrapper-adapting part is proving to be easier said that done.
> 
> Looking at the existing wrappers, many of them have a compiled component (i.e. .m files). As far as I can tell, that seems to be responsible for bringing in protocols, constants and C functions. That said, it's not clear to me what all triggers the need for a compiled extension. I also saw that the _metadata.py files in existing wrappers have this at the top of them: "This file is generated by objective.metadata". I tracked that down to this repo: https://bitbucket.org/ronaldoussoren/objective.metadata which, with some coaxing I could get to build, install and run, but I've not gotten it to do anything useful yet -- i.e. how I get it to generate these _metadata.py files is not obvious. 
> 
> I'm content to keep fighting through the source on my own, but there's this part of my mind saying, "You've *got* to be missing something. It can't possibly be this involved to expose a framework to python." I can understand the overhead for exposing C functions and constants, but all the Objective-C stuff should be doable at runtime, right?

That’s correct. The metadata is only needed to expose C functions, constants, C type definitions (e.g. “NSRect”)  and the API for methods where the API cannot be fully extracted from the Objective-C runtime. The latter are methods that have pointer arguments (excluding “id”), as the bridge cannot know what’s supposed to be passed there (input or output, 1 value or an array of some size, …)
 
> 
> So, in sum: 
> 
> 1) Is this the right way to expose Objective-C classes to Python?

The framework wrappers are an example of the most comprehensive way to expose Objective-C APIs to Python. If that is the best way for you depends on the amount and complexity of the code you want to expose to python.

> 
> Assuming yes...
> 
> 2) Exhaustively speaking, what triggers the need for a compiled extension?

* Protocols
* Methods and functions that cannot be represented using metadata

> 3) What is the magic invocation to get objective.metadata to spit out the _metadata.py files for my framework?



> 4) Any other tips that might help in with this "hybrid" app goal?
> 
> Many thanks,
> Ian
> 
> 
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Stackless?

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

On 17 Feb 2014, at 20:34, Ian McCullough <ip...@po...> wrote:

> Yeah, I'm not delusional enough to think that the whole NS* world would magically be pickle-able, but it seemed within the realm of possibility that I could implement pickling for the small subset of classes that comprised my model.

That should be possible, that is Objective-C objects can be pickled if you implement __reduce__ for their classes. It is not possible to pickle arbitrary Objective-C objects, not even the subset implementing NSCoding.

> It still does seem like a reasonable proposition, but I'm seeing enough squirrelly behavior between the stackless interpreter and pyobjc right off the bat, that I'm sort of hesitant to press onward.  The first thing was the fact that PyHeapTypeObject is the same as PyTypeObject in stackless, so I had to go through and remove all the places that accessed the ht_type of PyHeapTypeObject. A straightforward change, to be sure, but then I started seeing lots of weirdness at run time (lots of null-ptr dereferences around the python <-> pyobjc boundaries that made no sense). I might have been willing to bite off the task of maintaining a vendor branch of pyobjc for running with stackless python, but I don't want to end up maintaining a vendor branch of stackless as well, so…

Patches to make PyObjC work with Stackless would be appreciated as long as they are not too invasive (and actually work). I don’t use Stackless myself and hence have never tested with it.

BTW. You’re bound to run into problems if Stackless still copies the C stack to switch between tasks and you switch tasks where one of the tasks has calls to Objective-C on the stack.

> 
> As far as serializing execution state, the classic native approach would be to break the code down into a state machine, and then serialize the state machine. For non-trivial code (you know, anything with loops or subroutines, etc), breaking it down into a state machine becomes tedious. Not using python also eliminates the scripty-ness/dynamism of using python. By using python to implement the logic and flow, it becomes that much easier to experiment with minor variations in the logic, etc. 
> 
> Oh well... I might bang on it a little more to see what I can see, but I assume that if someone on this list were up and running with pyobjc and stackless they would have posted by now…

I wouldn’t count on that at all :-). Have you asked on the stackless list about this?

Ronald
> 
> Thanks,
> Ian
> 
> 
> On Sun, Feb 16, 2014 at 3:57 PM, Diez B. Roggisch <de...@we...> wrote:
> I thought it was something along these lines.
> 
> I guess all you can do is to set up your "host" application in a way that it can restore the save-game state from scratch, regardless of what that state currently is.
> 
> But hoping that the whole NS*-world is persistable is bound to be disappointing :)
> 
> Diez
> 
> On Feb 16, 2014, at 9:28 PM, Ian McCullough <ip...@po...> wrote:
> 
>> The idea is to have a native Objective-C app, which hosts a stackless python interpreter in-process. The main feature of interest to me is the ability of stackless python to serialize a tasklet and deserialize and resume it later. Think of it as a "save game" mechanism, where the game logic is implemented in python -- you can save your game by serializing the state of the tasklet, and restore it later. 
>> 
>> The usage of pyobjc was intended to keep from having to keep a python-side model and a native-side model in sync.
>> 
>> FWIW, I actually managed to get pyobjc to compile against stackless with some slight modifications, but I'm seeing some real weird behavior at runtime, so I'm not holding out much hope.
>> 
>> Ian
>> 
>> 
>> 
>> On Sun, Feb 16, 2014 at 3:17 PM, Diez B. Roggisch <de...@we...> wrote:
>> As long as objective C isn't stackless, I doubt there is much use to it. What's your purpose?
>> 
>> Diez
>> 
>> On Feb 14, 2014, at 10:01 PM, Ian McCullough <ip...@po...> wrote:
>> 
>> >
>> > Is it possible to build PyObjC for use with Stackless python?  My attempts are pointing to "No" but I figured I'd ask.
>> > Thanks,Ian
>> >
>> > ------------------------------------------------------------------------------
>> > Android apps run on BlackBerry 10
>> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> > Get your Android app in front of a whole new audience.  Start now.
>> > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
>> > Pyobjc-dev mailing list
>> > Pyo...@li...
>> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>> 
>> 
>> ------------------------------------------------------------------------------
>> Android apps run on BlackBerry 10
>> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> Get your Android app in front of a whole new audience.  Start now.
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Proper way to expose custom Obj-C classes to Python?

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

(Sorry about the top posting, I'm posting through iCloud webmail and that tends to mangle mails to mailinglist in interesting ways...)

The framework wrappers don't contain that much intelligence, at first approximation a wrapper module for your own code can do something like:

     # MyClasses.py
     import objc
     # ... arrange for loading your code (if necessary)
     for cls in objc.getClassList():
         globals()[cls.name] = cls

That way your classes are available in the MyClasses namespace.  Then add definitions for globals symbols and the like.

The metadata tools are at best under-documented, and is very, very fragile (and didn't work at all for me on the 10.9 headers).  I'm trying to rewrite the parsing code using the python interface to clang.cindex, but that is moving forward fairly slowly because there is very little documentation on clang.cindex.

At the moment it might be easier to just create an _metadata.py file manually instead of using the metadata tool (assuming your headers don't contain a lot of definitions that need to be added to the metadata file)

Ronald

On Feb 19, 2014, at 03:07 PM, Ian McCullough <ip...@po...> wrote:

Ken & Georg,

Thanks for your replies. 

I've already gotten this far -- i.e. I'm running the interpreter in process, executing arbitrary python scripts in it, and trading objects back and forth via NSClassFromString and other API with provided wrappers. What I was hoping to achieve was "first-class" support for my classes -- like the framework wrappers that ship with PyObjC for the system frameworks. 

I've made some progress by brute force. I've gotten objective-metadata-tool installed, and I'm currently working through getting it to scan my framework's headers. This process appears under-documented, so my experience is basically, "Try an invocation of objective-metadata-tool in the debugger. See what fails. Figure out why it failed. Adjust invocation to avoid that condition. Repeat." I'll report back with my findings if I have any eventual success.
 



Thanks,
Ian




On Wed, Feb 19, 2014 at 2:56 AM, Ken Thomases <ke...@co...> wrote:
On Feb 18, 2014, at 5:23 PM, Ian McCullough wrote:

> I'm trying to determine the best way to expose custom,
> application-specific, non-system-framework (i.e. not in one of the
> framework wrappers provided with PyObjC) classes written in Objective-C to
> python across the PyObjC bridge. My eventual hope is to develop a "hybrid"
> application in which some portions of the app are in Objective-C and others
> are in python, with the two side integrating via the PyObjC bridge. Most of
> the documentation I've been able to find seems to focus on situations where
> the goal is to have all the app-specific code be in python, and to have the
> python call out to AppKit classes, etc via the bridge and the pre-packaged
> system framework wrappers.
>
> I've not seen any indication that it's possible to expose classes from an
> app.

It is.  I don't know if this is the best way, but one way is to link an otherwise ordinary Cocoa app, written in Objective-C, to the Python framework.  You would then use the Python embedding API to set up the Python runtime and load and run some Python code.  You might do something like:

    NSString* pythonPath = /* path within your app bundle to its Python files */;
    setenv("PYTHONPATH", [pythonPath fileSystemRepresentation], 1);

    Py_SetProgramName("/usr/bin/python2.6"); // or whatever version of Python you link against; don't know how relevant this is
    Py_InitializeEx(0);
    PyEval_InitThreads();
    PyGILState_STATE gilState = PyGILState_Ensure();

    NSString* script = /* path to a initialization script in your app bundle */;
    static char* arg0 = strdup([script fileSystemRepresentation]); // don't deallocate until Python runtime is terminated, if ever
    static char** argv = &arg0; // ditto
    PySys_SetArgv(1, argv);

    FILE* scriptFile = fopen([script fileSystemRepresentation], "r");
    int result = PyRun_SimpleFileEx(scriptFile, (char *)[[script lastPathComponent] fileSystemRepresentation], 1);
    if (result) /* handle error */;

    PyGILState_Release(gilState);
    if (gilState == PyGILState_LOCKED)
    {
        PyThreadState_Swap(NULL);
        PyEval_ReleaseLock();
    }

The script file mentioned above would just import modules and do initialization and then exit.  It wouldn't be a long-running script.  Since the application keeps running and the Python runtime is persistent, the state which is set up by the script persists, too.

After that, you have a few ways of interacting between the Python code and the Objective-C code.  Any Python class which inherits from a Cocoa class is registered with the Objective-C runtime.  It can be looked up with NSClassFromString().  Then, it's methods can be invoked directly.  You can make that simpler by declaring Objective-C interfaces for those classes.

The Objective-C code can pass its objects into the methods of the Python classes and the Python code can then operate on those objects.

Also, the Python code can find some objects itself, such as NSApp or various singletons.  It can then do things like set itself as delegates or register for notifications.

I believe that the classes of your app, since they were registered with the Objective-C runtime at the time that Python was loaded and your initialization script was run, can just be used directly in your Python scripts.  If that doesn't work, I'm sure you can use Foundation.NSClassFromString() to get access.

I hope that helps.

Cheers,
Ken


------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Pyobjc-dev mailing list
Pyo...@li...
https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Proper way to expose custom Obj-C classes to Python?

[Ian M. <ip...@po...>]

Ken & Georg,

Thanks for your replies.

I've already gotten this far -- i.e. I'm running the interpreter in
process, executing arbitrary python scripts in it, and trading objects back
and forth via NSClassFromString and other API with provided wrappers. What
I was hoping to achieve was "first-class" support for my classes -- like
the framework wrappers that ship with PyObjC for the system frameworks.

I've made some progress by brute force. I've gotten objective-metadata-tool
installed, and I'm currently working through getting it to scan my
framework's headers. This process appears under-documented, so my
experience is basically, "Try an invocation of objective-metadata-tool in
the debugger. See what fails. Figure out why it failed. Adjust invocation
to avoid that condition. Repeat." I'll report back with my findings if I
have any eventual success.

Thanks,
Ian




On Wed, Feb 19, 2014 at 2:56 AM, Ken Thomases <ke...@co...> wrote:

> On Feb 18, 2014, at 5:23 PM, Ian McCullough wrote:
>
> > I'm trying to determine the best way to expose custom,
> > application-specific, non-system-framework (i.e. not in one of the
> > framework wrappers provided with PyObjC) classes written in Objective-C
> to
> > python across the PyObjC bridge. My eventual hope is to develop a
> "hybrid"
> > application in which some portions of the app are in Objective-C and
> others
> > are in python, with the two side integrating via the PyObjC bridge. Most
> of
> > the documentation I've been able to find seems to focus on situations
> where
> > the goal is to have all the app-specific code be in python, and to have
> the
> > python call out to AppKit classes, etc via the bridge and the
> pre-packaged
> > system framework wrappers.
> >
> > I've not seen any indication that it's possible to expose classes from an
> > app.
>
> It is.  I don't know if this is the best way, but one way is to link an
> otherwise ordinary Cocoa app, written in Objective-C, to the Python
> framework.  You would then use the Python embedding API to set up the
> Python runtime and load and run some Python code.  You might do something
> like:
>
>     NSString* pythonPath = /* path within your app bundle to its Python
> files */;
>     setenv("PYTHONPATH", [pythonPath fileSystemRepresentation], 1);
>
>     Py_SetProgramName("/usr/bin/python2.6"); // or whatever version of
> Python you link against; don't know how relevant this is
>     Py_InitializeEx(0);
>     PyEval_InitThreads();
>     PyGILState_STATE gilState = PyGILState_Ensure();
>
>     NSString* script = /* path to a initialization script in your app
> bundle */;
>     static char* arg0 = strdup([script fileSystemRepresentation]); //
> don't deallocate until Python runtime is terminated, if ever
>     static char** argv = &arg0; // ditto
>     PySys_SetArgv(1, argv);
>
>     FILE* scriptFile = fopen([script fileSystemRepresentation], "r");
>     int result = PyRun_SimpleFileEx(scriptFile, (char *)[[script
> lastPathComponent] fileSystemRepresentation], 1);
>     if (result) /* handle error */;
>
>     PyGILState_Release(gilState);
>     if (gilState == PyGILState_LOCKED)
>     {
>         PyThreadState_Swap(NULL);
>         PyEval_ReleaseLock();
>     }
>
> The script file mentioned above would just import modules and do
> initialization and then exit.  It wouldn't be a long-running script.  Since
> the application keeps running and the Python runtime is persistent, the
> state which is set up by the script persists, too.
>
> After that, you have a few ways of interacting between the Python code and
> the Objective-C code.  Any Python class which inherits from a Cocoa class
> is registered with the Objective-C runtime.  It can be looked up with
> NSClassFromString().  Then, it's methods can be invoked directly.  You can
> make that simpler by declaring Objective-C interfaces for those classes.
>
> The Objective-C code can pass its objects into the methods of the Python
> classes and the Python code can then operate on those objects.
>
> Also, the Python code can find some objects itself, such as NSApp or
> various singletons.  It can then do things like set itself as delegates or
> register for notifications.
>
> I believe that the classes of your app, since they were registered with
> the Objective-C runtime at the time that Python was loaded and your
> initialization script was run, can just be used directly in your Python
> scripts.  If that doesn't work, I'm sure you can use
> Foundation.NSClassFromString() to get access.
>
> I hope that helps.
>
> Cheers,
> Ken
>
>

Re: [Pyobjc-dev] Proper way to expose custom Obj-C classes to Python?

[Georg S. <geo...@gm...>]

Hi,
I use python in my app a lot. The App is written in ObjectiveC but it can run python scripts.

The only thing I needed to do is to link to the python framework and run Py_Initialize(); once.

Then I run some python code like this:

	PyGILState_STATE gilState = PyGILState_Ensure();
	PyRun_SimpleString( "Some initializer code" );
	PyGILState_Release(gilState);

Best
Georg Seifert


Am 19.02.2014 um 08:56 schrieb Ken Thomases <ke...@co...>:

> On Feb 18, 2014, at 5:23 PM, Ian McCullough wrote:
> 
>> I'm trying to determine the best way to expose custom,
>> application-specific, non-system-framework (i.e. not in one of the
>> framework wrappers provided with PyObjC) classes written in Objective-C to
>> python across the PyObjC bridge. My eventual hope is to develop a "hybrid"
>> application in which some portions of the app are in Objective-C and others
>> are in python, with the two side integrating via the PyObjC bridge. Most of
>> the documentation I've been able to find seems to focus on situations where
>> the goal is to have all the app-specific code be in python, and to have the
>> python call out to AppKit classes, etc via the bridge and the pre-packaged
>> system framework wrappers.
>> 
>> I've not seen any indication that it's possible to expose classes from an
>> app.
> 
> It is.  I don't know if this is the best way, but one way is to link an otherwise ordinary Cocoa app, written in Objective-C, to the Python framework.  You would then use the Python embedding API to set up the Python runtime and load and run some Python code.  You might do something like:
> 
>    NSString* pythonPath = /* path within your app bundle to its Python files */;
>    setenv("PYTHONPATH", [pythonPath fileSystemRepresentation], 1);
> 
>    Py_SetProgramName("/usr/bin/python2.6"); // or whatever version of Python you link against; don't know how relevant this is
>    Py_InitializeEx(0);
>    PyEval_InitThreads();
>    PyGILState_STATE gilState = PyGILState_Ensure();
> 
>    NSString* script = /* path to a initialization script in your app bundle */;
>    static char* arg0 = strdup([script fileSystemRepresentation]); // don't deallocate until Python runtime is terminated, if ever
>    static char** argv = &arg0; // ditto
>    PySys_SetArgv(1, argv);
> 
>    FILE* scriptFile = fopen([script fileSystemRepresentation], "r");
>    int result = PyRun_SimpleFileEx(scriptFile, (char *)[[script lastPathComponent] fileSystemRepresentation], 1);
>    if (result) /* handle error */;
> 
>    PyGILState_Release(gilState);
>    if (gilState == PyGILState_LOCKED)
>    {
>        PyThreadState_Swap(NULL);
>        PyEval_ReleaseLock();
>    }
> 
> The script file mentioned above would just import modules and do initialization and then exit.  It wouldn't be a long-running script.  Since the application keeps running and the Python runtime is persistent, the state which is set up by the script persists, too.
> 
> After that, you have a few ways of interacting between the Python code and the Objective-C code.  Any Python class which inherits from a Cocoa class is registered with the Objective-C runtime.  It can be looked up with NSClassFromString().  Then, it's methods can be invoked directly.  You can make that simpler by declaring Objective-C interfaces for those classes.
> 
> The Objective-C code can pass its objects into the methods of the Python classes and the Python code can then operate on those objects.
> 
> Also, the Python code can find some objects itself, such as NSApp or various singletons.  It can then do things like set itself as delegates or register for notifications.
> 
> I believe that the classes of your app, since they were registered with the Objective-C runtime at the time that Python was loaded and your initialization script was run, can just be used directly in your Python scripts.  If that doesn't work, I'm sure you can use Foundation.NSClassFromString() to get access.
> 
> I hope that helps.
> 
> Cheers,
> Ken
> 
> 
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Proper way to expose custom Obj-C classes to Python?

[Ken T. <ke...@co...>]

On Feb 18, 2014, at 5:23 PM, Ian McCullough wrote:

> I'm trying to determine the best way to expose custom,
> application-specific, non-system-framework (i.e. not in one of the
> framework wrappers provided with PyObjC) classes written in Objective-C to
> python across the PyObjC bridge. My eventual hope is to develop a "hybrid"
> application in which some portions of the app are in Objective-C and others
> are in python, with the two side integrating via the PyObjC bridge. Most of
> the documentation I've been able to find seems to focus on situations where
> the goal is to have all the app-specific code be in python, and to have the
> python call out to AppKit classes, etc via the bridge and the pre-packaged
> system framework wrappers.
> 
> I've not seen any indication that it's possible to expose classes from an
> app.

It is.  I don't know if this is the best way, but one way is to link an otherwise ordinary Cocoa app, written in Objective-C, to the Python framework.  You would then use the Python embedding API to set up the Python runtime and load and run some Python code.  You might do something like:

    NSString* pythonPath = /* path within your app bundle to its Python files */;
    setenv("PYTHONPATH", [pythonPath fileSystemRepresentation], 1);

    Py_SetProgramName("/usr/bin/python2.6"); // or whatever version of Python you link against; don't know how relevant this is
    Py_InitializeEx(0);
    PyEval_InitThreads();
    PyGILState_STATE gilState = PyGILState_Ensure();

    NSString* script = /* path to a initialization script in your app bundle */;
    static char* arg0 = strdup([script fileSystemRepresentation]); // don't deallocate until Python runtime is terminated, if ever
    static char** argv = &arg0; // ditto
    PySys_SetArgv(1, argv);

    FILE* scriptFile = fopen([script fileSystemRepresentation], "r");
    int result = PyRun_SimpleFileEx(scriptFile, (char *)[[script lastPathComponent] fileSystemRepresentation], 1);
    if (result) /* handle error */;

    PyGILState_Release(gilState);
    if (gilState == PyGILState_LOCKED)
    {
        PyThreadState_Swap(NULL);
        PyEval_ReleaseLock();
    }

The script file mentioned above would just import modules and do initialization and then exit.  It wouldn't be a long-running script.  Since the application keeps running and the Python runtime is persistent, the state which is set up by the script persists, too.

After that, you have a few ways of interacting between the Python code and the Objective-C code.  Any Python class which inherits from a Cocoa class is registered with the Objective-C runtime.  It can be looked up with NSClassFromString().  Then, it's methods can be invoked directly.  You can make that simpler by declaring Objective-C interfaces for those classes.

The Objective-C code can pass its objects into the methods of the Python classes and the Python code can then operate on those objects.

Also, the Python code can find some objects itself, such as NSApp or various singletons.  It can then do things like set itself as delegates or register for notifications.

I believe that the classes of your app, since they were registered with the Objective-C runtime at the time that Python was loaded and your initialization script was run, can just be used directly in your Python scripts.  If that doesn't work, I'm sure you can use Foundation.NSClassFromString() to get access.

I hope that helps.

Cheers,
Ken

[Pyobjc-dev] Proper way to expose custom Obj-C classes to Python?

[Ian M. <ip...@po...>]

Hi,

I'm trying to determine the best way to expose custom,
application-specific, non-system-framework (i.e. not in one of the
framework wrappers provided with PyObjC) classes written in Objective-C to
python across the PyObjC bridge. My eventual hope is to develop a "hybrid"
application in which some portions of the app are in Objective-C and others
are in python, with the two side integrating via the PyObjC bridge. Most of
the documentation I've been able to find seems to focus on situations where
the goal is to have all the app-specific code be in python, and to have the
python call out to AppKit classes, etc via the bridge and the pre-packaged
system framework wrappers.

I've not seen any indication that it's possible to expose classes from an
app. But I did find this web page:
https://pythonhosted.org/pyobjc/dev/wrapping.html which makes it sound like
the best way would be for me to move any classes that need to be visible to
python out of my application, and into a framework (which I can embed in my
application), and then to adapt an existing framework wrapper to wrap this
newly-created framework. So far, the wrapper-adapting part is proving to be
easier said that done.

Looking at the existing wrappers, many of them have a compiled component
(i.e. .m files). As far as I can tell, that seems to be responsible for
bringing in protocols, constants and C functions. That said, it's not clear
to me what all triggers the need for a compiled extension. I also saw that
the _metadata.py files in existing wrappers have this at the top of them:
"This file is generated by objective.metadata". I tracked that down to this
repo: https://bitbucket.org/ronaldoussoren/objective.metadata which, with
some coaxing I could get to build, install and run, but I've not gotten it
to do anything useful yet -- i.e. how I get it to generate these
_metadata.py files is not obvious.

I'm content to keep fighting through the source on my own, but there's this
part of my mind saying, "You've *got* to be missing something. It can't
possibly be this involved to expose a framework to python." I can
understand the overhead for exposing C functions and constants, but all the
Objective-C stuff should be doable at runtime, right?

So, in sum:

1) Is this the right way to expose Objective-C classes to Python?

Assuming yes...

2) Exhaustively speaking, what triggers the need for a compiled extension?
3) What is the magic invocation to get objective.metadata to spit out the
_metadata.py files for my framework?
4) Any other tips that might help in with this "hybrid" app goal?

Many thanks,
Ian

Re: [Pyobjc-dev] Stackless?

[Ian M. <ip...@po...>]

Yeah, I'm not delusional enough to think that the whole NS* world would
magically be pickle-able, but it seemed within the realm of possibility
that I could implement pickling for the small subset of classes that
comprised my model. It still does seem like a reasonable proposition, but
I'm seeing enough squirrelly behavior between the stackless interpreter and
pyobjc right off the bat, that I'm sort of hesitant to press onward.  The
first thing was the fact that PyHeapTypeObject is the same as PyTypeObject
in stackless, so I had to go through and remove all the places that
accessed the ht_type of PyHeapTypeObject. A straightforward change, to be
sure, but then I started seeing lots of weirdness at run time (lots of
null-ptr dereferences around the python <-> pyobjc boundaries that made no
sense). I might have been willing to bite off the task of maintaining a
vendor branch of pyobjc for running with stackless python, but I don't want
to end up maintaining a vendor branch of stackless as well, so...

As far as serializing execution state, the classic native approach would be
to break the code down into a state machine, and then serialize the state
machine. For non-trivial code (you know, anything with loops or
subroutines, etc), breaking it down into a state machine becomes tedious.
Not using python also eliminates the scripty-ness/dynamism of using python.
By using python to implement the logic and flow, it becomes that much
easier to experiment with minor variations in the logic, etc.

Oh well... I might bang on it a little more to see what I can see, but I
assume that if someone on this list were up and running with pyobjc and
stackless they would have posted by now...

Thanks,
Ian


On Sun, Feb 16, 2014 at 3:57 PM, Diez B. Roggisch <de...@we...> wrote:

> I thought it was something along these lines.
>
> I guess all you can do is to set up your "host" application in a way that
> it can restore the save-game state from scratch, regardless of what that
> state currently is.
>
> But hoping that the whole NS*-world is persistable is bound to be
> disappointing :)
>
> Diez
>
> On Feb 16, 2014, at 9:28 PM, Ian McCullough <ip...@po...> wrote:
>
> The idea is to have a native Objective-C app, which hosts a stackless
> python interpreter in-process. The main feature of interest to me is the
> ability of stackless python to serialize a tasklet and deserialize and
> resume it later. Think of it as a "save game" mechanism, where the game
> logic is implemented in python -- you can save your game by serializing the
> state of the tasklet, and restore it later.
>
> The usage of pyobjc was intended to keep from having to keep a python-side
> model and a native-side model in sync.
>
> FWIW, I actually managed to get pyobjc to compile against stackless with
> some slight modifications, but I'm seeing some real weird behavior at
> runtime, so I'm not holding out much hope.
>
> Ian
>
>
>
> On Sun, Feb 16, 2014 at 3:17 PM, Diez B. Roggisch <de...@we...> wrote:
>
>> As long as objective C isn't stackless, I doubt there is much use to it.
>> What's your purpose?
>>
>> Diez
>>
>> On Feb 14, 2014, at 10:01 PM, Ian McCullough <ip...@po...> wrote:
>>
>> >
>> > Is it possible to build PyObjC for use with Stackless python?  My
>> attempts are pointing to "No" but I figured I'd ask.
>> > Thanks,Ian
>> >
>> >
>> ------------------------------------------------------------------------------
>> > Android apps run on BlackBerry 10
>> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
>> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
>> > Get your Android app in front of a whole new audience.  Start now.
>> >
>> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
>> > Pyobjc-dev mailing list
>> > Pyo...@li...
>> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
>

Re: [Pyobjc-dev] Stackless?

[Diez B. R. <de...@we...>]

I thought it was something along these lines.

I guess all you can do is to set up your "host" application in a way that it can restore the save-game state from scratch, regardless of what that state currently is.

But hoping that the whole NS*-world is persistable is bound to be disappointing :)

Diez

On Feb 16, 2014, at 9:28 PM, Ian McCullough <ip...@po...> wrote:

> The idea is to have a native Objective-C app, which hosts a stackless python interpreter in-process. The main feature of interest to me is the ability of stackless python to serialize a tasklet and deserialize and resume it later. Think of it as a "save game" mechanism, where the game logic is implemented in python -- you can save your game by serializing the state of the tasklet, and restore it later. 
> 
> The usage of pyobjc was intended to keep from having to keep a python-side model and a native-side model in sync.
> 
> FWIW, I actually managed to get pyobjc to compile against stackless with some slight modifications, but I'm seeing some real weird behavior at runtime, so I'm not holding out much hope.
> 
> Ian
> 
> 
> 
> On Sun, Feb 16, 2014 at 3:17 PM, Diez B. Roggisch <de...@we...> wrote:
> As long as objective C isn't stackless, I doubt there is much use to it. What's your purpose?
> 
> Diez
> 
> On Feb 14, 2014, at 10:01 PM, Ian McCullough <ip...@po...> wrote:
> 
> >
> > Is it possible to build PyObjC for use with Stackless python?  My attempts are pointing to "No" but I figured I'd ask.
> > Thanks,Ian
> >
> > ------------------------------------------------------------------------------
> > Android apps run on BlackBerry 10
> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
> > Get your Android app in front of a whole new audience.  Start now.
> > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> > Pyobjc-dev mailing list
> > Pyo...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 
> 
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Stackless?

[Ian M. <ip...@po...>]

The idea is to have a native Objective-C app, which hosts a stackless
python interpreter in-process. The main feature of interest to me is the
ability of stackless python to serialize a tasklet and deserialize and
resume it later. Think of it as a "save game" mechanism, where the game
logic is implemented in python -- you can save your game by serializing the
state of the tasklet, and restore it later.

The usage of pyobjc was intended to keep from having to keep a python-side
model and a native-side model in sync.

FWIW, I actually managed to get pyobjc to compile against stackless with
some slight modifications, but I'm seeing some real weird behavior at
runtime, so I'm not holding out much hope.

Ian



On Sun, Feb 16, 2014 at 3:17 PM, Diez B. Roggisch <de...@we...> wrote:

> As long as objective C isn't stackless, I doubt there is much use to it.
> What's your purpose?
>
> Diez
>
> On Feb 14, 2014, at 10:01 PM, Ian McCullough <ip...@po...> wrote:
>
> >
> > Is it possible to build PyObjC for use with Stackless python?  My
> attempts are pointing to "No" but I figured I'd ask.
> > Thanks,Ian
> >
> >
> ------------------------------------------------------------------------------
> > Android apps run on BlackBerry 10
> > Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> > Now with support for Jelly Bean, Bluetooth, Mapview and more.
> > Get your Android app in front of a whole new audience.  Start now.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> > Pyobjc-dev mailing list
> > Pyo...@li...
> > https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Re: [Pyobjc-dev] Stackless?

[Diez B. R. <de...@we...>]

As long as objective C isn't stackless, I doubt there is much use to it. What's your purpose?

Diez

On Feb 14, 2014, at 10:01 PM, Ian McCullough <ip...@po...> wrote:

> 
> Is it possible to build PyObjC for use with Stackless python?  My attempts are pointing to "No" but I figured I'd ask.
> Thanks,Ian
> 
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience.  Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Stackless?

[Ian M. <ip...@po...>]

Is it possible to build PyObjC for use with Stackless python?  My attempts
are pointing to "No" but I figured I'd ask.
Thanks,Ian

Re: [Pyobjc-dev] Failed to run the HotKey Example

[Jake W. <del...@gm...>]

I just ran this:

python -c "import Cocoa; print(Cocoa.__file__)"

and I got:

/Library/Python/2.7/site-packages/pyobjc_framework_Cocoa-2.5.1-py2.7-macosx-10.8-intel.egg/AppKit/_AppKit.so

Thanks for the analysis regarding the PyQT question. As long as the hotkey
registration code doesn't rely on NSApplication and can co-exist with PyQT,
it should work. I will do more investigation on this later.

Cheers,
Jake


On Thu, Jan 9, 2014 at 9:15 PM, Ronald Oussoren <ron...@ma...>wrote:

>
> On 09 Jan 2014, at 14:06, Jake Wang <del...@gm...> wrote:
>
> Hi Ronald,
>
> I just tried your new version of the example code.
>
> 1. When I built via: python setup.py py2app
>
> and run it with
>
> arch -i386 dist/HotKey.app/Contents/MacOS/HotKey
>
> 'print(sys.prefix)' printed the following line:
>
> /Users/jakew/Desktop/HotKeyPython/dist/HotKey.app/Contents/Resources
>
>
> and the app could be run correctly.
>
> 2. But if I built via: python setup.py py2app -A
>
> and run it with
>
> arch -i386 dist/HotKey.app/Contents/MacOS/HotKey
>
> 'print(sys.prefix)' printed the following line:
>
> /Library/Frameworks/Python.framework/Versions/2.7
>
> and the app failed to start duo to an error: 'ImportError: No module
> named Cocoa’
>
>
> That’s odd. What is printed if you run “python -c ‘import Cocoa;
> print(Cocoa.__file__)’’?
>
>
> It's good that the non-alias way worked! Thanks a lot.
>
> I would like to use this HotKey feature with a PyQT application, so is it
> possible
> to not use NSApplication to RegisterEventHotKey, and instead, do it in
> PyQT application
> class? Or, is there other ways to make the HotKey function work with PyQT?
>
>
> I don’t know because I’ve never used PyQt on OSX. The registration code in
> finishLaunching should work just as well in a Qt application (that just
> uses the Carbon package to register a hotkey), but I don’t know how you’d
> inspect native events in PyQt (the code in sendEvent_).
>
> Ronald
>
>

Re: [Pyobjc-dev] Failed to run the HotKey Example

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

On 09 Jan 2014, at 14:06, Jake Wang <del...@gm...> wrote:

> Hi Ronald,
> 
> I just tried your new version of the example code.
> 
> 1. When I built via: python setup.py py2app
> 
> and run it with
> 
> arch -i386 dist/HotKey.app/Contents/MacOS/HotKey
> 
> 'print(sys.prefix)' printed the following line:
> 
> /Users/jakew/Desktop/HotKeyPython/dist/HotKey.app/Contents/Resources
> 
> and the app could be run correctly.
> 
> 2. But if I built via: python setup.py py2app -A
> 
> and run it with
> 
> arch -i386 dist/HotKey.app/Contents/MacOS/HotKey
> 
> 'print(sys.prefix)' printed the following line:
> 
> /Library/Frameworks/Python.framework/Versions/2.7
> 
> and the app failed to start duo to an error: 'ImportError: No module named Cocoa’

That’s odd. What is printed if you run “python -c ‘import Cocoa; print(Cocoa.__file__)’’?

> 
> It's good that the non-alias way worked! Thanks a lot.
> 
> I would like to use this HotKey feature with a PyQT application, so is it possible 
> to not use NSApplication to RegisterEventHotKey, and instead, do it in PyQT application 
> class? Or, is there other ways to make the HotKey function work with PyQT?

I don’t know because I’ve never used PyQt on OSX. The registration code in finishLaunching should work just as well in a Qt application (that just uses the Carbon package to register a hotkey), but I don’t know how you’d inspect native events in PyQt (the code in sendEvent_).

Ronald

Re: [Pyobjc-dev] Failed to run the HotKey Example

[Jake W. <del...@gm...>]

Hi Ronald,

I just tried your new version of the example code.

1. When I built via: python setup.py py2app

and run it with

arch -i386 dist/HotKey.app/Contents/MacOS/HotKey

'print(sys.prefix)' printed the following line:

/Users/jakew/Desktop/HotKeyPython/dist/HotKey.app/Contents/Resources

and the app could be run correctly.

2. But if I built via: python setup.py py2app -A

and run it with

arch -i386 dist/HotKey.app/Contents/MacOS/HotKey

'print(sys.prefix)' printed the following line:

/Library/Frameworks/Python.framework/Versions/2.7

and the app failed to start duo to an error: 'ImportError: No module named
Cocoa'

It's good that the non-alias way worked! Thanks a lot.

I would like to use this HotKey feature with a PyQT application, so is it
possible
to not use NSApplication to RegisterEventHotKey, and instead, do it in PyQT
application
class? Or, is there other ways to make the HotKey function work with PyQT?

Thanks,
Jake


On Thu, Jan 9, 2014 at 7:00 PM, Ronald Oussoren <ron...@ma...>wrote:

>
> On 04 Jan 2014, at 05:30, Jake Wang <del...@gm...> wrote:
>
> Thank you Ronald.
>
> I will try it again, and look forward to seeing if you can run it
> successfully.
>
>
> I’ve tested the example with a slight newer version of the example code
> (and an experimental version of PyObjC, but that shouldn’t matter here) and
> it works for me.
>
> I tested both with ‘python setup.py py2app -A’ and ‘python setup.py
> py2app’. I did have to ensure that the application was started in 32-bit
> mode, either by running from the Terminal as "arch -i386
> dist/HotKey.app/Contents/MacOS/HotKey” or by by selecting “Open in 32-bit
> mode” in the Get Info popup in the Finder.
>
> The newer version is attached below and only changes the way code is
> imported, it no longer uses “from Cocoa import *” (that also shouldn’t
> affect to way the application is launched, but should result in a faster
> launching application).
>
> I really don’t understand why an alias build doesn’t work for you even
> though just running “python HotKey.py” does seem to find PyObjC (otherwise
> you’d have gotten an import error there as well, and instead of the error
> message from the AppKit framework). Are you really sure that you used the
> same python executable for running HotKey.py directly and for
> running “python setup.py py2app -A”?  You could add “import sys;
> print(sys.prefix)” to the start of HotKey.py to make sure, that should
> print the same prefix in both ways of running the script.
>
> Ronald
>
>
>
>
> Jake
>
>
> On Fri, Jan 3, 2014 at 10:51 PM, Ronald Oussoren <ron...@ma...>wrote:
>
>> Hi,
>>
>> This example like all pyobjc examples with a setup.py file needs to be
>> run from an application bundle (run "python setup.py -A").
>>
>> This particular example has some other restrictions (which aren't
>> documented on the website right now):
>>
>> * It requires python 2.x because it uses the Carbon package that was
>> removed in Python 3.0
>>
>> * It requires a 32-bit build of python 2.x because the Carbon package is
>> ancient and uses functions that Apple hasn't made available in 64-bit code.
>>
>>
>> The last restriction makes using py2app harder, because the app bundle
>> will happily try to run in 64-bit mode when you build using a python that
>> supports 64-bit code. The easiest workaround is to disable 64-bit through
>> the finder (for this application).
>>
>> I'm not sure why the application gives an ImportError exception when you
>> try to run it. The usual problem is that the python you're using to run
>> py2app is a different one than you expect (e.g. one without pyobjc
>> installed), but that doesn't seem to be the problem here because you don't
>> get an ImportError when running the script from the command-line.
>>
>> Ronald
>>
>> P.S. I haven't tried to run this example in a long while, I'll try to do
>> so tonight.
>>
>> On Jan 03, 2014, at 03:02 PM, Jake Wang <del...@gm...> wrote:
>>
>> Hi,
>>
>> I was trying to run the sample PyObjc HotKey example app downloaded from
>> this link:
>> http://pythonhosted.org/pyobjc/_downloads/PyObjCExample-HotKeyPython.zip
>>
>> (My environment: Mac OS X 10.8.5, Python 2.7.5)
>>
>> After I unpacked the file, I tried to:
>>
>> 1) run it via:
>>
>> python HotKey.py
>>
>> and got the following error:
>>
>> Traceback (most recent call last):
>>   File "HotKey.py", line 18, in <module>
>>     from Carbon.CarbonEvt import RegisterEventHotKey,
>> GetApplicationEventTarget
>> ImportError: cannot import name RegisterEventHotKey
>>
>> 2) run it in 32bit mode, as I thought this might only be supported in
>> 32bit.
>>
>> arch -i386 python HotKey.py
>>
>> and got another error:
>>
>> 2014-01-03 21:57:41.083 Python[2047:f0b] No Info.plist file in
>> application bundle or no NSPrincipalClass in the Info.plist file, exiting
>>
>> 3) Then I thought I might have to package it as an xx.app to run, then I
>> executed the following command to package it:
>>
>> python setup.py py2app -A
>>
>> (also tried 'arch -i386 python setup.py py2app -A')
>>
>> The app couldn't be run, and then ran it from console, I got the
>> following errors:
>>
>> Traceback (most recent call last):
>>   File
>> "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py",
>> line 69, in <module>
>>     _run()
>>   File
>> "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py",
>> line 62, in _run
>>     exec(compile(source, script, 'exec'), globals(), globals())
>>   File
>> "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/HotKey.py", line
>> 16, in <module>
>>     from AppKit import *
>> ImportError: No module named AppKit
>> 2014-01-03 22:00:41.775 HotKey[2126:707] HotKey Error
>>
>> Is it possible to run it in some way? Thanks in advance!
>>
>> Thanks,
>> Jake
>>
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT
>> organizations don't have a clear picture of how application performance
>> affects their revenue. With AppDynamics, you get 100% visibility into
>> your
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
>> Pro!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>>
>>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>
>
>

Re: [Pyobjc-dev] Failed to run the HotKey Example

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

On 04 Jan 2014, at 05:30, Jake Wang <del...@gm...> wrote:

> Thank you Ronald.
> 
> I will try it again, and look forward to seeing if you can run it successfully.

I’ve tested the example with a slight newer version of the example code (and an experimental version of PyObjC, but that shouldn’t matter here) and it works for me. 

I tested both with ‘python setup.py py2app -A’ and ‘python setup.py py2app’. I did have to ensure that the application was started in 32-bit mode, either by running from the Terminal as "arch -i386 dist/HotKey.app/Contents/MacOS/HotKey” or by by selecting “Open in 32-bit mode” in the Get Info popup in the Finder.

The newer version is attached below and only changes the way code is imported, it no longer uses “from Cocoa import *” (that also shouldn’t affect to way the application is launched, but should result in a faster launching application).

I really don’t understand why an alias build doesn’t work for you even though just running “python HotKey.py” does seem to find PyObjC (otherwise you’d have gotten an import error there as well, and instead of the error message from the AppKit framework). Are you really sure that you used the same python executable for running HotKey.py directly and for running “python setup.py py2app -A”?  You could add “import sys; print(sys.prefix)” to the start of HotKey.py to make sure, that should print the same prefix in both ways of running the script.

Ronald


> 
> Jake
> 
> 
> On Fri, Jan 3, 2014 at 10:51 PM, Ronald Oussoren <ron...@ma...> wrote:
> Hi,
> 
> This example like all pyobjc examples with a setup.py file needs to be run from an application bundle (run "python setup.py -A").
> 
> This particular example has some other restrictions (which aren't documented on the website right now):
> 
> * It requires python 2.x because it uses the Carbon package that was removed in Python 3.0
> 
> * It requires a 32-bit build of python 2.x because the Carbon package is ancient and uses functions that Apple hasn't made available in 64-bit code.  
> 
> The last restriction makes using py2app harder, because the app bundle will happily try to run in 64-bit mode when you build using a python that supports 64-bit code. The easiest workaround is to disable 64-bit through the finder (for this application).
> 
> I'm not sure why the application gives an ImportError exception when you try to run it. The usual problem is that the python you're using to run py2app is a different one than you expect (e.g. one without pyobjc installed), but that doesn't seem to be the problem here because you don't get an ImportError when running the script from the command-line.
> 
> Ronald
> 
> P.S. I haven't tried to run this example in a long while, I'll try to do so tonight.
> 
> On Jan 03, 2014, at 03:02 PM, Jake Wang <del...@gm...> wrote:
> 
>> Hi,
>> 
>> I was trying to run the sample PyObjc HotKey example app downloaded from this link: http://pythonhosted.org/pyobjc/_downloads/PyObjCExample-HotKeyPython.zip
>> 
>> (My environment: Mac OS X 10.8.5, Python 2.7.5)
>> 
>> After I unpacked the file, I tried to:
>> 
>> 1) run it via:
>> 
>> python HotKey.py
>> 
>> and got the following error:
>> 
>> Traceback (most recent call last):
>>   File "HotKey.py", line 18, in <module>
>>     from Carbon.CarbonEvt import RegisterEventHotKey, GetApplicationEventTarget
>> ImportError: cannot import name RegisterEventHotKey
>> 
>> 2) run it in 32bit mode, as I thought this might only be supported in 32bit.
>> 
>> arch -i386 python HotKey.py
>> 
>> and got another error:
>> 
>> 2014-01-03 21:57:41.083 Python[2047:f0b] No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting
>> 
>> 3) Then I thought I might have to package it as an xx.app to run, then I executed the following command to package it:
>> 
>> python setup.py py2app -A
>> 
>> (also tried 'arch -i386 python setup.py py2app -A')
>> 
>> The app couldn't be run, and then ran it from console, I got the following errors:
>> 
>> Traceback (most recent call last):
>>   File "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py", line 69, in <module>
>>     _run()
>>   File "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py", line 62, in _run
>>     exec(compile(source, script, 'exec'), globals(), globals())
>>   File "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/HotKey.py", line 16, in <module>
>>     from AppKit import *
>> ImportError: No module named AppKit
>> 2014-01-03 22:00:41.775 HotKey[2126:707] HotKey Error
>> 
>> Is it possible to run it in some way? Thanks in advance!
>> 
>> Thanks,
>> Jake
>> ------------------------------------------------------------------------------
>> Rapidly troubleshoot problems before they affect your business. Most IT 
>> organizations don't have a clear picture of how application performance 
>> affects their revenue. With AppDynamics, you get 100% visibility into your 
>> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
>> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Pyobjc-dev mailing list
>> Pyo...@li...
>> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
> 
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT 
> organizations don't have a clear picture of how application performance 
> affects their revenue. With AppDynamics, you get 100% visibility into your 
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk_______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

Re: [Pyobjc-dev] Failed to run the HotKey Example

[Jake W. <del...@gm...>]

Thank you Ronald.

I will try it again, and look forward to seeing if you can run it
successfully.

Jake


On Fri, Jan 3, 2014 at 10:51 PM, Ronald Oussoren <ron...@ma...>wrote:

> Hi,
>
> This example like all pyobjc examples with a setup.py file needs to be run
> from an application bundle (run "python setup.py -A").
>
> This particular example has some other restrictions (which aren't
> documented on the website right now):
>
> * It requires python 2.x because it uses the Carbon package that was
> removed in Python 3.0
>
> * It requires a 32-bit build of python 2.x because the Carbon package is
> ancient and uses functions that Apple hasn't made available in 64-bit code.
>
>
> The last restriction makes using py2app harder, because the app bundle
> will happily try to run in 64-bit mode when you build using a python that
> supports 64-bit code. The easiest workaround is to disable 64-bit through
> the finder (for this application).
>
> I'm not sure why the application gives an ImportError exception when you
> try to run it. The usual problem is that the python you're using to run
> py2app is a different one than you expect (e.g. one without pyobjc
> installed), but that doesn't seem to be the problem here because you don't
> get an ImportError when running the script from the command-line.
>
> Ronald
>
> P.S. I haven't tried to run this example in a long while, I'll try to do
> so tonight.
>
> On Jan 03, 2014, at 03:02 PM, Jake Wang <del...@gm...> wrote:
>
> Hi,
>
> I was trying to run the sample PyObjc HotKey example app downloaded from
> this link:
> http://pythonhosted.org/pyobjc/_downloads/PyObjCExample-HotKeyPython.zip
>
> (My environment: Mac OS X 10.8.5, Python 2.7.5)
>
> After I unpacked the file, I tried to:
>
> 1) run it via:
>
> python HotKey.py
>
> and got the following error:
>
> Traceback (most recent call last):
>   File "HotKey.py", line 18, in <module>
>     from Carbon.CarbonEvt import RegisterEventHotKey,
> GetApplicationEventTarget
> ImportError: cannot import name RegisterEventHotKey
>
> 2) run it in 32bit mode, as I thought this might only be supported in
> 32bit.
>
> arch -i386 python HotKey.py
>
> and got another error:
>
> 2014-01-03 21:57:41.083 Python[2047:f0b] No Info.plist file in application
> bundle or no NSPrincipalClass in the Info.plist file, exiting
>
> 3) Then I thought I might have to package it as an xx.app to run, then I
> executed the following command to package it:
>
> python setup.py py2app -A
>
> (also tried 'arch -i386 python setup.py py2app -A')
>
> The app couldn't be run, and then ran it from console, I got the following
> errors:
>
> Traceback (most recent call last):
>   File
> "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py",
> line 69, in <module>
>     _run()
>   File
> "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py",
> line 62, in _run
>     exec(compile(source, script, 'exec'), globals(), globals())
>   File
> "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/HotKey.py", line
> 16, in <module>
>     from AppKit import *
> ImportError: No module named AppKit
> 2014-01-03 22:00:41.775 HotKey[2126:707] HotKey Error
>
> Is it possible to run it in some way? Thanks in advance!
>
> Thanks,
> Jake
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
>

Re: [Pyobjc-dev] Failed to run the HotKey Example

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

Hi,

This example like all pyobjc examples with a setup.py file needs to be run from an application bundle (run "python setup.py -A").

This particular example has some other restrictions (which aren't documented on the website right now):

* It requires python 2.x because it uses the Carbon package that was removed in Python 3.0

* It requires a 32-bit build of python 2.x because the Carbon package is ancient and uses functions that Apple hasn't made available in 64-bit code.  

The last restriction makes using py2app harder, because the app bundle will happily try to run in 64-bit mode when you build using a python that supports 64-bit code. The easiest workaround is to disable 64-bit through the finder (for this application).

I'm not sure why the application gives an ImportError exception when you try to run it. The usual problem is that the python you're using to run py2app is a different one than you expect (e.g. one without pyobjc installed), but that doesn't seem to be the problem here because you don't get an ImportError when running the script from the command-line.

Ronald

P.S. I haven't tried to run this example in a long while, I'll try to do so tonight.

On Jan 03, 2014, at 03:02 PM, Jake Wang <del...@gm...> wrote:

Hi,

I was trying to run the sample PyObjc HotKey example app downloaded from this link: http://pythonhosted.org/pyobjc/_downloads/PyObjCExample-HotKeyPython.zip

(My environment: Mac OS X 10.8.5, Python 2.7.5)

After I unpacked the file, I tried to:

1) run it via:

python HotKey.py

and got the following error:

Traceback (most recent call last):
  File "HotKey.py", line 18, in <module>
    from Carbon.CarbonEvt import RegisterEventHotKey, GetApplicationEventTarget
ImportError: cannot import name RegisterEventHotKey

2) run it in 32bit mode, as I thought this might only be supported in 32bit.

arch -i386 python HotKey.py

and got another error:

2014-01-03 21:57:41.083 Python[2047:f0b] No Info.plist file in application bundle or no NSPrincipalClass in the Info.plist file, exiting

3) Then I thought I might have to package it as an xx.app to run, then I executed the following command to package it:

python setup.py py2app -A

(also tried 'arch -i386 python setup.py py2app -A')

The app couldn't be run, and then ran it from console, I got the following errors:

Traceback (most recent call last):
  File "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py", line 69, in <module>
    _run()
  File "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py", line 62, in _run
    exec(compile(source, script, 'exec'), globals(), globals())
  File "/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/HotKey.py", line 16, in <module>
    from AppKit import *
ImportError: No module named AppKit
2014-01-03 22:00:41.775 HotKey[2126:707] HotKey Error

Is it possible to run it in some way? Thanks in advance!

Thanks,
Jake
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Pyobjc-dev mailing list
Pyo...@li...
https://lists.sourceforge.net/lists/listinfo/pyobjc-dev

[Pyobjc-dev] Failed to run the HotKey Example

[Jake W. <del...@gm...>]

Hi,

I was trying to run the sample PyObjc HotKey example app downloaded from
this link:
http://pythonhosted.org/pyobjc/_downloads/PyObjCExample-HotKeyPython.zip

(My environment: Mac OS X 10.8.5, Python 2.7.5)

After I unpacked the file, I tried to:

1) run it via:

python HotKey.py

and got the following error:

Traceback (most recent call last):
  File "HotKey.py", line 18, in <module>
    from Carbon.CarbonEvt import RegisterEventHotKey,
GetApplicationEventTarget
ImportError: cannot import name RegisterEventHotKey

2) run it in 32bit mode, as I thought this might only be supported in 32bit.

arch -i386 python HotKey.py

and got another error:

2014-01-03 21:57:41.083 Python[2047:f0b] No Info.plist file in application
bundle or no NSPrincipalClass in the Info.plist file, exiting

3) Then I thought I might have to package it as an xx.app to run, then I
executed the following command to package it:

python setup.py py2app -A

(also tried 'arch -i386 python setup.py py2app -A')

The app couldn't be run, and then ran it from console, I got the following
errors:

Traceback (most recent call last):
  File
"/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py",
line 69, in <module>
    _run()
  File
"/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/dist/HotKey.app/Contents/Resources/__boot__.py",
line 62, in _run
    exec(compile(source, script, 'exec'), globals(), globals())
  File
"/Users/jiakuanwang/opensource/PyObjCExample-HotKeyPython/HotKey.py", line
16, in <module>
    from AppKit import *
ImportError: No module named AppKit
2014-01-03 22:00:41.775 HotKey[2126:707] HotKey Error

Is it possible to run it in some way? Thanks in advance!

Thanks,
Jake