Yes, I though I was loosing it. I could not reproduce the problem on XP,
and no one else could reproduce it either. Only after I added printf
statements to pixelarray.c did I notice the break statement's absence.
That's what happens when one doesn't work with C on a regular basis.
Lenard
Ren
oh noes! the cursed switch statement strikes again.
Well done for squashing it :)
On Wed, Feb 27, 2008 at 4:54 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
>
> Brian Fisher wrote:
> > On Tue, Feb 26, 2008 at 12:07 PM, Lenard Lindstrom <[EMAIL PROTECTED]>
> wrote:
> >
> >> For both pass
Brian Fisher wrote:
On Tue, Feb 26, 2008 at 12:07 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
For both pass and fail I get (0,0,0) --> 0, (255,255,255) --> 127. But
sf.unmap_rgb(0x00ff) is (255,255,255), the same as sf.get_at((8,8)).
So the test should always fail. The question no
On Tue, Feb 26, 2008 at 12:07 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> For both pass and fail I get (0,0,0) --> 0, (255,255,255) --> 127. But
> sf.unmap_rgb(0x00ff) is (255,255,255), the same as sf.get_at((8,8)).
> So the test should always fail. The question now becomes, why does
are all the warnings fixed for that code? Maybe that'd give a clue?
setup.py -warnings
Have you tried a different video driver? Maybe that'd change things.
On Wed, Feb 27, 2008 at 7:07 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
> Brian Fisher wrote:
> > It seems to me once the failure
Brian Fisher wrote:
It seems to me once the failure is reliably repeatable it should be
fairly straightforward to debug, right?
I wish. :-)
...but I'm a bit confused, looking at the test that is failing, I'm
not sure how that could be considered a repeatable test...
The fails are not 1
It sounds like a win98 not setting memory to zero by default with the
undefined pallete? Whereas I think freebsd zeros memory by default?
Or maybe it's something to do with the video driver on win98 and the
set pallete call?
On Tue, Feb 26, 2008 at 8:44 PM, Marcus von Appen <[EMAIL PROTECTED]>
On, Mon Feb 25, 2008, Lenard Lindstrom wrote:
> I was trying out one of my custom Windows builds of Pygame 1.8.0rc3 rev
> 1126 with Python 2.4. Using run_tests.py to check the Python 2.4 version
> before release I found the following fail:
[...]
I just tried nearly any combination with clean i
It seems to me once the failure is reliably repeatable it should be
fairly straightforward to debug, right?
...but I'm a bit confused, looking at the test that is failing, I'm
not sure how that could be considered a repeatable test...
with 8 bpp, don't you have to set a palette? the SDL docs
SDL_
I have confirmed the problem also exists with Brian Fisher's build of
Python 2.4. So here are the specifics: Windows 98, Python 2.4.0 final 0,
Pygame 1.8.0rc3 rev 1126. Attached is the modified pixelarray_test.py.
All four test modules are required to cause the fail. I assume they must
execute
I have narrowed it down to four unit test modules, run in this order:
transform_test.py, surfarray_test.py, movie_test.py and
pixelarray_test.py . It appears all are necessary to get a consistent
fail. The test_contains method in pixelarray_test.py is the first method
executed, so commenting ou
Yeah, good point.
Another thing to try might be to try removing one of the other tests
at a time until the test stops failing.
On Tue, Feb 26, 2008 at 11:55 AM, Casey Duncan <[EMAIL PROTECTED]> wrote:
>
> On Feb 25, 2008, at 4:37 PM, Lenard Lindstrom wrote:
>
> > Lenard Lindstrom wrote:
> >>
On Feb 25, 2008, at 4:37 PM, Lenard Lindstrom wrote:
Lenard Lindstrom wrote:
[EMAIL PROTECTED] wrote:
Lenard Lindstrom <[EMAIL PROTECTED]>:
[snip]
I just bring this up since it shows possible problems with
testing more
than one version of Python on the same system. If it is a Pygame
bu
Maybe a thread related issue?
Or maybe an issue with set_at in 8 bit mode?
sf.set_at ((8, 8), (255, 255, 255))
On Tue, Feb 26, 2008 at 11:37 AM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote:
>
> [snip]
> The problem could be with the Python 2.4 unit testing framework itself.
> I put
Lenard Lindstrom wrote:
[EMAIL PROTECTED] wrote:
Lenard Lindstrom <[EMAIL PROTECTED]>:
[snip]
I just bring this up since it shows possible problems with testing more
than one version of Python on the same system. If it is a Pygame bug it
is unpredictable and hard to pin down. So please keep
[EMAIL PROTECTED] wrote:
Lenard Lindstrom <[EMAIL PROTECTED]>:
[snip]
I just bring this up since it shows possible problems with testing more
than one version of Python on the same system. If it is a Pygame bug it
is unpredictable and hard to pin down. So please keep a watch for
similar probl
Lenard Lindstrom <[EMAIL PROTECTED]>:
I was trying out one of my custom Windows builds of Pygame 1.8.0rc3 rev
1126 with Python 2.4. Using run_tests.py to check the Python 2.4
version before release I found the following fail:
.
I was trying out one of my custom Windows builds of Pygame 1.8.0rc3 rev
1126 with Python 2.4. Using run_tests.py to check the Python 2.4 version
before release I found the following fail:
F.
18 matches
Mail list logo