Cannot run any pyglet ("long int too long to convert")

355 views
Skip to first unread message

Hello3171

unread,
Sep 11, 2011, 12:45:43 PM9/11/11
to pyglet-users
Traceback (most recent call last):
File "astraea.py", line 823, in <module>
fps_display =
pyglet.clock.ClockDisplay(font=pyglet.font.load(FONT_NAME, 24))
File "C:\Python27\lib\site-packages\pyglet\font\__init__.py", line
638, in load
font = _font_class(name, size, bold=bold, italic=italic, dpi=dpi)
File "C:\Python27\lib\site-packages\pyglet\font\win32.py", line 528,
in __init__
super(GDIPlusFont, self).__init__(name, size, bold, italic, dpi)
File "C:\Python27\lib\site-packages\pyglet\font\win32.py", line 334,
in __init__
gdi32.SelectObject(dc, self.hfont)
ctypes.ArgumentError: argument 2: <type 'exceptions.OverflowError'>:
long int too long to convert

I receive this error whenever I try to run a pyglet project. For
example, the above was from the astraea example with pyglet 1.1.4. I
am using python 2.7.2 (x64). Any idea what the problem is?

I had to install pyglet using setup.py and I 'installed' AVBin
separately.

claudio canepa

unread,
Sep 11, 2011, 1:11:13 PM9/11/11
to pyglet...@googlegroups.com
The 1.1.4 version is not compatible with win 64 + python 64 bits.
Someone patched the 1.2dev version and seems that it works, look at

If you try that way, it would be great if you  add a comment in that issue about your results.

--
claudio

Hello3171

unread,
Sep 11, 2011, 1:29:50 PM9/11/11
to pyglet-users
Hmm.. I will try the 1.2dev version.

Is it the "enhancements_1_2" branch found here
http://code.google.com/p/pyglet/source/browse/?name=enhancements_1_2?

Better learn how to use Mercurial too!

On Sep 11, 6:11 pm, claudio canepa <ccanep...@gmail.com> wrote:
> On Sun, Sep 11, 2011 at 1:45 PM, Hello3171 <hello3...@gmail.com> wrote:
> > Traceback (most recent call last):
> >  File "astraea.py", line 823, in <module>
> >    fps_display =
> > pyglet.clock.ClockDisplay(font=pyglet.font.load(FONT_NAME, 24))
> >  File "C:\Python27\lib\site-packages\pyglet\font\__init__.py", line
> > 638, in load
> >    font = _font_class(name, size, bold=bold, italic=italic, dpi=dpi)
> >  File "C:\Python27\lib\site-packages\pyglet\font\win32.py", line 528,
> > in __init__
> >    super(GDIPlusFont, self).__init__(name, size, bold, italic, dpi)
> >  File "C:\Python27\lib\site-packages\pyglet\font\win32.py", line 334,
> > in __init__
> >    gdi32.SelectObject(dc, self.hfont)
> > ctypes.ArgumentError: argument 2: <type 'exceptions.OverflowError'>:
> > long int too long to convert
>
> > I receive this error whenever I try to run a pyglet project. For
> > example, the above was from the astraea example with pyglet 1.1.4. I
> > am using python 2.7.2 (x64). Any idea what the problem is?
>
> > I had to install pyglet using setup.py and I 'installed' AVBin
> > separately.
>
> The 1.1.4 version is not compatible with win 64 + python 64 bits.
> Someone patched the 1.2dev version and seems that it works, look athttp://code.google.com/p/pyglet/issues/detail?id=510

claudio canepa

unread,
Sep 11, 2011, 1:44:08 PM9/11/11
to pyglet...@googlegroups.com
On Sun, Sep 11, 2011 at 2:29 PM, Hello3171 <hell...@gmail.com> wrote:
Hmm.. I will try the 1.2dev version.

Is it the "enhancements_1_2" branch found here
http://code.google.com/p/pyglet/source/browse/?name=enhancements_1_2?

Better learn how to use Mercurial too!

 

no, it is the default branch in the repo.
You can checkout with

hg clone http://code.google.com/p/pyglet/    pyglet_local

where  pyglet_local is any nonexistent dir name where you want the data to go.

Into that directory will be a pyglet directory which is the one you want to use.
Remember to patch as indicated in the issue 510, the patch is *not* incorporated in the current repo.

--
claudio



Hello3171

unread,
Mar 22, 2012, 3:24:25 PM3/22/12
to pyglet...@googlegroups.com
Well I finally got round to doing it. I updated with the patch in issue 510 and the astraea example works at least. How come the patch is not incorporated, lack of testing?

