> 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
...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.
> 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
> On Oct 25, 2012, at 2:47 PM, Steve Willis wrote:
> > 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...@googlegroups.com<javascript:>.
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
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.
On Thursday, November 1, 2012 12:29:56 AM UTC-7, George Wright 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? > 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
> On Tuesday, 23 October 2012 02:53:10 UTC+11, Nathan wrote:
>> Just for the benefit of users finding this thread through Google, pyglet >> now works on system python under Mountain Lion.
On Thu, Nov 1, 2012 at 1:29 AM, George Wright <georg...@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.
On Thu, Nov 1, 2012 at 10:16 AM, Steve Willis <steve.wil...@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:
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:
> On Thu, Nov 1, 2012 at 10:16 AM, Steve Willis <steve.wil...@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:
> --
> 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 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.dorm...@gmail.com> wrote:
> 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:
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.l...@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.
> 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?
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?
On Thursday, November 1, 2012 1:04:15 PM UTC-7, Nathan wrote:
> On Thu, Nov 1, 2012 at 10:16 AM, Steve Willis <steve....@gmail.com<javascript:> > > 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:
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.
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
> On Thursday, November 1, 2012 1:04:15 PM UTC-7, Nathan wrote:
>> 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:
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/cty pes/__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-users@googlegroups.com [pyglet-users@googlegroups.com] On Behalf Of Steve Willis [steve.wil...@gmail.com]
Sent: Thursday, December 06, 2012 3:54 PM
To: pyglet-users@googlegroups.com
Subject: Re: pyglet on Mac OS Mountain Lion?
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
On Thursday, November 1, 2012 1:04:15 PM UTC-7, Nathan wrote:
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:
--
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.
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 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:
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.
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.
On Friday, December 7, 2012 10:58:41 AM UTC-7, Nathan wrote:
> On Thu, Dec 6, 2012 at 4:39 PM, pepijn <pep...@boltcreative.com<javascript:> > > 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:
On Fri, Dec 7, 2012 at 11:28 AM, Steve Willis <steve.wil...@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?
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.
On Friday, December 7, 2012 11:49:39 AM UTC-7, Nathan wrote:
> On Fri, Dec 7, 2012 at 11:28 AM, Steve Willis <steve....@gmail.com<javascript:> > > 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?
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
On Dec 7, 2012, at 1:20 PM, Steve Willis <steve.wil...@gmail.com> wrote:
> 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
> On Friday, December 7, 2012 11:49:39 AM UTC-7, Nathan wrote:
> 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
> -- > 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.
> 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.
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.savedSta te
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/__i nit__.py", line 443, in LoadLibrary
return self._dlltype(name)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__i nit__.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/__i nit__.py", line 443, in LoadLibrary
return self._dlltype(name)
File "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__i nit__.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-users@googlegroups.com [pyglet-users@googlegroups.com] On Behalf Of Nathan [nathan.sto...@gmail.com]
Sent: Friday, December 07, 2012 9:58 AM
To: pyglet-users@googlegroups.com
Subject: Re: pyglet on Mac OS Mountain Lion?
On Thu, Dec 6, 2012 at 4:39 PM, pepijn <pep...@boltcreative.com<mailto: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:
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.
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
--
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 Friday, December 7, 2012 2:54:42 PM UTC-8, pepijn wrote:
> 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.savedSta te
> 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/__i nit__.py", > line 443, in LoadLibrary > return self._dlltype(name) > File > "/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/__i nit__.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
> 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.
On Friday, December 7, 2012 10:26:24 PM UTC-8, Nathan wrote:
> Awesome! Thanks for fixing that, Phillip.
> ~ Nathan
> On Fri, Dec 7, 2012 at 1:50 PM, Phillip Nguyen <evil.p...@gmail.com<javascript:> > > wrote:
>> 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.
> 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
> On Friday, December 7, 2012 10:26:24 PM UTC-8, Nathan wrote:
>> Awesome! Thanks for fixing that, Phillip.
>> ~ Nathan
>> On Fri, Dec 7, 2012 at 1:50 PM, Phillip Nguyen <evil.p...@gmail.com>wrote:
>>> 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 unsubscribe from this group and stop receiving emails from it, send an
> email to pyglet-users+unsubscribe@googlegroups.com.
