Re: pyglet on Mac OS Mountain Lion?

[Nathan]

On Sat, Jul 28, 2012 at 11:30 AM, Adam Kidder <thek...@gmail.com> wrote:
> I've been using pyglet on Mac OS 10.7 successfully for a while by installing
> from hg. Recently, I installed Mountain Lion, and pyglet is completely
> broken. Creating a window results in absolutely nothing showing up on the
> screen. There is the familiar python rocket ship in the dock, but no windows
> actually appear.
>
> Are there any known bugs with pyglet in 10.8? Or any workarounds/debugging I
> could try to diagnose this?

There's definitely Mountain Lion issues that need to be addressed. I
updated one of my systems and tried out my bubbles sample program (see
https://github.com/peaceful/bubbles ) and immediately hit two
problems:

1) A sound _plays_ and the audio libraries fail to load and everything
seems to hang (I never see a window, but I do hear the startup "puff"
sound).

2012-07-30 10:12:18.177 Python[1265:1307] Error loading
/Library/Audio/Plug-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio:
dlopen(/Library/Audio/Plug-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio,
262): no suitable image found. Did find:
/Library/Audio/Plug-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAudio:
no matching architecture in universal wrapper
2012-07-30 10:12:18.178 Python[1265:1307] Cannot find function pointer
NewPlugIn for factory C5A4CE5B-0BB8-11D8-9D75-0003939615B6 in
CFBundle/CFPlugIn 0x7fab0a541600
</Library/Audio/Plug-Ins/HAL/DVCPROHDAudio.plugin> (bundle, not
loaded)

^CTraceback (most recent call last):
File "./bubbles.py", line 159, in <module>
pyglet.app.run()
File "/Library/Python/2.7/site-packages/pyglet/app/__init__.py",
line 123, in run
event_loop.run()
File "/Library/Python/2.7/site-packages/pyglet/app/base.py", line 135, in run
self._run_estimated()
File "/Library/Python/2.7/site-packages/pyglet/app/base.py", line
174, in _run_estimated
if not platform_event_loop.step(estimate) and estimate != 0.0 and \
File "/Library/Python/2.7/site-packages/pyglet/app/cocoa.py", line
118, in step
NSAnyEventMask, timeout_date, NSDefaultRunLoopMode, True)
File "/Library/Python/2.7/site-packages/pyglet/libs/darwin/cocoapy/runtime.py",
line 770, in __call__
return self.method(self.objc_id, *args)
File "/Library/Python/2.7/site-packages/pyglet/libs/darwin/cocoapy/runtime.py",
line 740, in __call__
result = f(objc_id, self.selector, *args)
KeyboardInterrupt


2) If I comment out the audio calls from bubbles.py, things just seem
to hang without a window ever showing up.


An interesting thing to note: On another prototype I have that
manually pumps the event loop, a window will show up...

[Tristam MacDonald]

On Mon, Jul 30, 2012 at 12:20 PM, Nathan <nathan...@gmail.com> wrote:

An interesting thing to note:  On another prototype I have that
manually pumps the event loop, a window will show up...

The fact that our Cocoa event loop ever worked at all strikes me as a bit of a miracle. It was always a mashup of invisible/private APIs.

I'll see if I can do some triage on it this week.

--

Tristam MacDonald

http://swiftcoder.wordpress.com/

[Nathan]

On Mon, Jul 30, 2012 at 10:57 AM, Tristam MacDonald
<swift...@gmail.com> wrote:
> On Mon, Jul 30, 2012 at 12:20 PM, Nathan <nathan...@gmail.com> wrote:
>>
>>
>> An interesting thing to note: On another prototype I have that
>> manually pumps the event loop, a window will show up...
>
>
> The fact that our Cocoa event loop ever worked at all strikes me as a bit of
> a miracle. It was always a mashup of invisible/private APIs.
>
> I'll see if I can do some triage on it this week.

Thanks, Tristam. :-)

~ Nathan

[oscar]

The fact that our Cocoa event loop ever worked at all strikes me as a bit of a miracle. It was always a mashup of invisible/private APIs.

I'm playing with the idea of making a simple (free) game with pyglet, and trying to put it on the Mac App Store. Is something like these "invisible/private APIs" going to be a problem? I guess, since 1.2 is in beta, that no one has a pyglet app on the Mac App Store yet? 

[Nathan]

On Saturday, August 4, 2012 1:30:46 PM UTC-6, oscar wrote:

