How about a 1.2 release?

[Richard Jones]

Hi all,

I'd like to get the 1.2 release of pyglet out, hopefully coinciding
with a new release of avbin and definitely a companion release to the
latest cocos2d.

To help this, I'd appreciate it if people could volunteer to run the
test suite in the hg default branch on a platform:

- Windows 32-bit*
- Linux 32-bit (and 64-bit?**)
- OS X 32-bit and 64-bit under Lion (I can do so under Snow Leopard)

This will hopefully help us identify problem areas.

* if anyone is willing to put in the effort to introduce 64-bit
Windows support that'd be awesome!
** I honestly can't recall whether 64-bit is supported on Linux

Richard

[Thomas A R Woelz]

I'd love to see pyglet 1.2 to work, and see improvements specially in video decoding and joystick input. I run both Win7 64bit (running Python 32 bit) and Linux 64 bit (Ubuntu: using included Python, not sure if it is 32 or 64 right now). 

Thomas

[Richard Jones]

The 32- or 64-bit'ness refers solely to the Python binary used. So on
Windows you're fine.

On OS X 32-bit mode may be forced (assuming you have a default fat build) using:

export VERSIONER_PYTHON_PREFER_32_BIT=yes
export ARCHFLAGS='-arch i386'

... though in some of my virtualenvs I've gone so far as to "lipo
-thin i386 ..." to force Python to be 32-bit just for that virtualenv.

Not sure how such things are achieved on Linux.

Richard

[Petr Viktorin]

Hello,
Pyglet mostly works on my Linux 64bit box (Kubuntu 11.04; crappy Intel
integrated graphics). I did have some problems though; most
importantly the graphics.RETAINED_INDEXED test segfaulted, so I
commented it out and ran the other tests. Sound didn't work at all.
The Compose key doesn't work in the text tests.

Test log: http://pastebin.com/iseSwY5W

graphics.RETAINED_INDEXED backtrace at http://pastebin.com/3U011N06,
if that helps.

Petr

> --
> 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/-/oT7B3MQN6mkJ.
> 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.
>

[Richard Jones]

On 27 October 2011 16:10, Petr Viktorin <enc...@gmail.com> wrote:
> Pyglet mostly works on my Linux 64bit box (Kubuntu 11.04; crappy Intel
> integrated graphics). I did have some problems though; most
> importantly the graphics.RETAINED_INDEXED test segfaulted, so I
> commented it out and ran the other tests.

Thanks! Sadly "crappy Intel integrated graphics" have been known to
cause us unmeasurable compatibility pain in the past ;-)

Is your Python binary 32- or 64-bit? If 64 then would it be possible
to try a 32-bit build?

> Sound didn't work at all.

What sound system(s) are running? Could you possibly try some variants
by setting the PYGLET_AUDIO environment variable? See "pydoc pyglet"
for how the options work. I believe on Linux we can use pulse and
openal.

> The Compose key doesn't work in the text tests.

> Test log: http://pastebin.com/iseSwY5W

There's quite a few failures in there that look like they wouldn't
take very long for someone on a Linux system to fix. Then there's the
other ones, some of which are probably related to your graphics
hardware.

Richard

[Petr Viktorin]

On Thu, Oct 27, 2011 at 08:26, Richard Jones <r1char...@gmail.com> wrote:
> On 27 October 2011 16:10, Petr Viktorin <enc...@gmail.com> wrote:
>> Pyglet mostly works on my Linux 64bit box (Kubuntu 11.04; crappy Intel
>> integrated graphics). I did have some problems though; most
>> importantly the graphics.RETAINED_INDEXED test segfaulted, so I
>> commented it out and ran the other tests.
>
>
> Thanks! Sadly "crappy Intel integrated graphics" have been known to
> cause us unmeasurable compatibility pain in the past ;-)
>
> Is your Python binary 32- or 64-bit? If 64 then would it be possible
> to try a 32-bit build?

