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

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

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

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

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

Petr

On Thu, Oct 27, 2011 at 07:39, Thomas A R Woelz <two...@gmail.com> wrote:

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

     Richard

Adam.

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

On Wed, Oct 26, 2011 at 10:09 PM, Richard Jones <r1chardj0...@gmail.com>wrote:

    Richard

    Richard

  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

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

(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

pyglet.1.log 63K Download

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

    Richard

- Bruce

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

        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

(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

In the meanwhile it would be nice to see CHANGELOG<http://code.google.com/p/pyglet/source/browse/CHANGELOG>updated with changes up to 1.1.4 and above.

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

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

to facilitate following by OS (hope it it right)

--
claudio

On Oct 26, 9:09 pm, Richard Jones <r1chardj0...@gmail.com> wrote:

Christoph

On Oct 28, 6:08 am, Phillip Nguyen <evil.phil...@gmail.com> wrote:

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

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