The fact that our Cocoa event loop ever worked at all strikes me as a bit of a miracle. It was always a mashup of invisible/private APIs.

I'm playing with the idea of making a simple (free) game with pyglet, and trying to put it on the Mac App Store. Is something like these "invisible/private APIs" going to be a problem? I guess, since 1.2 is in beta, that no one has a pyglet app on the Mac App Store yet? 

I've never heard of anyone getting a pyglet app in the App Store yet -- doesn't mean it hasn't happened.

~ Nathan 

[Nathan]

On Mon, Jul 30, 2012 at 10:57 AM, Tristam MacDonald

> The fact that our Cocoa event loop ever worked at all strikes me as a bit of
> a miracle. It was always a mashup of invisible/private APIs.
>
> I'll see if I can do some triage on it this week.

 

Okay, I just upgraded to Mountain Lion on my main machine today and discovered that this still apparently hasn't been addressed.  :-(

How can I help?  I know next to nothing about Cocoa, other than basic syntax and having run through a couple tutorials, but if there's anything I can do to help get pyglet working on Mountain Lion sooner rather than later, please let me know.

I would be happy to help debug or test or research or whatever.

~ Nathan

[Noyan Tokgozoglu]

I would also like to contribute. Using Python 3.2.3 on Mountain Lion with pyglet 1.2alpha1, I get the following error when I try to import gl from pyglet.gl:

Traceback (most recent call last):

  File "main.py", line 3, in <module>

    from pyglet.gl import gl

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/gl/__init__.py", line 220, in <module>

    from .cocoa import CocoaConfig as Config

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/gl/cocoa.py", line 15, in <module>

    from pyglet.canvas.cocoa import CocoaCanvas

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/canvas/__init__.py", line 90, in <module>

    from pyglet.canvas.cocoa import CocoaDisplay as Display

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/canvas/cocoa.py", line 15, in <module>

    from pyglet.libs.darwin.cocoapy import *

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/libs/darwin/__init__.py", line 6, in <module>

    from .cocoapy import *

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/libs/darwin/cocoapy/__init__.py", line 32, in <module>

    from .runtime import objc, send_message, send_super

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/libs/darwin/cocoapy/runtime.py", line 1149, in <module>

    class DeallocationObserver_Implementation(object):

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/libs/darwin/cocoapy/runtime.py", line 1150, in DeallocationObserver_Implementation

    DeallocationObserver = ObjCSubclass('NSObject', 'DeallocationObserver', register=False)

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/libs/darwin/cocoapy/runtime.py", line 1050, in __init__

    self.objc_cls = create_subclass(superclass, name)

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/libs/darwin/cocoapy/runtime.py", line 603, in create_subclass

    superclass = get_class(superclass)

  File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages/pyglet/libs/darwin/cocoapy/runtime.py", line 402, in get_class

    return c_void_p(objc.objc_getClass(name))

ctypes.ArgumentError: argument 1: <class 'TypeError'>: wrong type

[Phillip Nguyen]

In the line

return c_void_p(objc.objc_getClass(name))

objc_getClass is expecting that name is a string that ctypes can convert to a char *.  However in Python 3, all strings are unicode so name needs to be converted to a different format before ctypes can use it.  Something like name.encode('ascii') would work.

I've not done any testing with Python 3 so I imagine that the cocoa backend has other issues with Python 3 besides just this.

--phillip

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.
To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/qGl1lOxmZ0gJ.
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.

[Haluk Noyan Tokgozoglu]

But the same code works on Windows, so I assume this is a Mac issue
and not a Py3k issue.

Haluk Noyan Tokgozoglu

Johns Hopkins University
Computer Science PhD Candidate
Computational Interaction and Robotics Laboratory
Secretary of the GRO
Treasurer of UPE

[Phillip Nguyen]

It is a Mac issue in that the cocoa backend for pyglet is not currently Python 3 compatible. The code we're talking about isn't run on Windows.

--phillip

[Phillip Nguyen]

I've committed some code changes to make pyglet's cocoa backend compatible with Python 3.2. Mostly a lot of unicode vs bytes issues that needed to be fixed when interfacing the objc runtime via ctypes. Pyglet still needs to be converted with 2to3 before use. I've tested it on Mac OS 10.6 with Python 3.2.3 and it seems to work.

If you're running on Mac OS 10.8, well … now you can experience the same non-existent window bugs in both Python 2.7 and Python 3.