It's 64-bit. For 32-bit.. I'm not sure I believe I'd have to compile
Python, and all libraries it uses, from source. Or just use a 32-bit
system – that would probably be easier.
So it's possible, but is it really what you'll want Pyglet's Linux users to do?

>> Sound didn't work at all.
>
> What sound system(s) are running? Could you possibly try some variants
> by setting the PYGLET_AUDIO environment variable? See "pydoc pyglet"
> for how the options work. I believe on Linux we can use pulse and
> openal.

I'll try when I have time again :)

>> The Compose key doesn't work in the text tests.
>
>
>> Test log: http://pastebin.com/iseSwY5W
>
> There's quite a few failures in there that look like they wouldn't
> take very long for someone on a Linux system to fix. Then there's the
> other ones, some of which are probably related to your graphics
> hardware.

I'll try that when I have yet more time...

>     Richard

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

[Adam Bark]

I'm running 64-bit linux mint 11 and pyglet seems to run without any
problems although I haven't run the test suite yet, I'll do that later
today. Pulse works mostly fine although seems to be the buggiest driver,
I have a fix awaiting review on googlecode if anyone would mind patching
and checking it doesn't break anything on there systems. OpenAL seems to
work well too and probably runs through pulseaudio if you have that too.

Adam.

[Nathan]

I'll run it for OS X Lion tonight (about 8 hours from now).

Does this mean you merged the ctypes changes into the default branch?

~ Nathan

[Richard Jones]

On 28 October 2011 06:45, Nathan <nathan...@gmail.com> wrote:
> I'll run it for OS X Lion tonight (about 8 hours from now).
>
> Does this mean you merged the ctypes changes into the default branch?

Phillip's branch was merged back in March.

Richard

[Richard Jones]

On 27 October 2011 21:34, Adam Bark <adam....@gmail.com> wrote:
> today. Pulse works mostly fine although seems to be the buggiest driver,
> I have a fix awaiting review on googlecode if anyone would mind patching
> and checking it doesn't break anything on there systems.

Which patch in particular is that?

Richard

[Richard Jones]

Oh, I think I found it:

Issue 536: Pitch change functionality with pulseaudio driver.

It seems reasonable so I've applied it.

There's a couple of other Linux-related patches in the tracker - would
you mind having a look at them please?

Richard

[Bruce Smith]

On Thu, Oct 27, 2011 at 12:45 PM, Nathan <nathan...@gmail.com> wrote:

I'll run it for OS X Lion tonight (about 8 hours from now).

Does this mean you merged the ctypes changes into the default branch?

~ Nathan

Are you planning to do 32-bit (Carbon) or 64-bit (Cocoa)?

I have a bugfix for 32-bit which is required if you run it without any version of PyObjC present at all. (Apple's Python has PyObjC preinstalled, but ActivePython doesn't, at least in Lion and Python 2.7.)

I'll commit this later tonight or tomorrow (followed by some other bugfixes I've been procrastinating on committing), but in case you happen to run into that problem sooner, the diff for the fix is:

% hg diff

diff -r ea330ef69fbc pyglet/__init__.py

--- a/pyglet/__init__.py Thu Oct 27 15:26:09 2011 +1100

+++ b/pyglet/__init__.py Thu Oct 27 19:52:24 2011 -0700

@@ -193,10 +193,15 @@

     is_64bits = sys.maxint > 2**32

     import platform

     osx_version = platform.mac_ver()[0]

-    from objc import __version__ as pyobjc_version

     if is_64bits:

         if osx_version < '10.6':

             raise Exception('pyglet is not compatible with 64-bit Python for versions of Mac OS X prior to 10.6.')

+        try:

+            # note: we don't import objc until now, since it's not needed

+            # (and not always present) under 32-bit Python.

+            from objc import __version__ as pyobjc_version

+        except ImportError:

+            raise Exception('pyglet requires PyObjC when run in 64-bit Python; import objc failed')

         if pyobjc_version < '2.2':

             raise Exception('pyglet is not compatible with 64-bit Python for versions of PyObjC prior to 2.2')            

         options['darwin_cocoa'] = True

