On Tue, Sep 11, 2012 at 12:04 AM, Adam Griffiths < [email protected]> wrote:
> Pythonbrew is vanilla Python. I believe I've read elsewhere that Apple's > system python can cause problems in some cases. > > I would recommend always using pythonbrew and virtualenv anyway. > It's not good to pollute your system python, a system update will ruin all > your work, or your work could ruin your system =P. > > Cheers, > Adam > > Ya, I looked at the pythonbrew source code, and it pretty much does the standard compilation steps. The real puzzler, though, is why the binary OS X installer from Python.org exhibits the same behavior as the Apple-supplied python. (???) Is Python.org not providing "vanilla Python"? There may be something going on here... During my ~6-8 hours trying to find the problem, I noticed that the following characteristics: - Pyglet side of the event loop ran fine, including the Cocoa portion that passed through keystrokes - Sounds worked fine, with or without AVbin decompression (both .ogg and .wav files played normally) - Graphics-related calls all _worked_, meaning the call ran and didn't error out (Here's where it gets really interesting) - Cocoa put up the Application Menu once, but it was unclickable (meaning whatever loop processed menu handling didn't seem to be getting pumped) - The window never appeared, even though all the calls to draw to it succeeded. Again suggesting some graphics-related event loop wasn't getting pumped. Things are soooo close to working, it just seems like with the system/Python.org python versions something is subtly different resulting in some windowing subsystem not getting pumped. Could this be an elusive 1-line fix somewhere??? ~ Nathan -- You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en.