--phillip

[Nathan]

On Sat, Sep 15, 2012 at 4:09 PM, Phillip Nguyen <evil.p...@gmail.com> wrote:

I've committed some code changes to make pyglet's cocoa backend compatible with Python 3.2.  Mostly a lot of unicode vs bytes issues that needed to be fixed when interfacing the objc runtime via ctypes.  Pyglet still needs to be converted with 2to3 before use.  I've tested it on Mac OS 10.6 with Python 3.2.3 and it seems to work.

If you're running on Mac OS 10.8, well … now you can experience the same non-existent window bugs in both Python 2.7 and Python 3.

Sweet!  :-/

I'll go see if the non-existent window bugs act the same on Python 3.

~ Nathan 

[Nathan]

1) I'm actually using Python 3.3.0rc1 at the moment.

2) The "PY3K" file says that 2to3 is supposed to be run automatically when you run "python setup.py install" -- but it doesn't.  Not to worry, "2to3 -w pyglet" did the trick.

3) One error was output during "sudo python3 setup.py install":

[snip]

byte-compiling /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyglet/text/formats/html.py to html.cpython-33.pyc

  File "/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyglet/text/formats/html.py", line 54

    from . import html.parser

                      ^

SyntaxError: invalid syntax

byte-compiling /Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packages/pyglet/text/formats/structured.py to structured.cpython-33.pyc

[snip]

4) The buggy non-visible-window behavior is _exactly_ the same as far as I can tell.  Where's a Cocoa expert when you need one?

~ Nathan

[Nathan]

...and the pythonbrew version of python 2.7 runs pyglet fine with the patches you made.

~ Nathan

[Nathan]

I'm not sure about 1.1.4, but 1.2dev works with Mountain Lion under python installed by pythonbrew.

~ Nathan

On Sat, Oct 6, 2012 at 4:11 AM, Ricard Pérez del Campo <ricar...@gmail.com> wrote:

Hi! I have just started with python and I wanted to do some stuff with Cocos2D, which runs under pyglet, so first I wanted to check out this library.

I installed it version 1.1.4 using python 2.7.2, and could run a simple "Hello World" on OSX Mountain Lion, but JUST FOR ONCE! When I tried to run it again, it didn't crash but the window didn't appear and now it always fails... So after googling it a lot, this is the most similar post I have found, but I can't see (or understand?) any solution here... So please, how did you solve it?

Thanks you.

El domingo, 16 de septiembre de 2012 01:41:13 UTC+2, Nathan escribió:

...and the pythonbrew version of python 2.7 runs pyglet fine with the patches you made.

~ Nathan

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/YnekUsjT7pQJ.

[Richard Jones]

There's a lot to be said for ignoring the OS X system Python and using
brew python in general on Mountain Lion (and Lion for that matter.)


Richard

[Nathan]

On Mon, Oct 8, 2012 at 5:39 PM, Richard Jones <r1char...@gmail.com> wrote:

There's a lot to be said for ignoring the OS X system Python and using
brew python in general on Mountain Lion (and Lion for that matter.)


    Richard

Really?  Since I've been using python on OS X (2003) I've never had any issues with system python, except with regards to 1) pyglet (doesn't work with system python for some weird reason at the moment), and 2) py2app (won't gather the system python).  What other problems have you seen?

~ Nathan 

[Richard Jones]

On 9 October 2012 11:20, Nathan <nathan...@gmail.com> wrote:
> On Mon, Oct 8, 2012 at 5:39 PM, Richard Jones <r1char...@gmail.com>
> wrote:
>>
>> There's a lot to be said for ignoring the OS X system Python and using
>> brew python in general on Mountain Lion (and Lion for that matter.)
>

