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?
On Sat, Jul 28, 2012 at 11:30 AM, Adam Kidder <thekid...@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/DVCPROHDAud io:
dlopen(/Library/Audio/Plug-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCP ROHDAudio,
262): no suitable image found. Did find:
/Library/Audio/Plug-Ins/HAL/DVCPROHDAudio.plugin/Contents/MacOS/DVCPROHDAud io:
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...
> 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?
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.
> 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.
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-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/pyglet/libs/darwin/__init__.py", line 6, in <module> from .cocoapy import * File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/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
On Wednesday, September 5, 2012 12:13:03 AM UTC-4, Nathan wrote:
> 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.
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
On Sep 14, 2012, at 12:55 PM, Noyan Tokgozoglu <cladinapa...@gmail.com> wrote:
> 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-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/pyglet/libs/darwin/__init__.py", line 6, in <module>
> from .cocoapy import *
> File "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/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
> On Wednesday, September 5, 2012 12:13:03 AM UTC-4, Nathan wrote:
> 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
> -- > 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-users@googlegroups.com.
> To unsubscribe from this group, send email to pyglet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
On Fri, Sep 14, 2012 at 2:28 PM, Phillip Nguyen <evil.phil...@gmail.com> wrote:
> 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
> On Sep 14, 2012, at 12:55 PM, Noyan Tokgozoglu <cladinapa...@gmail.com>
> wrote:
> 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-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/pyglet/libs/darwin/__init__.py",
> line 6, in <module>
> from .cocoapy import *
> File
> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/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
> On Wednesday, September 5, 2012 12:13:03 AM UTC-4, Nathan wrote:
>>> 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
> --
> 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-users@googlegroups.com.
> To unsubscribe from this group, send email to
> pyglet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pyglet-users?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "pyglet-users" group.
> To post to this group, send email to pyglet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> pyglet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pyglet-users?hl=en.
> 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
> On Fri, Sep 14, 2012 at 2:28 PM, Phillip Nguyen <evil.phil...@gmail.com> wrote:
>> 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
>> On Sep 14, 2012, at 12:55 PM, Noyan Tokgozoglu <cladinapa...@gmail.com>
>> wrote:
>> 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-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/pyglet/libs/darwin/__init__.py",
>> line 6, in <module>
>> from .cocoapy import *
>> File
>> "/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/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-packa ges/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
>> On Wednesday, September 5, 2012 12:13:03 AM UTC-4, Nathan wrote:
>>>> 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
>> --
>> 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-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> pyglet-users+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/pyglet-users?hl=en.
>> --
>> You received this message because you are subscribed to the Google Groups
>> "pyglet-users" group.
>> To post to this group, send email to pyglet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> pyglet-users+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/pyglet-users?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "pyglet-users" group.
> To post to this group, send email to pyglet-users@googlegroups.com.
> To unsubscribe from this group, send email to pyglet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
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.
On Sat, Sep 15, 2012 at 4:09 PM, Phillip Nguyen <evil.phil...@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.
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-packag es/pyglet/text/formats/html.py
to html.cpython-33.pyc
File
"/Library/Frameworks/Python.framework/Versions/3.3/lib/python3.3/site-packa ges/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-packag es/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?
On Sat, Sep 15, 2012 at 5:13 PM, Nathan <nathan.sto...@gmail.com> wrote:
> On Sat, Sep 15, 2012 at 4:09 PM, Phillip Nguyen <evil.phil...@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.
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ó:
ricardpe...@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.
> To post to this group, send email to pyglet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> pyglet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pyglet-users?hl=en.
> 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
> <ricardpe...@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.
>> To post to this group, send email to pyglet-users@googlegroups.com.
>> To unsubscribe from this group, send email to
>> pyglet-users+unsubscribe@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/pyglet-users?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "pyglet-users" group.
> To post to this group, send email to pyglet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> pyglet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pyglet-users?hl=en.
On Mon, Oct 8, 2012 at 5:39 PM, Richard Jones <r1chardj0...@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?
On 9 October 2012 11:20, Nathan <nathan.sto...@gmail.com> wrote:
> On Mon, Oct 8, 2012 at 5:39 PM, Richard Jones <r1chardj0...@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.)
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?
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:
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:
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?
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
> On Monday, October 22, 2012 8:53:10 AM UTC-7, Nathan wrote:
>> Just for the benefit of users finding this thread through Google, pyglet >> now works on system python under Mountain Lion.
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.)
> 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:
> 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
> On Monday, October 22, 2012 8:53:10 AM UTC-7, Nathan wrote:
> Just for the benefit of users finding this thread through Google, pyglet now works on system python under Mountain Lion.
> ~ 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/-/T--DZ1GbnlYJ.
> To post to this group, send email to pyglet-users@googlegroups.com.
> To unsubscribe from this group, send email to pyglet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