(If you want to commit this fix yourself, go ahead if that's more convenient.)

As for 64-bit Python, I found no way to run pyglet in it myself, under Lion. The details are complicated. My issue may have been specific to ActivePython and/or Python 2.7, and was certainly specific to Lion. The issue (IIRC) was that I needed PyObjcC 2.3 but that version of ActivePython (2.7.2.5) only has it up to 2.2 for Lion. (As of a month or two ago.)

- Bruce Smith

[Nathan]

On Thu, Oct 27, 2011 at 9:05 PM, Bruce Smith <ore...@gmail.com> wrote:

On Thu, Oct 27, 2011 at 12:45 PM, Nathan <nathan...@gmail.com> wrote:

I'll run it for OS X Lion tonight (about 8 hours from now).

Does this mean you merged the ctypes changes into the default branch?

~ Nathan

Are you planning to do 32-bit (Carbon) or 64-bit (Cocoa)?

64-bit
 

I have a bugfix for 32-bit which is required if you run it without any version of PyObjC present at all. (Apple's Python has PyObjC preinstalled, but ActivePython doesn't, at least in Lion and Python 2.7.)

I'll commit this later tonight or tomorrow (followed by some other bugfixes I've been procrastinating on committing), but in case you happen to run into that problem sooner, the diff for the fix is:

% hg diff

diff -r ea330ef69fbc pyglet/__init__.py

--- a/pyglet/__init__.py Thu Oct 27 15:26:09 2011 +1100

+++ b/pyglet/__init__.py Thu Oct 27 19:52:24 2011 -0700

@@ -193,10 +193,15 @@

     is_64bits = sys.maxint > 2**32

     import platform

     osx_version = platform.mac_ver()[0]

-    from objc import __version__ as pyobjc_version

     if is_64bits:

         if osx_version < '10.6':

             raise Exception('pyglet is not compatible with 64-bit Python for versions of Mac OS X prior to 10.6.')

+        try:

+            # note: we don't import objc until now, since it's not needed

+            # (and not always present) under 32-bit Python.

+            from objc import __version__ as pyobjc_version

+        except ImportError:

+            raise Exception('pyglet requires PyObjC when run in 64-bit Python; import objc failed')

         if pyobjc_version < '2.2':

             raise Exception('pyglet is not compatible with 64-bit Python for versions of PyObjC prior to 2.2')            

         options['darwin_cocoa'] = True

