pyglet + pypy + mac

[Tristam MacDonald]

I see a number of messages in the past year from users who have managed to successfully run pyglet under PyPy/Mac/64-bit, but no mention of how they did so.

The pyglet trunk is still using PyObjC, so that is out.

I cloned the evilphillip-cocoa-ctypes repository from google code, and that does bring up a window and perform basic rendering, but there is a constant stream of warnings on the console, and mouse events seem to cause everything to crash. I wasn't able to execute even the first test from tests/tests.py.

Would anyone care to elaborate on the process? Is there a different ctypes repository/branch that I am overlooking?

--

Tristam MacDonald

System Administrator, Suffolk University Math & CS Department

http://swiftcoder.wordpress.com/

[Tristam MacDonald]

On Mon, Nov 21, 2011 at 7:01 PM, Tristam MacDonald <swift...@gmail.com> wrote:

I cloned the evilphillip-cocoa-ctypes repository from google code, and that does bring up a window and perform basic rendering, but there is a constant stream of warnings on the console, and mouse events seem to cause everything to crash. I wasn't able to execute even the first test from tests/tests.py.

My apologies - after several minutes of churning, PyPy did indeed execute the tests from tests/tests.py. I am not quite sure why it took so long to prepare, but no mind.

The mouse event error turned out to be a missing void return type specification for the call to [NSApplication sendEvent:], a working patch is as follows:

===============================================================

diff -r b4dd39184f08 pyglet/app/cocoa.py

--- a/pyglet/app/cocoa.py Wed Apr 06 07:54:59 2011 -0500

+++ b/pyglet/app/cocoa.py Mon Nov 21 19:30:40 2011 -0500

@@ -109,7 +109,7 @@

             if event_type != NSApplicationDefined:

                 # Send out event as normal.  Responders will still receive 

                 # keyUp:, keyDown:, and flagsChanged: events.

-                send_message(self.NSApp, 'sendEvent:', event)

+                send_message(self.NSApp, 'sendEvent:', event, restype=None)

 

                 # Resend key events as special pyglet-specific messages

                 # which supplant the keyDown:, keyUp:, and flagsChanged: messages

===============================================================

I can't seem to get pypy to pickup keyboard events - the pyglet window isn't managing to take focus away from the terminal window. The fix for this is to run from within an App bundle (or pretend to, as the system 'pythonw' does), but that part of my original Cocoa port doesn't seem to have survived the development process.

[Tristam MacDonald]

On Mon, Nov 21, 2011 at 7:39 PM, Tristam MacDonald <swift...@gmail.com> wrote:

I can't seem to get pypy to pickup keyboard events - the pyglet window isn't managing to take focus away from the terminal window. The fix for this is to run from within an App bundle (or pretend to, as the system 'pythonw' does), but that part of my original Cocoa port doesn't seem to have survived the development process.

Aha! I finally found the post-Snow Leopard solution to this problem, in the form of the little-known [NSApplication setActivationPolicy:  NSApplicationActivationPolicyRegular] method.

This method is unavailable pre-Snow Leopard. Is a Cocoa backend pre-Snow Leopard possible or desirable? Do we need to special case this for older OS versions?

Simplistic patch against the evilphillip-cocoa-ctypes repository is as follows:

========================================================

diff -r acee3bdb3b9d pyglet/app/cocoa.py

--- a/pyglet/app/cocoa.py Mon Nov 21 19:28:22 2011 -0500

+++ b/pyglet/app/cocoa.py Tue Nov 22 01:05:16 2011 -0500

@@ -76,6 +76,7 @@

         # Create an autorelease pool for menu creation and finishLaunching

         self.pool = alloc_init('NSAutoreleasePool')

         create_menu()

+        send_message(self.NSApp, 'setActivationPolicy:', 0)

         send_message(self.NSApp, 'finishLaunching')

         send_message(self.NSApp, 'activateIgnoringOtherApps:', True)

         #send_message(self.pool, 'drain')

========================================================

[Richard Jones]

Pre Snow Leopard the carbon interface should suffice.

Sent from my phone - please excuse brevity.

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To post to this group, send email to pyglet...@googlegroups.com.
To unsubscribe from this group, send email to pyglet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.