> Really? Since I've been using python on OS X (2003) I've never had any
> issues with system python, except with regards to 1) pyglet (doesn't work
> with system python for some weird reason at the moment), and 2) py2app
> (won't gather the system python). What other problems have you seen?

Oh, I've been a happy user for about the same amount of time. However:

- Snow Leopard broke building things thanks to the broken 32/64 bit build config
- Lion (and ML) mostly fixed that but causes other problems regarding
easy_install and virtualenvs and an inability to install distribute
over setuptools

It's often still necessary to lipo the system python in virtualenvs to
remove the x86_64 binary to make some 32-bit software happy (even with
"arch" and the VERSIONER env var.)


Richard

[Nathan]

Just for the benefit of users finding this thread through Google, pyglet now works on system python under Mountain Lion.

~ Nathan

[Steve Willis]

My apologies. Between posting the message below and being approved for the group (thanks!), I realized Nathan was referring to the revision control version, and not the release version.

That said, I attempted to get the latest version by doing the following:

hg clone https://code.google.com/p/pyglet/

This version exhibits the problem others were having with this on Mountain Lion before...it runs without error, but no window is visible. Based on the date stamps for the Mercurial download, I think I've still got a version that predates the one Nathan committed recently. This is my first adventure with Mercurial, and I'm sure I'm doing something silly. Any tips on getting a version of the code with the Mountain Lion fix to try out?

Thanks,

Steve

On Thursday, October 25, 2012 9:37:06 AM UTC-7, Steve Willis wrote:

This does not seem to be working for me on system python under Mountain Lion, though this is my first attempt at using pyglet and I might be overlooking something. When I try to run the "Hello, World" example (http://www.pyglet.org/doc/programming_guide/hello_world.html), it fails with the following error:

OSError: dlopen(/System/Library/Frameworks/QuickTime.framework/QuickTime, 6): no suitable image found.  Did find:
/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture
/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture

Any advice would be appreciated.

Steve

[Winston Wolff]

Hi Steve-

Try:
hg clone --update https://code.google.com/p/pyglet/

Unlike git, mercurial separates the cloning process (moving data from remote repository to local repository) and the update process (update your working directory with latest files from local repo.)

-Winston

> --
> You received this message because you are subscribed to the Google Groups "pyglet-users" group.

> To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/T--DZ1GbnlYJ.

[Steve Willis]

Thanks for your help. --update does not appear to be a legal option:

hg clone: invalid arguments
hg clone [OPTION]... SOURCE [DEST]
make a copy of an existing repository
options:
 -U --noupdate          the clone will include an empty working copy (only a
                        repository)
 -u --updaterev REV     revision, tag or branch to check out
 -r --rev REV [+]       include the specified changeset
 -b --branch BRANCH [+] clone only the specified branch
    --pull              use pull protocol to copy metadata
    --uncompressed      use uncompressed transfer (fast over LAN)
 -e --ssh CMD           specify ssh command to use
    --remotecmd CMD     specify hg command to run on the remote side
    --insecure          do not verify server certificate (ignoring web.cacerts
                        config)
[+] marked option can be specified multiple times
use "hg help clone" to show the full help text

When I simply issue

hg clone --update https://code.google.com/p/pyglet/ 

...does it not fetch the latest and greatest? Keep in mind that I did not have a copy of pyglet at all prior to issuing this command, and it certainly did fetch some version.

Also, just a sanity check, am I correct that someone recently committed a change that should be downloadable? I'm referring to this post from the 15th, https://groups.google.com/forum/?fromgroups=#!topic/pyglet-users/JSxcQk_NEDo, but when I view the changes listed here, http://code.google.com/p/pyglet/source/list, I don't see any updates since September.

I appreciate your patience.

Steve

[George Wright]

I have a brand new MacBook Pro with 10.8.2 System python as it cones from the shop - off the shelf.

I've been waiting for an announcement like this from Nathan before installing pyglet. On my older 10.6 machine pyglet stopped working after years of being fine and I couldn't get it going again.

Can I be confident if I install from the pyglet.org site the  pyglet-1.1.4.dmg off the shelf - then it will work without problems?

I would prefer not to have to install another version of python.

I would prefer to wait until problems are sorted than just trying it and getting into a mess like I did before.

I'm not very good at fixing things when broken....

I see later posts since Nathan's below reporting problems.

Am I expecting too much?

Regards

George Wright

[Steve Willis]

I would suggest downloading and trying it. That said, as I posted before, it does not seem to be working for me. There was mention of committing a fix for OSX Mountain Lion in earlier discussions. I have not been able to determine if that fix made it to the Mercurial repository. If it did, either I am not savvy enough to clone the correct revision (completely plausible), or the committed fix doesn't work on my system. I feel somewhat confident in conveying the current (as of last week) .dmg release does not work on OSX 10.8, which isn't a surprise from the comments about it in the mailing list.

I have never run pyglet before, so take my own (in)experience with a grain of salt. My system Python is:

Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]

I have had non-Apple Python installations on this system and upgraded the operating system many times since mid-2007, so I can't speak to how pyglet would perform on an "off the shelf" machine.

If you try it out, please reply with your experience.

Best regards,

Steve

[Nathan]

On Thu, Nov 1, 2012 at 1:29 AM, George Wright <geor...@bigpond.net.au> wrote:

I have a brand new MacBook Pro with 10.8.2 System python as it cones from the shop - off the shelf.

I've been waiting for an announcement like this from Nathan before installing pyglet. On my older 10.6 machine pyglet stopped working after years of being fine and I couldn't get it going again.

Can I be confident if I install from the pyglet.org site the  pyglet-1.1.4.dmg off the shelf - then it will work without problems?

No, not 1.1.4.  Yes, the latest version of 1.2dev from the repository works for me on 10.8.2 system python.

The next alpha/beta release of 1.2x ought to work for 10.8.2 off-the-shelf.

When's the next packaged release, guys?

~ Nathan

[Nathan]

On Thu, Nov 1, 2012 at 10:16 AM, Steve Willis <steve....@gmail.com> wrote:

I would suggest downloading and trying it. That said, as I posted before, it does not seem to be working for me. There was mention of committing a fix for OSX Mountain Lion in earlier discussions. I have not been able to determine if that fix made it to the Mercurial repository. If it did, either I am not savvy enough to clone the correct revision (completely plausible), or the committed fix doesn't work on my system. I feel somewhat confident in conveying the current (as of last week) 

[snip]

Steve

 The following commands run in the terminal ought to get you the latest pyglet 1.2dev:

(First install mercurial from http://mercurial.selenic.com/ )

hg clone https://pyglet.googlecode.com/hg/ pyglet

cd pyglet

hg pull

hg update

sudo python setup.py install

~ Nathan

[Olivier Dormond]

Hi all,

I've been bitten by that annoying "no window" bug and despite the previous
indication that this should be fixed now I've not managed to get it solved.
Nathan last post pushed me to try again and it didn't work once more. However,
I've taken more time to investigate and have finally fixed it ! \o/

So for anybody out there still desperately trying to get that fixed,
here is what
I did in addition to Nathan's instruction to get the latest release:

rm -fr ~/Library/Saved\ Application\ State/org.python.*

That's it.

There is actually two savedState that were removed by that operation:
- org.python.PythonLauncher.savedState
- org.python.python.savedState

I don't know if the removal of both is mandatory to fix the problem
but it worked
and they did not reappear for now.

Cheers,

Odie


2012/11/1 Nathan <nathan...@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups
> "pyglet-users" group.

[Nathan]

Interesting.  I've never even heard of those files!

~ Nathan

[Stonewall Ballard]

I found that I had to delete org.python.python.savedState each time before running the tests in order to get the windows to show up. This explains why it ran correctly only the first time I installed pyglet.

If I delete the saved state, then run the "window" test by itself, it works and does not generate new saved state. "window" will run repeatedly. If I run the "app" test by itself first, it generates the saved state, and prevents the "window" test from running subsequently, until the saved state is deleted.

In particular, it's the file "data.data" within the saved state that's causing the problem. If I remove only that file, the window test works.

The tests "app", "font", "text", and "image" all generate the "data.data" file. The others do not.

I don't know why this is happening, but I hope that this info will clarify things.

I'm running 10.8.2 with the stock python on a Macbook Pro Retina.

- Stoney

On Nov 1, 2012, at 5:25 PM, Olivier Dormond <olivier...@gmail.com> wrote:

> Hi all,
>
> I've been bitten by that annoying "no window" bug and despite the previous
> indication that this should be fixed now I've not managed to get it solved.
> Nathan last post pushed me to try again and it didn't work once more. However,
> I've taken more time to investigate and have finally fixed it ! \o/
>
> So for anybody out there still desperately trying to get that fixed,
> here is what
> I did in addition to Nathan's instruction to get the latest release:
>
> rm -fr ~/Library/Saved\ Application\ State/org.python.*
>
> That's it.
>
> There is actually two savedState that were removed by that operation:
> - org.python.PythonLauncher.savedState
> - org.python.python.savedState
>
> I don't know if the removal of both is mandatory to fix the problem
> but it worked
> and they did not reappear for now.
>
> Cheers,
>
> Odie
>

--
Stonewall Ballard
sto...@sb.org http://stoney.sb.org/

[Stonewall Ballard]

I found a simple work-around for this. Empty the org.python.python.savedState folder, get info on it, then turn on the lock flag. The Python app will no longer be able to save state.

- Stoney

On Nov 2, 2012, at 5:52 PM, Stonewall Ballard <sb....@sb.org> wrote:

> I found that I had to delete org.python.python.savedState each time before running the tests in order to get the windows to show up. This explains why it ran correctly only the first time I installed pyglet.
>
> If I delete the saved state, then run the "window" test by itself, it works and does not generate new saved state. "window" will run repeatedly. If I run the "app" test by itself first, it generates the saved state, and prevents the "window" test from running subsequently, until the saved state is deleted.
>
> In particular, it's the file "data.data" within the saved state that's causing the problem. If I remove only that file, the window test works.
>
> The tests "app", "font", "text", and "image" all generate the "data.data" file. The others do not.
>
> I don't know why this is happening, but I hope that this info will clarify things.
>
> I'm running 10.8.2 with the stock python on a Macbook Pro Retina.
>
> - Stoney

[Adam Schackart]

perhaps i should have compiled some dylibs and played around with them before making such a glib assumption

i am eating my words here, and they are delicious

On Thursday, October 11, 2012 8:04:53 AM UTC-7, Adam Schackart wrote:

http://bugs.python.org/issue13370

as i told richard on twitter, this is most likely due to a difference between the gcc and clang calling convention

unfortunately, the default osx python interpreter does not yet contain this patch afaik

On Saturday, July 28, 2012 10:30:10 AM UTC-7, Adam Kidder wrote:

I've been using pyglet on Mac OS 10.7 successfully for a while by installing from hg. Recently, I installed Mountain Lion, and pyglet is completely broken. Creating a window results in absolutely nothing showing up on the screen. There is the familiar python rocket ship in the dock, but no windows actually appear.

Are there any known bugs with pyglet in 10.8? Or any workarounds/debugging I could try to diagnose this?

[Steve Willis]

Pepjin,

I don't believe I had any "quick time" issues. Stonewall Ballard's replies above worked for the issue I did have, though this limits my ability to deploy a production Pyglet application with other Mac users. The issue appears to have something to do with OSX saving the state for windows automatically, which then allows the operating system to restore the window's geometry and last opened documents the next time a particular application is launched. This behavior isn't specific to Python...if you browse your "~/Library/Saved Application State" directory, you will see many such entries for a variety of applications. In this case, the offending one that must be deleted is org.python.python.savedState. However, as Stonewall Ballard noted above, you must actually lock this file somehow to prevent it from being recreated each time Pyglet runs.

Thanks to all who helped me with this issue. I am now running a pure-Python OpenGL application, and am very impressed with Pyglet. I don't have any additional information on this issue, but would be happy to lend my time and Macs to tracking down the cause.

Best regards,

Steve

On Thursday, December 6, 2012 4:39:28 PM UTC-7, pepijn wrote:

Hey Nathan/all,

Thanks for outlining these steps. Unfortunately i'm still getting the same quick time errors as Steve Willis above. I had previously installed Pyglet 1.1.4 through pyglet.org... Maybe i should've uninstalled that one before i followed your steps. Not sure how to uninstall though. I looked through their documentation but they only tell you how to install. Anyone any ideas?

Also, can i use the stock python that comes with os x 10.8?

Thanks for all the help here in any case!

Pepijn

[Pepijn Gooiker]

Thanks Steve for clearing that up. I checked the saved state folder in Library but didn't see the state for org.python.python.savedState.

Btw, I was referring to the 'quicktime' output that you pasted above.

When i tried to build my application i receive something very similar:

File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 353, in __init__
self._handle = _dlopen(self._name, mode)

OSError: dlopen(/System/Library/Frameworks/QuickTime.framework/QuickTime, 6): no suitable image found. Did find:
/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture
/System/Library/Frameworks/QuickTime.framework/QuickTime: mach-o, but wrong architecture

Please excuse any 'noob' comments/observations. I'm pretty new to pyglet and it was always running fine on 10.7.

Thanks,
Pepijn



________________________________________
From: pyglet...@googlegroups.com [pyglet...@googlegroups.com] On Behalf Of Steve Willis [steve....@gmail.com]
Sent: Thursday, December 06, 2012 3:54 PM
To: pyglet...@googlegroups.com
Subject: Re: pyglet on Mac OS Mountain Lion?

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/jKhZZizkFNUJ.

[Nathan]

On Thu, Dec 6, 2012 at 4:39 PM, pepijn <pep...@boltcreative.com> wrote:

Hey Nathan/all,

Thanks for outlining these steps. Unfortunately i'm still getting the same quick time errors as Steve Willis above. I had previously installed Pyglet 1.1.4 through pyglet.org... Maybe i should've uninstalled that one before i followed your steps. Not sure how to uninstall though. I looked through their documentation but they only tell you how to install. Anyone any ideas?

Lets check to see if everything got upgraded like you expected.  Try running python, and then running the following commands:

import pyglet

print(pyglet.version)

print(pyglet.media.have_avbin)

print(pyglet.media.avbin.get_version())

For example, on one of my machines it looks like this:

$ python

Python 2.7.2 (default, Jun 20 2012, 16:23:33) 

[GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin

Type "help", "copyright", "credits" or "license" for more information.

>>> import pyglet

>>> print(pyglet.version)

1.2alpha1

>>> print(pyglet.media.have_avbin)

True

>>> print(pyglet.media.avbin.get_version())

11

 

Also, can i use the stock python that comes with os x 10.8?

You can if you install the development version of pyglet from the mercurial repository.

 

Thanks for all the help here in any case!

I hope this helps.  :-)

~ Nathan 

[Steve Willis]

I am using the latest development Pyglet from the mercurial repository on OSX 10.8 without issue, aside from the need to suppress the Application State file as described previously. I haven't run any tests outside of my own project, but it seems to be very stable thus far.

Steve 

[Nathan]

On Fri, Dec 7, 2012 at 11:28 AM, Steve Willis <steve....@gmail.com> wrote:

I am using the latest development Pyglet from the mercurial repository on OSX 10.8 without issue, aside from the need to suppress the Application State file as described previously. I haven't run any tests outside of my own project, but it seems to be very stable thus far.

Steve 

That is so weird that you have to suppress the creation of the "~/Library/Saved Application State/org.python.python.savedState" directory.  That directory exists on all my 10.8 installations, but has never caused a problem.

Does the problem occur even if you do a basic "hello world" pyglet app?

~ Nathan

[Steve Willis]

Yes. In fact, I am very new to Pyglet, and initially encountered this issue when trying the first "Hello, World" example in the Pyglet documentation. The development version runs without error and the Python process is running, but no window appears. After suppressing the creation of the org.python.python.savedState file, everything has gone smoothly.

A little research tells me that this file, and the many others like it, are part of the feature which can be configured with the "Close windows when quitting an application" checkbox found in System Preferences | General. In my case, checking this box did not solve the problem by itself, but the file is related to this feature allowing for OSX to restore the window state and open documents within for compliant applications.

I have also observed that this file is not created immediately in all cases. Before suppressing the creation of the file by locking permissions on the Application State folder (disabling this feature for all other applications as well), I tried manually deleting it while developing a simple test application. In some cases, it was several minutes before the file was created. In some cases I could even launch my application again after its creation, but not consistently. The only method that has proved reliable is to avoid creating the file in the first place.

One final tidbit: I also tried simply checking for the existence of this file and deleting it when found as the first task in my Python script. This did not work. As a result, I suspect that the file is created at the time Pyglet is initialized on import, and not necessarily at the time a window is actually displayed. 

Steve

[Phillip Nguyen]

Wow, thanks!  With this information I found the ApplePersistenceIgnoreState key, and I've committed a fix that should prevent the org.python.python.savedState file from ever being created or used.  This fixes the problem of new windows not being displayed after finishLaunching got called.  It also explains why the problem was only showing up with certain builds of python and not pypy.  There is an Xcode build setting that can be checked to prevent automatic state restoration for the application and I'm guessing the python from python.org doesn't have this set.

When you run a pyglet program from the terminal, there is a warning message saying that it won't be saving or restoring state.  But I think I can live with that.

--phillip

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.

To view this discussion on the web visit https://groups.google.com/d/msg/pyglet-users/-/2jopLtpcMh0J.

[Pepijn Gooiker]

Hey Nathan,

This is the output when i run said commands:

Python 2.7.3 (v2.7.3:70274d53c1dd, Apr 9 2012, 20:52:43)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin

Type "help", "copyright", "credits" or "license" for more information.
>>> import pyglet

>>> print(pyglet.version)
1.2alpha1

>>> print(pyglet.media.have_avbin)

2012-12-07 14:52:34.051 Python[414:f07] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/b6/wjplmbk94bd501nx2n40vzbr0000gn/T/org.python.python.savedState
Unexpected error loading library /usr/local/lib/libavbin.dylib: dlopen(/usr/local/lib/libavbin.dylib, 6): no suitable image found. Did find:
/usr/local/lib/libavbin.dylib: no matching architecture in universal wrapper
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "pyglet/__init__.py", line 338, in __getattr__
__import__(import_name)
File "pyglet/media/__init__.py", line 1469, in <module>
import avbin
File "pyglet/media/avbin.py", line 64, in <module>
darwin='/usr/local/lib/libavbin.dylib')
File "pyglet/lib.py", line 111, in load_library
lib = ctypes.cdll.LoadLibrary(name)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 443, in LoadLibrary
return self._dlltype(name)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 365, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(/usr/local/lib/libavbin.dylib, 6): no suitable image found. Did find:
/usr/local/lib/libavbin.dylib: no matching architecture in universal wrapper

>>> print(pyglet.media.avbin.get_version())
Unexpected error loading library /usr/local/lib/libavbin.dylib: dlopen(/usr/local/lib/libavbin.dylib, 6): no suitable image found. Did find:
/usr/local/lib/libavbin.dylib: no matching architecture in universal wrapper
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "pyglet/__init__.py", line 338, in __getattr__
__import__(import_name)
File "pyglet/media/__init__.py", line 1469, in <module>
import avbin
File "pyglet/media/avbin.py", line 64, in <module>
darwin='/usr/local/lib/libavbin.dylib')
File "pyglet/lib.py", line 111, in load_library
lib = ctypes.cdll.LoadLibrary(name)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 443, in LoadLibrary
return self._dlltype(name)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__init__.py", line 365, in __init__
self._handle = _dlopen(self._name, mode)
OSError: dlopen(/usr/local/lib/libavbin.dylib, 6): no suitable image found. Did find:
/usr/local/lib/libavbin.dylib: no matching architecture in universal wrapper
>>>