(If you want to commit this fix yourself, go ahead if that's more convenient.)

I won't run into it.  I don't plan to deal with 32-bit at all.
 

As for 64-bit Python, I found no way to run pyglet in it myself, under Lion. The details are complicated. My issue may have been specific to ActivePython and/or Python 2.7, and was certainly specific to Lion. The issue (IIRC) was that I needed PyObjcC 2.3 but that version of ActivePython (2.7.2.5) only has it up to 2.2 for Lion. (As of a month or two ago.)

That's odd.  I'm just using the system python under Lion, and it works.  Albeit not perfectly.

~ Nathan

[Nathan]

(See also pyglet.1.log)

Significant problems.

First, and most annoying, the window would always start hidden.  According to the events, it was always active and shown, but it wasn't.  During the graphics test, the window process was selected, but to get the window to actually appear I had to switch to another application (like Terminal) and then switch back to the python app, and then it displayed.  During the font tests, I could just click on the python app and the window appeared.  NOTE that this problem did NOT occur in the checkouts of Philip's version -- so if his changes were merged, this would seem to be a regression.

Second, during ANY resize event, garbage would be displayed.  In the case of resize-by-mouse garbage would continue to be displayed until the mouse button was released.  Results when resizing was inconsistent.  Sometimes the scene seemed sane after a resize, often it didn't.  Lots of garbage and garbled artifacts.

Third, no sound played during any of the sound tests, and I was oddly never given a chance to indicate that.

Fourth, during the test with the output below, the window never appeared, and there was no way to regain control of the testing process.  So I killed it and decided to send in what I have.

---------
Running Test: text.PLAIN
Test an unformatted document is editable.

Examine and type over the text in the window that appears.  The window
contents can be scrolled with the mouse wheel.

Press ESC to exit the test.
--------

Fifth, there were some other failures, but most of them were related to the above.

Sixth, the log is attached.

Seventh, I'm using my custom-compiled version of avbin, if that makes any difference.

~ Nathan

[Richard Jones]

On 28 October 2011 14:05, Bruce Smith <ore...@gmail.com> wrote:
> I have a bugfix for 32-bit which is required if you run it without any
> version of PyObjC present at all. (Apple's Python has PyObjC
> preinstalled, but ActivePython doesn't, at least in Lion and Python 2.7.)
> I'll commit this later tonight or tomorrow (followed by some other bugfixes
> I've been procrastinating on committing), but in case you happen to run into
> that problem sooner, the diff for the fix is:

[snip]

Thanks, I actually had a local patch for this sitting un-committed.
I've just pushed it :-)

Richard

[Bruce Smith]

On Thu, Oct 27, 2011 at 9:37 PM, Nathan <nathan...@gmail.com> wrote:

On Thu, Oct 27, 2011 at 9:05 PM, Bruce Smith <ore...@gmail.com> wrote:

On Thu, Oct 27, 2011 at 12:45 PM, Nathan <nathan...@gmail.com> wrote:

I'll run it for OS X Lion tonight (about 8 hours from now).

Does this mean you merged the ctypes changes into the default branch?

~ Nathan

Are you planning to do 32-bit (Carbon) or 64-bit (Cocoa)?

64-bit

I'll do 32-bit when I get a chance, which might mean in a few days. (So if anyone else wants to do it, don't hold back.)

 

As for 64-bit Python, I found no way to run pyglet in it myself, under Lion. The details are complicated. My issue may have been specific to ActivePython and/or Python 2.7, and was certainly specific to Lion. The issue (IIRC) was that I needed PyObjcC 2.3 but that version of ActivePython (2.7.2.5) only has it up to 2.2 for Lion. (As of a month or two ago.)

That's odd.  I'm just using the system python under Lion, and it works.  Albeit not perfectly.

~ Nathan

My problem is probably limited to trying to run it under ActivePython (a particular third-party distribution of Python). I had other requirements which forced me there, away from the system python. (I.e. some extension packages I could not get compiled successfully under the system python.)

- Bruce

[Richard Jones]

On 28 October 2011 15:45, Nathan <nathan...@gmail.com> wrote:
> First, and most annoying, the window would always start hidden.  According
> to the events, it was always active and shown, but it wasn't.  During the
> graphics test, the window process was selected, but to get the window to
> actually appear I had to switch to another application (like Terminal) and
> then switch back to the python app, and then it displayed.  During the font
> tests, I could just click on the python app and the window appeared.  NOTE
> that this problem did NOT occur in the checkouts of Philip's version -- so
> if his changes were merged, this would seem to be a regression.

Hmm, that's a question for Philip - he merged the branch:

http://code.google.com/p/pyglet/source/detail?r=caf8b30706b757a4e70809f404408b51ba5b3513

> Second, during ANY resize event, garbage would be displayed.  In the case of
> resize-by-mouse garbage would continue to be displayed until the mouse
> button was released.  Results when resizing was inconsistent.  Sometimes the
> scene seemed sane after a resize, often it didn't.  Lots of garbage and
> garbled artifacts.

I also saw this. I suspect that the older-style test code is to blame.
For example, WINDOW_RESIZABLE has:

self.w = w = window.Window(self.width, self.height, resizable=True)
glClearColor(1, 1, 1, 1)
while not w.has_exit:
w.dispatch_events()
window_util.draw_client_border(w)
w.flip()
w.close()

It looks like the OS X code (cocoa and carbon) is blocking in
w.dispatch_events() while the mouse is held down on the resize handle.
When the mouse is released the window contents are redrawn as
expected.

I'm not sure whether this is reasonable or even controllable. I'd
appreciate it if someone could indicate the behaviour of
WINDOW_RESIZABLE on other platforms.

To account for the blocking and allow redraw while events are being
handled, I modified the code to:

self.w = w = window.Window(self.width, self.height, resizable=True)
def on_draw():
glClearColor(1, 1, 1, 1)
window_util.draw_client_border(w)
w.flip()
w.push_handlers(on_draw)
on_draw()
while not w.has_exit:
w.dispatch_events()
w.close()

all flickering / corruption goes away. I'm just not sure this is appropriate.

Thanks for the log! I'm not sure how much of the objc-based code I'm
going to be able to address, but we'll see :-)

Richard

[Bruce Smith]

On Thu, Oct 27, 2011 at 9:45 PM, Nathan <nathan...@gmail.com> wrote:

.... NOTE that this problem did NOT occur in the checkouts of Philip's version -- so if his changes were merged, this would seem to be a regression. .....

To avoid possible confusion: I think there are two versions of "pyglet under Cocoa" around, one using ctypes and PyObjC, which was integrated into the pyglet trunk in around March, and one using more and messier ctypes but not requiring PyObjC, which works better but has never been integrated into the pyglet googlecode project (it lives in a forked project, not in a branch in the same project). 

(If those who actually know can confirm this and mention these versions' unambiguous names, that would be great. I *think* that second one was from "evil philip" but I'm not sure. I'm not even sure if the two versions were (in their final forms) by different people or the same person.) 

Anyway, which of these are you referring to as "the checkouts of Philip's version" above?

- Bruce

[anatoly techtonik]

In the meanwhile it would be nice to see CHANGELOG updated with changes up to 1.1.4 and above.

[Phillip Nguyen]

Bruce is correct. The cocoa branch that I merged back in March,
currently in the pyglet trunk, is still dependent on PyObjC. The
messy ctypes-only version is a separate clone, available from
http://code.google.com/r/evilphillip-cocoa-ctypes/. I think it's the
ctypes-only clone that Nathan is referring to above. The two
codebases are theoretically equivalent -- they both make the exact
same objective-c function calls. It's just that the version in the
repository is using PyObjC and the clone version is using a ctypes
wrapper around the objc runtime. So I'm surprised that the PyObjC
version from the trunk is showing problems that the ctypes-only
version isn't. Unfortunately, I'm not running Lion to be able to look
into it.

--phillip

[claudio canepa]

On Thu, Oct 27, 2011 at 1:09 AM, Richard Jones <r1char...@gmail.com> wrote:

Hi all,

I'd like to get the 1.2 release of pyglet out, hopefully coinciding
with a new release of avbin and definitely a companion release to the
latest cocos2d.

To help this, I'd appreciate it if people could volunteer to run the
test suite in the hg default branch on a platform:

- Windows 32-bit*
- Linux 32-bit (and 64-bit?**)
- OS X 32-bit and 64-bit under Lion (I can do so under Snow Leopard)

This will hopefully help us identify problem areas.

I spawned a thread called 'tests results win 32bits'

http://groups.google.com/group/pyglet-users/t/b2eb66d665301b12

to facilitate following by OS (hope it it right)

--

claudio 

[Christoph Gohlke]

On Oct 26, 9:09 pm, Richard Jones <r1chardj0...@gmail.com> wrote:
> Hi all,
>
> I'd like to get the 1.2 release of pyglet out, hopefully coinciding
> with a new release of avbin and definitely a companion release to the
> latest cocos2d.
>
> To help this, I'd appreciate it if people could volunteer to run the
> test suite in the hg default branch on a platform:
>
> - Windows 32-bit*
> - Linux 32-bit (and 64-bit?**)
> - OS X 32-bit and 64-bit under Lion (I can do so under Snow Leopard)
>
> This will hopefully help us identify problem areas.
>
> * if anyone is willing to put in the effort to introduce 64-bit
> Windows support that'd be awesome!

I have submitted a patch for win-amd64 earlier this year. See issue
510 <http://code.google.com/p/pyglet/issues/detail?id=510>.

Christoph

[greenmoss]

Is there any chance the ctypes-only clone will be integrated before a
pyglet 1.2 release, or for that matter "any time soon"? FWIW, I tried
the clone, and it was acting a bit "weird" for me.

On Oct 28, 6:08 am, Phillip Nguyen <evil.phil...@gmail.com> wrote:
> Bruce is correct.  The cocoa branch that I merged back in March,
> currently in the pyglet trunk, is still dependent on PyObjC.  The

> messy ctypes-only version is a separate clone, available fromhttp://code.google.com/r/evilphillip-cocoa-ctypes/.  I think it's the

[Bruce Smith]

On Sun, Oct 30, 2011 at 8:25 AM, greenmoss <ktyg...@yoderhome.com> wrote:

Is there any chance the ctypes-only clone will be integrated before a
pyglet 1.2 release, or for that matter "any time soon"? FWIW, I tried
the clone, and it was acting a bit "weird" for me. 

My $0.000002 on that would be that if tests show it clearly works better on at least one configuration we want to support, we should seriously consider integrating it. I have not looked inside it, but it seems like we could add an option to use it, and the messiness would show up either as a lot of tests for that option, or a lot of duplicated code (if the modules that otherwise would have all those tests would have two variants instead). Further, we might not be able to have a perfect automated choice for how to set the option. But either of those situations seems better to me than just not working well on some important system configuration.

But until more test results are in, it's hard to discuss this concretely.

Also it might be helpful if you would elaborate a bit on "acting a bit weird" :-)

- Bruce Smith

[greenmoss]

Yeah I apologize, "weird" isn't a useful description. I gave up on it
and returned to 32-bit. To run all the tests, do I just invoke
"nosetests" from inside the pyglet directory?

On Oct 30, 1:42 pm, Bruce Smith <ores...@gmail.com> wrote:

[Leonardo Santagada]

I would like to point out that a pure ctypes pyglet would run on pypy also, and ctypes in pypy is way faster than cpython so probably you will end up with faster games :)