[Phillip Nguyen]

Thanks! I applied both of your fixes to the ctypes clone.
(Though on my end I still can't get anything to run in
PyPy 1.6. It gives me an "unknown shape" assertion
error during a call to CFStringGetCString. I might try the
newer version later today and see if that fixes anything. )

--phillip

On Nov 22, 12:17 am, Tristam MacDonald <swiftco...@gmail.com> wrote:

> On Mon, Nov 21, 2011 at 7:39 PM, Tristam MacDonald <swiftco...@gmail.com>wrote:
>
> > I can't seem to get pypy to pickup keyboard events - the pyglet window
> > isn't managing to take focus away from the terminal window. The fix for
> > this is to run from within an App bundle (or pretend to, as the system
> > 'pythonw' does), but that part of my original Cocoa port doesn't seem to
> > have survived the development process.
>
> Aha! I finally found the post-Snow Leopard solution to this problem, in the
> form of the little-known [NSApplication setActivationPolicy:

> NSApplicationActivationPolicyRegular<http://developer.apple.com/library/mac/documentation/AppKit/Reference...>]

[Tristam MacDonald]

On Tue, Nov 22, 2011 at 11:57 AM, Phillip Nguyen <evil.p...@gmail.com> wrote:

Thanks! I applied both of your fixes to the ctypes clone.
(Though on my end I still can't get anything to run in
PyPy 1.6.  It gives me an "unknown shape" assertion
error during a call to CFStringGetCString.  I might try the
newer version later today and see if that fixes anything. )

--phillip

I just grabbed the stock pypy 1.7 w/ JIT binary yesterday - hopefully it works for you as well.

Even though my patches fixed the major event crash, and fixes the input focus problem, there are still some crashes happening during event handling. I haven't managed to get a reliable backtrace from one of these crashes yet though, as they seem to occur outside of the normal pyglet event loop.

Although most of the examples run, the test suite UI in the terminal doesn't work at all (I think because of the event problems, but I can't be sure). 

Would someone with access to Windows/Linux be willing to run tests/tests.py under pypy 1.7, and let me know what works and what doesn't? I'd like to figure out what portion of the current problems are pypy issues and what portion is our platform code.

[anatoly techtonik]

On Tuesday, November 22, 2011 8:19:12 PM UTC+3, swiftcoder wrote:

Would someone with access to Windows/Linux be willing to run tests/tests.py under pypy 1.7, and let me know what works and what doesn't? I'd like to figure out what portion of the current problems are pypy issues and what portion is our platform code.

Ubuntu 11.10. It took a while to run tests with standard CPython, so I've run out of time to test PyPy. It will help to group tests, so allow multiple users test different parts separately.

Right from the start PyPy 1.7 throws this warning.

tests/../pyglet/image/codecs/gdkpixbuf2.py:161: RuntimeWarning: C function without declared arguments called

  gdk.g_type_init()

 

[Nathan]

So, Philip, are you _maintaining_ a separate ctypes-based pyglet fork,
then? I've been focusing on AVbin a lot lately, but I really need to
get my project(s) running pyglet on OS X again. Where should I focus
my efforts, trunk or evilphillip-cocoa-ctypes?

~ Nathan

[Phillip Nguyen]

On Nov 24, 10:11 am, Nathan <nathan.sto...@gmail.com> wrote:
> So, Philip, are you _maintaining_ a separate ctypes-based pyglet fork,
> then?  I've been focusing on AVbin a lot lately, but I really need to
> get my project(s) running pyglet on OS X again.  Where should I focus
> my efforts, trunk or evilphillip-cocoa-ctypes?

No, I'm definitely not maintaining anything at this point.
You should focus your efforts (thank-you, btw) on the trunk.

--phillip

[Nathan]

Okay, great. Trunk it is.

~ Nathan

[Tristam MacDonald]

Let be very explicit here. As I understand it:

pyglet trunk contains a Cocoa implementation via PyObjC, which works on Apple's stock python, and occasionally works on other python packages, but notably does not work on PyPy.

evilphillip-cocoa-ctypes, regardless of whether it is maintained, contains a Cocoa implementation via a custom ctypes layer, *without* PyObjC, which should (when complete) run on *all* python packages, including PyPy.