Any idea what's happening?

Thanks
Pepijn

________________________________________
From: pyglet...@googlegroups.com [pyglet...@googlegroups.com] On Behalf Of Nathan [nathan...@gmail.com]
Sent: Friday, December 07, 2012 9:58 AM

To: pyglet...@googlegroups.com
Subject: Re: pyglet on Mac OS Mountain Lion?

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.

[Nathan]

Awesome!  Thanks for fixing that, Phillip.

~ Nathan

[Nathan]

Ya, that was fixed.  You have to check out pyglet from the repository using mercurial and install it from there.

~ Nathan

On Thu, May 30, 2013 at 12:02 AM, Andrew Schmidt <scatt...@gmail.com> wrote:

Did we get an actual solution to this? I have this exact problem, running the 1.2alpha1 version.

Everything else about pyglet looks lovely, and I'm eager to get started :D

--
You received this message because you are subscribed to the Google Groups "pyglet-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pyglet-users...@googlegroups.com.

To post to this group, send email to pyglet...@googlegroups.com.

Visit this group at http://groups.google.com/group/pyglet-users?hl=en.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[John Duprey]

I installed through from mercurial using:

pip install hg+https://pyglet.googlecode.com/hg/

I'm using python2.7 via Mac Homebrew.

Now I get these warnings:

2013-09-26 12:35:06.233 Python[69057:1307] ApplePersistenceIgnoreState: Existing state will not be touched. New state will be written to /var/folders/66/8tn_4g0j3tb4s085cfrpt0vm0000gn/T/org.python.python.savedState

Can these be silenced/fixed?

1.2alpha1 has been out for quite a while.. has pyglet development stalled?

Likewise, there are issues with avbin (that pyglet depends on) that seem to be long standing.

["Juan J. Martínez"]

On 26/09/13 17:39, John Duprey wrote:
> [...]
>
> Can these be silenced/fixed?

No idea, Mac platform is not my strong skill.

> 1.2alpha1 has been out for quite a while.. has pyglet development stalled?

Yes, things have been a little bit slow lately.

I'm trying to improve the situation. catching up with the bug reports
first (several include patches) and then fixing some issues with Python
3. After that, alpha2 (or perhaps beta1) will be released and we'll try
to make it easier to install/use.

So I hope I'll be able to make a new release in a couple of months.

Regards,

Juan

--
jjm's home: http://www.usebox.net/jjm/
blackshell: http://blackshell.usebox.net/