[Richard Jones]

On 1 November 2011 00:35, greenmoss <ktyg...@yoderhome.com> wrote:
> Yeah I apologize, "weird" isn't a useful description. I gave up on it
> and returned to 32-bit. To run all the tests, do I just invoke
> "nosetests" from inside the pyglet directory?

No, they're not usual unit tests. You need to "pypy tests/test.py"

Richard

[Richard Jones]

On 1 November 2011 01:32, Leonardo Santagada <sant...@gmail.com> wrote:
> I would like to point out that a pure ctypes pyglet would run on pypy also,

In fact on OS X we require a pure ctypes pyglet because there's C
modules missing from pypy's repertoire. Unfortunately even with an
amazing effort the pure ctypes pyglet (a branch developed externally
to the core repository) is incomplete.

Richard

[Bruce Smith]

I think his question didn't involve pypy, and if so, then according to the module docstring of tests/test.py (and my very vague memory), the command you want is

% python tests/test.py

If you also want to tell OS X to run python in 32-bit mode (which I don't suppose you do, for testing that ctypes-not-PyObjC version, but anyway), then instead:

% arch -i386 python tests/test.py

(Someone who is more sure should probably edit README to say this, and update the list of supported python versions, platforms, etc.)

- Bruce

[Richard Jones]

On 1 November 2011 09:39, Bruce Smith <ore...@gmail.com> wrote:
> (Someone who is more sure should probably edit README to say this, and
> update the list of supported python versions, platforms, etc.)

Thanks for the reminder. I've added a short mention to the README.

I've left the supported platforms/versions alone until we've got a
better understanding of what they are :-)

Richard