Am I correct?

[Nathan]

On Thu, Nov 24, 2011 at 7:26 PM, Tristam MacDonald <swift...@gmail.com> wrote:
> Let be very explicit here. As I understand it:
> pyglet trunk contains a Cocoa implementation via PyObjC, which works on
> Apple's stock python, and occasionally works on other python packages, but
> notably does not work on PyPy.

> evilphillip-cocoa-ctypes, regardless of whether it is maintained, contains a
> Cocoa implementation via a custom ctypes layer, *without* PyObjC, which
> should (when complete) run on *all* python packages, including PyPy.
> Am I correct?
> --
> Tristam MacDonald

That's a great conversation to have. To help determine the best
long-term strategy for 64-bit support on OS X, I would add the
questions:

- What are the pros/cons of a ctypes implementation in general?
- What are the pros/cons of a PyObjC implementation in general?

From the (admittedly limited) information I have run across so far, it
would seem that ctypes implementation has the major advantage of being
able to be run by more python environments than the PyObjC
implementation, and the disadvantage of being more work to implement.
If that major advantage is important to people willing to contribute
coding time.

I've been a lurker on the PyObjC mailing list for many years now, ever
since I heard of it, got interested in maybe using it, but then never
did. From what I see, PyObjC is a one-man project that doesn't get a
whole lot of attention, as the mailing list is extremely low traffic.
Occasionally when things break, or changes happen to OS X, PyObjC
seems to take awhile to catch up. To the his credit, that one guy
seems to do a great job when he has the time to work on it. I don't
know much more about it than that.

I've never used ctypes. All I know is the basic information that it's
a built-in way for Python to wrap libraries in pure python.

~ Nathan

[Phillip Nguyen]

On Nov 24, 10:53 pm, Nathan <nathan.sto...@gmail.com> wrote:

> On Thu, Nov 24, 2011 at 7:26 PM, Tristam MacDonald <swiftco...@gmail.com> wrote:
> > Let be very explicit here. As I understand it:
> > pyglet trunk contains a Cocoa implementation via PyObjC, which works on
> > Apple's stock python, and occasionally works on other python packages, but
> > notably does not work on PyPy.
> > evilphillip-cocoa-ctypes, regardless of whether it is maintained, contains a
> > Cocoa implementation via a custom ctypes layer, *without* PyObjC, which
> > should (when complete) run on *all* python packages, including PyPy.
> > Am I correct?

Yes, that's correct. To add to that, back when I was still working on
this, I wrote a third cocoa implementation for pyglet based on ctypes,
which arguably looks a bit nicer than what's in evilphillip-cocoa-
ctypes (no more send_message and no more specifying argument and
return types with each call) but is still kind of rough. I would like
to eventually replace the trunk with this code, however I just haven't
had time to do any work on it and I don't want to simply obliterate
PyObjC implementation which does work. I also haven't had a chance to
see how this implementation interacts with PyPy. I would post it as
another branch or clone, but I think things are confusing enough as it
is.

I feel like it would be a good idea to have an official release of 1.2
containing the PyObjC backend before I start completely changing
what's in the trunk.

> That's a great conversation to have.  To help determine the best
> long-term strategy for 64-bit support on OS X, I would add the
> questions:
>
> - What are the pros/cons of a ctypes implementation in general?
> - What are the pros/cons of a PyObjC implementation in general?
>
> From the (admittedly limited) information I have run across so far, it
> would seem that ctypes implementation has the major advantage of being
> able to be run by more python environments than the PyObjC
> implementation, and the disadvantage of being more work to implement.
> If that major advantage is important to people willing to contribute
> coding time.
>
> I've been a lurker on the PyObjC mailing list for many years now, ever
> since I heard of it, got interested in maybe using it, but then never
> did.  From what I see, PyObjC is a one-man project that doesn't get a
> whole lot of attention, as the mailing list is extremely low traffic.
> Occasionally when things break, or changes happen to OS X, PyObjC
> seems to take awhile to catch up.  To the his credit, that one guy
> seems to do a great job when he has the time to work on it.  I don't
> know much more about it than that.

This is my impression also.

--phillip

[Tristam MacDonald]