Although I did get this error when attempting to change into fullscreen mode:

Traceback (most recent call last):
  File "_ctypes/callbacks.c", line 313, in 'calling callback function'
  File "C:\Python27\lib\site-packages\pyglet\window\win32\__init__.py", line 612
, in _wnd_proc
    result = event_handler(msg, wParam, lParam)
  File "C:\Python27\lib\site-packages\pyglet\window\win32\__init__.py", line 693
, in _event_key
    self.dispatch_event(ev, symbol, modifiers)
  File "C:\Python27\lib\site-packages\pyglet\window\__init__.py", line 1151, in
dispatch_event
    if EventDispatcher.dispatch_event(self, *args) != False:
  File "C:\Python27\lib\site-packages\pyglet\event.py", line 355, in dispatch_ev
ent
    if handler(*args):
  File "astraea.py", line 351, in on_key_release
    self.items[self.selected_index].on_key_release(symbol, modifiers)
  File "astraea.py", line 423, in on_key_release
    self.toggle_func(self.value)
  File "astraea.py", line 481, in set_enable_fullscreen
    win.set_fullscreen(value, width=ARENA_WIDTH, height=ARENA_HEIGHT)
  File "C:\Python27\lib\site-packages\pyglet\window\__init__.py", line 651, in s
et_fullscreen
    self._windowed_location = self.get_location()
  File "C:\Python27\lib\site-packages\pyglet\window\win32\__init__.py", line 321
, in get_location
    _user32.ClientToScreen(self._hwnd, byref(rect))
ctypes.ArgumentError: argument 2: <type 'exceptions.TypeError'>: expected LP_POI
NT instance instead of pointer to RECT


I also tried running test.py although I'm not sure exactly how that works. Near the beginning when windows were supposed to start popping up, they simply didn't.

claudio canepa

unread,
Mar 22, 2012, 6:11:00 PM3/22/12
to pyglet...@googlegroups.com
--
 

The last problem seems to be the one reported at issu 559:

It includes code to workaround that.

Maybe you can give it a try and do follow ups in issues 510 - 559 ?

claudio

--

Hello3171

unread,
Mar 23, 2012, 7:53:20 AM3/23/12
to pyglet...@googlegroups.com
I updated with the code from issue 559, however, now when attempting to enter fullscreen mode the window simply freezes up.

I tracked the freeze occuring at Win32Screen:get_mode in pyglet/canvas/win32.py, specifically the "_user32..." line below

    def get_mode(self):
        mode = DEVMODE()
        mode.dmSize = sizeof(DEVMODE)
        _user32.EnumDisplaySettingsW(self.get_device_name(), ENUM_CURRENT_SETTINGS, byref(mode))
        return Win32ScreenMode(self, mode)

At this point I don't know what to do.

Christoph Gohlke

unread,
Mar 25, 2012, 11:37:26 AM3/25/12
to pyglet...@googlegroups.com
In the patch for #510, one of the EnumDisplaySettingsW parameters is wrong. Line 143 in pyglet\libs\win32\__init__.py should be

_user32.EnumDisplaySettingsW.argtypes = [c_wchar_p, DWORD, POINTER(DEVMODE)]

Christoph

Hello3171

unread,
Mar 25, 2012, 4:26:14 PM3/25/12
to pyglet...@googlegroups.com
Great that fixed the freeze issue! One question though, when you enter fullscreen in the astraea example should it scale to fit the entire screen? I have a 640x480 region (filled with the game) surrounded with blackness.

I want to run test.py to make sure everything else is working okay, however near the beginning where the tests claim that windows should be popping up, they really don't. There isn't even an error/exception.

Christoph Gohlke

unread,
Mar 25, 2012, 7:19:37 PM3/25/12
to pyglet...@googlegroups.com
On 3/25/2012 1:26 PM, Hello3171 wrote:
Great that fixed the freeze issue! One question though, when you enter fullscreen in the astraea example should it scale to fit the entire screen? I have a 640x480 region (filled with the game) surrounded with blackness.

Works for me.


I want to run test.py to make sure everything else is working okay, however near the beginning where the tests claim that windows should be popping up, they really don't. There isn't even an error/exception.

Works for me; sort of. The windows are created but occasionally the window tests hang when run as part of the whole test suite (not when run one by one). Anyway, the win-amd64 patch was not verified against the test suite, which was not functional at that time.

Christoph

Reply all
Reply to author
Forward
0 new messages