On Fri, Nov 25, 2011 at 2:19 PM, Phillip Nguyen <evil.p...@gmail.com> wrote:

I feel like it would be a good idea to have an official release of 1.2
containing the PyObjC backend before I start completely changing
what's in the trunk.

Not a bad idea, and I am happy to help with testing/fixing trunk for that purpose.

 

> That's a great conversation to have.  To help determine the best
> long-term strategy for 64-bit support on OS X, I would add the
> questions:
>
> - What are the pros/cons of a ctypes implementation in general?
> - What are the pros/cons of a PyObjC implementation in general?
>
> From the (admittedly limited) information I have run across so far, it
> would seem that ctypes implementation has the major advantage of being
> able to be run by more python environments than the PyObjC
> implementation, and the disadvantage of being more work to implement.
> If that major advantage is important to people willing to contribute
> coding time.

A solution that doesn't support PyPy is a non-starter for me. Since PyObjC is unlikely to ever be well supported under PyPy, that implies we either:

a) port PyObjC to ctypes, and continue to depend on PyObjC, or

b) port pyglet to ctypes.

The former being cooler (and having wider application than just pyglet), while the latter is considerably less work.

***

Philip: I'm going to have some free time coming up, and I want to get the ctypes implementation up and running (particularly on pypy). I'm not that familiar with distributed development using mercurial - does it make more sense for you to grant me write access on the ctypes repository, or for me to clone it and us to push-pull back and forth?

[anatoly techtonik]

There are plenty of binding generators exist. I am sure it is possible to take one (like shiboken) and tune to generate ctypes binding semi-automatically. In ideal case you won't have to port manually anything else.

-- 
anatoly t. 

[Tristam MacDonald]

On Sat, Nov 26, 2011 at 5:50 AM, anatoly techtonik <tech...@gmail.com> wrote:

There are plenty of binding generators exist. I am sure it is possible to take one (like shiboken) and tune to generate ctypes binding semi-automatically. In ideal case you won't have to port manually anything else.

I don't really see what a bindings generator would gain us, given that the ctypes port already is a feature-complete port of the PyObjC implementation - i.e. it does everything the PyObjC implementation does, minus a few bug fixes.

[anatoly techtonik]

On Sat, Nov 26, 2011 at 3:39 PM, Tristam MacDonald <swift...@gmail.com> wrote:

On Sat, Nov 26, 2011 at 5:50 AM, anatoly techtonik <tech...@gmail.com> wrote:

There are plenty of binding generators exist. I am sure it is possible to take one (like shiboken) and tune to generate ctypes binding semi-automatically. In ideal case you won't have to port manually anything else.

I don't really see what a bindings generator would gain us, given that the ctypes port already is a feature-complete port of the PyObjC implementation - i.e. it does everything the PyObjC implementation does, minus a few bug fixes.

I believe generators are invented to ease maintenance of bindings and API reference, but if you say that majority of work is already done, then it is not actual of course.
-- 
anatoly t. 

[Steve]

> Philip: I'm going to have some free time coming up, and I want to get the
> ctypes implementation up and running (particularly on pypy). I'm not that
> familiar with distributed development using mercurial - does it make more
> sense for you to grant me write access on the ctypes repository, or for me
> to clone it and us to push-pull back and forth?

You generally clone, work in a feature branch while periodically
merging other changes, and have him Pull when you have something
stable.

[Phillip Nguyen]

On Nov 25, 4:09 pm, Tristam MacDonald <swiftco...@gmail.com> wrote:
> Philip: I'm going to have some free time coming up, and I want to get the
> ctypes implementation up and running (particularly on pypy). I'm not that
> familiar with distributed development using mercurial - does it make more
> sense for you to grant me write access on the ctypes repository, or for me
> to clone it and us to push-pull back and forth?
>

I had looked into giving you commit access to the ctypes clone earlier
and it seems that it's not possible to have more than one committer on
a cloned repository. So I guess push-pull for now? I created a new
clone with the updated ctypes-based cocoa interface:

http://code.google.com/r/evilphillip-cocoa-ctypes2/

which you can make your own clone from, and I've added you as a
committer to the cocoapy project:

http://code.google.com/p/cocoa-python/

the code of which is included inside the pyglet/libs/darwin directory
of the clone.

--phillip