[pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
hi, Below are the failing unittests for Color on 64bit ubuntu. == FAIL: ColorTypeTest.test_float -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 412, in test_float self.assertEquals (float (c), float (0xCC00CC00)) AssertionError: 1.844674407283719e+19 != 3422604288.0 == FAIL: ColorTypeTest.test_hex -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 442, in test_hex self.assertEquals (hex (c), hex (0xCC00CC00)) AssertionError: '0xcc00cc00L' != '0xcc00cc00' == FAIL: ColorTypeTest.test_int -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 494, in test_int self.assertEquals (int (c), int (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288 == FAIL: ColorTypeTest.test_long -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 511, in test_long self.assertEquals (long (c), long (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288L == FAIL: ColorTypeTest.test_oct -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 427, in test_oct self.assertEquals (oct (c), oct (0xCC00CC00)) AssertionError: '017771400146000L' != '031400146000' == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 458, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11'
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Taking a look at color.c, I believe the bug may actually rest in the Pytype_FromUnsignedLong/Pytype_FromDouble/Pytype_FromString functions provided by the Python libs. There is no logical or numerical reason why, from the numbers we have, we would get those values with those operations. The tests beforehand affirm that the r, g, b, and a variables all the proper values, it just happens to be the one step in the code. I'll examine further. -Tyler On Fri, May 1, 2009 at 3:28 PM, René Dudfield ren...@gmail.com wrote: hi, Below are the failing unittests for Color on 64bit ubuntu. == FAIL: ColorTypeTest.test_float -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 412, in test_float self.assertEquals (float (c), float (0xCC00CC00)) AssertionError: 1.844674407283719e+19 != 3422604288.0 == FAIL: ColorTypeTest.test_hex -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 442, in test_hex self.assertEquals (hex (c), hex (0xCC00CC00)) AssertionError: '0xcc00cc00L' != '0xcc00cc00' == FAIL: ColorTypeTest.test_int -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 494, in test_int self.assertEquals (int (c), int (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288 == FAIL: ColorTypeTest.test_long -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 511, in test_long self.assertEquals (long (c), long (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288L == FAIL: ColorTypeTest.test_oct -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 427, in test_oct self.assertEquals (oct (c), oct (0xCC00CC00)) AssertionError: '017771400146000L' != '031400146000' == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 458, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
hi, there's some parts like this... static PyObject* _color_float (PyColor *color) { unsigned long tmp = (color-r 24) + (color-g 16) + (color-b 8) + color-a; return PyFloat_FromDouble ((double) tmp); } this code isn't endian or 64bit safe... since it is using bit shifting for packing. On different platforms, this produces different outputs. I think it has to convert into the same 32bit unsigned int, and then return that. On Sat, May 2, 2009 at 8:54 AM, Tyler Laing trinio...@gmail.com wrote: Taking a look at color.c, I believe the bug may actually rest in the Pytype_FromUnsignedLong/Pytype_FromDouble/Pytype_FromString functions provided by the Python libs. There is no logical or numerical reason why, from the numbers we have, we would get those values with those operations. The tests beforehand affirm that the r, g, b, and a variables all the proper values, it just happens to be the one step in the code. I'll examine further. -Tyler On Fri, May 1, 2009 at 3:28 PM, René Dudfield ren...@gmail.com wrote: hi, Below are the failing unittests for Color on 64bit ubuntu. == FAIL: ColorTypeTest.test_float -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 412, in test_float self.assertEquals (float (c), float (0xCC00CC00)) AssertionError: 1.844674407283719e+19 != 3422604288.0 == FAIL: ColorTypeTest.test_hex -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 442, in test_hex self.assertEquals (hex (c), hex (0xCC00CC00)) AssertionError: '0xcc00cc00L' != '0xcc00cc00' == FAIL: ColorTypeTest.test_int -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 494, in test_int self.assertEquals (int (c), int (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288 == FAIL: ColorTypeTest.test_long -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 511, in test_long self.assertEquals (long (c), long (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288L == FAIL: ColorTypeTest.test_oct -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 427, in test_oct self.assertEquals (oct (c), oct (0xCC00CC00)) AssertionError: '017771400146000L' != '031400146000' == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 458, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
I'll try that then. For reference, I am using an AMD Athlon 64 X2 5200+ processor. What would be the proper way to make it endian safe? Change the unsigned long tmp to unsigned int tmp? -Tyler On Fri, May 1, 2009 at 4:24 PM, René Dudfield ren...@gmail.com wrote: hi, there's some parts like this... static PyObject* _color_float (PyColor *color) { unsigned long tmp = (color-r 24) + (color-g 16) + (color-b 8) + color-a; return PyFloat_FromDouble ((double) tmp); } this code isn't endian or 64bit safe... since it is using bit shifting for packing. On different platforms, this produces different outputs. I think it has to convert into the same 32bit unsigned int, and then return that. On Sat, May 2, 2009 at 8:54 AM, Tyler Laing trinio...@gmail.com wrote: Taking a look at color.c, I believe the bug may actually rest in the Pytype_FromUnsignedLong/Pytype_FromDouble/Pytype_FromString functions provided by the Python libs. There is no logical or numerical reason why, from the numbers we have, we would get those values with those operations. The tests beforehand affirm that the r, g, b, and a variables all the proper values, it just happens to be the one step in the code. I'll examine further. -Tyler On Fri, May 1, 2009 at 3:28 PM, René Dudfield ren...@gmail.com wrote: hi, Below are the failing unittests for Color on 64bit ubuntu. == FAIL: ColorTypeTest.test_float -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 412, in test_float self.assertEquals (float (c), float (0xCC00CC00)) AssertionError: 1.844674407283719e+19 != 3422604288.0 == FAIL: ColorTypeTest.test_hex -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 442, in test_hex self.assertEquals (hex (c), hex (0xCC00CC00)) AssertionError: '0xcc00cc00L' != '0xcc00cc00' == FAIL: ColorTypeTest.test_int -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 494, in test_int self.assertEquals (int (c), int (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288 == FAIL: ColorTypeTest.test_long -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 511, in test_long self.assertEquals (long (c), long (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288L == FAIL: ColorTypeTest.test_oct -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 427, in test_oct self.assertEquals (oct (c), oct (0xCC00CC00)) AssertionError: '017771400146000L' != '031400146000' == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 458, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' -- Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Rene, You are right. I isolated the specific issue, and here's a sample .c file that shows the error on the 64 bit platform. When I get something that works on the the test file, I'll try it on the actual pygame code and see how the test performs. -Tyler On Fri, May 1, 2009 at 4:30 PM, Tyler Laing trinio...@gmail.com wrote: I'll try that then. For reference, I am using an AMD Athlon 64 X2 5200+ processor. What would be the proper way to make it endian safe? Change the unsigned long tmp to unsigned int tmp? -Tyler On Fri, May 1, 2009 at 4:24 PM, René Dudfield ren...@gmail.com wrote: hi, there's some parts like this... static PyObject* _color_float (PyColor *color) { unsigned long tmp = (color-r 24) + (color-g 16) + (color-b 8) + color-a; return PyFloat_FromDouble ((double) tmp); } this code isn't endian or 64bit safe... since it is using bit shifting for packing. On different platforms, this produces different outputs. I think it has to convert into the same 32bit unsigned int, and then return that. On Sat, May 2, 2009 at 8:54 AM, Tyler Laing trinio...@gmail.com wrote: Taking a look at color.c, I believe the bug may actually rest in the Pytype_FromUnsignedLong/Pytype_FromDouble/Pytype_FromString functions provided by the Python libs. There is no logical or numerical reason why, from the numbers we have, we would get those values with those operations. The tests beforehand affirm that the r, g, b, and a variables all the proper values, it just happens to be the one step in the code. I'll examine further. -Tyler On Fri, May 1, 2009 at 3:28 PM, René Dudfield ren...@gmail.com wrote: hi, Below are the failing unittests for Color on 64bit ubuntu. == FAIL: ColorTypeTest.test_float -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 412, in test_float self.assertEquals (float (c), float (0xCC00CC00)) AssertionError: 1.844674407283719e+19 != 3422604288.0 == FAIL: ColorTypeTest.test_hex -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 442, in test_hex self.assertEquals (hex (c), hex (0xCC00CC00)) AssertionError: '0xcc00cc00L' != '0xcc00cc00' == FAIL: ColorTypeTest.test_int -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 494, in test_int self.assertEquals (int (c), int (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288 == FAIL: ColorTypeTest.test_long -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 511, in test_long self.assertEquals (long (c), long (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288L == FAIL: ColorTypeTest.test_oct -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 427, in test_oct self.assertEquals (oct (c), oct (0xCC00CC00)) AssertionError: '017771400146000L' != '031400146000' == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 458, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' -- Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog //test_color.c #include stdio.h #include ctype.h #include stdint.h typedef uint8_t Uint8; main() { Uint8 r=204; Uint8 g=0; Uint8 b=204; Uint8 a=0; unsigned long tmp = (r 24) + (g 16) + (b 8) + a; printf(%lu\n, tmp); }
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Rene, Okay, so I've got a fix. You have to prefix color-r with (long), and then for hex and oct functions, you need to change INT_MAX to LONG_MAX for a 64 bit platform. How do I make a patch for submission? -Tyler On Fri, May 1, 2009 at 5:33 PM, Tyler Laing trinio...@gmail.com wrote: Rene, You are right. I isolated the specific issue, and here's a sample .c file that shows the error on the 64 bit platform. When I get something that works on the the test file, I'll try it on the actual pygame code and see how the test performs. -Tyler On Fri, May 1, 2009 at 4:30 PM, Tyler Laing trinio...@gmail.com wrote: I'll try that then. For reference, I am using an AMD Athlon 64 X2 5200+ processor. What would be the proper way to make it endian safe? Change the unsigned long tmp to unsigned int tmp? -Tyler On Fri, May 1, 2009 at 4:24 PM, René Dudfield ren...@gmail.com wrote: hi, there's some parts like this... static PyObject* _color_float (PyColor *color) { unsigned long tmp = (color-r 24) + (color-g 16) + (color-b 8) + color-a; return PyFloat_FromDouble ((double) tmp); } this code isn't endian or 64bit safe... since it is using bit shifting for packing. On different platforms, this produces different outputs. I think it has to convert into the same 32bit unsigned int, and then return that. On Sat, May 2, 2009 at 8:54 AM, Tyler Laing trinio...@gmail.com wrote: Taking a look at color.c, I believe the bug may actually rest in the Pytype_FromUnsignedLong/Pytype_FromDouble/Pytype_FromString functions provided by the Python libs. There is no logical or numerical reason why, from the numbers we have, we would get those values with those operations. The tests beforehand affirm that the r, g, b, and a variables all the proper values, it just happens to be the one step in the code. I'll examine further. -Tyler On Fri, May 1, 2009 at 3:28 PM, René Dudfield ren...@gmail.com wrote: hi, Below are the failing unittests for Color on 64bit ubuntu. == FAIL: ColorTypeTest.test_float -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 412, in test_float self.assertEquals (float (c), float (0xCC00CC00)) AssertionError: 1.844674407283719e+19 != 3422604288.0 == FAIL: ColorTypeTest.test_hex -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 442, in test_hex self.assertEquals (hex (c), hex (0xCC00CC00)) AssertionError: '0xcc00cc00L' != '0xcc00cc00' == FAIL: ColorTypeTest.test_int -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 494, in test_int self.assertEquals (int (c), int (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288 == FAIL: ColorTypeTest.test_long -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 511, in test_long self.assertEquals (long (c), long (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288L == FAIL: ColorTypeTest.test_oct -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 427, in test_oct self.assertEquals (oct (c), oct (0xCC00CC00)) AssertionError: '017771400146000L' != '031400146000' == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 458, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' -- Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Hi, cool, nice one. make your change to the file/files, make sure it compiles and passes the tests... Then run: svn diff patch.diff Then send the patch to the mailing list... or upload it somewhere, and send a link to it if it's really big... or just paste it into the email if it's tiny. cu, On Sat, May 2, 2009 at 11:21 AM, Tyler Laing trinio...@gmail.com wrote: Rene, Okay, so I've got a fix. You have to prefix color-r with (long), and then for hex and oct functions, you need to change INT_MAX to LONG_MAX for a 64 bit platform. How do I make a patch for submission? -Tyler On Fri, May 1, 2009 at 5:33 PM, Tyler Laing trinio...@gmail.com wrote: Rene, You are right. I isolated the specific issue, and here's a sample .c file that shows the error on the 64 bit platform. When I get something that works on the the test file, I'll try it on the actual pygame code and see how the test performs. -Tyler On Fri, May 1, 2009 at 4:30 PM, Tyler Laing trinio...@gmail.com wrote: I'll try that then. For reference, I am using an AMD Athlon 64 X2 5200+ processor. What would be the proper way to make it endian safe? Change the unsigned long tmp to unsigned int tmp? -Tyler On Fri, May 1, 2009 at 4:24 PM, René Dudfield ren...@gmail.com wrote: hi, there's some parts like this... static PyObject* _color_float (PyColor *color) { unsigned long tmp = (color-r 24) + (color-g 16) + (color-b 8) + color-a; return PyFloat_FromDouble ((double) tmp); } this code isn't endian or 64bit safe... since it is using bit shifting for packing. On different platforms, this produces different outputs. I think it has to convert into the same 32bit unsigned int, and then return that. On Sat, May 2, 2009 at 8:54 AM, Tyler Laing trinio...@gmail.com wrote: Taking a look at color.c, I believe the bug may actually rest in the Pytype_FromUnsignedLong/Pytype_FromDouble/Pytype_FromString functions provided by the Python libs. There is no logical or numerical reason why, from the numbers we have, we would get those values with those operations. The tests beforehand affirm that the r, g, b, and a variables all the proper values, it just happens to be the one step in the code. I'll examine further. -Tyler On Fri, May 1, 2009 at 3:28 PM, René Dudfield ren...@gmail.com wrote: hi, Below are the failing unittests for Color on 64bit ubuntu. == FAIL: ColorTypeTest.test_float -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 412, in test_float self.assertEquals (float (c), float (0xCC00CC00)) AssertionError: 1.844674407283719e+19 != 3422604288.0 == FAIL: ColorTypeTest.test_hex -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 442, in test_hex self.assertEquals (hex (c), hex (0xCC00CC00)) AssertionError: '0xcc00cc00L' != '0xcc00cc00' == FAIL: ColorTypeTest.test_int -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 494, in test_int self.assertEquals (int (c), int (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288 == FAIL: ColorTypeTest.test_long -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 511, in test_long self.assertEquals (long (c), long (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288L == FAIL: ColorTypeTest.test_oct -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 427, in test_oct self.assertEquals (oct (c), oct (0xCC00CC00)) AssertionError: '017771400146000L' != '031400146000' == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 458, in test_webstyle
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Correction, you have to do this: unsigned long tmp = ((long)color-r 24) + ((long)color-g 16) + ((long)color-b 8) +... to be specific. -Tyler On Fri, May 1, 2009 at 6:21 PM, Tyler Laing trinio...@gmail.com wrote: Rene, Okay, so I've got a fix. You have to prefix color-r with (long), and then for hex and oct functions, you need to change INT_MAX to LONG_MAX for a 64 bit platform. How do I make a patch for submission? -Tyler On Fri, May 1, 2009 at 5:33 PM, Tyler Laing trinio...@gmail.com wrote: Rene, You are right. I isolated the specific issue, and here's a sample .c file that shows the error on the 64 bit platform. When I get something that works on the the test file, I'll try it on the actual pygame code and see how the test performs. -Tyler On Fri, May 1, 2009 at 4:30 PM, Tyler Laing trinio...@gmail.com wrote: I'll try that then. For reference, I am using an AMD Athlon 64 X2 5200+ processor. What would be the proper way to make it endian safe? Change the unsigned long tmp to unsigned int tmp? -Tyler On Fri, May 1, 2009 at 4:24 PM, René Dudfield ren...@gmail.com wrote: hi, there's some parts like this... static PyObject* _color_float (PyColor *color) { unsigned long tmp = (color-r 24) + (color-g 16) + (color-b 8) + color-a; return PyFloat_FromDouble ((double) tmp); } this code isn't endian or 64bit safe... since it is using bit shifting for packing. On different platforms, this produces different outputs. I think it has to convert into the same 32bit unsigned int, and then return that. On Sat, May 2, 2009 at 8:54 AM, Tyler Laing trinio...@gmail.com wrote: Taking a look at color.c, I believe the bug may actually rest in the Pytype_FromUnsignedLong/Pytype_FromDouble/Pytype_FromString functions provided by the Python libs. There is no logical or numerical reason why, from the numbers we have, we would get those values with those operations. The tests beforehand affirm that the r, g, b, and a variables all the proper values, it just happens to be the one step in the code. I'll examine further. -Tyler On Fri, May 1, 2009 at 3:28 PM, René Dudfield ren...@gmail.com wrote: hi, Below are the failing unittests for Color on 64bit ubuntu. == FAIL: ColorTypeTest.test_float -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 412, in test_float self.assertEquals (float (c), float (0xCC00CC00)) AssertionError: 1.844674407283719e+19 != 3422604288.0 == FAIL: ColorTypeTest.test_hex -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 442, in test_hex self.assertEquals (hex (c), hex (0xCC00CC00)) AssertionError: '0xcc00cc00L' != '0xcc00cc00' == FAIL: ColorTypeTest.test_int -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 494, in test_int self.assertEquals (int (c), int (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288 == FAIL: ColorTypeTest.test_long -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 511, in test_long self.assertEquals (long (c), long (0xCC00CC00)) AssertionError: 18446744072837188608L != 3422604288L == FAIL: ColorTypeTest.test_oct -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 427, in test_oct self.assertEquals (oct (c), oct (0xCC00CC00)) AssertionError: '017771400146000L' != '031400146000' == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 458, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' -- Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Cool, thanks. I think we can look applying this patch after Lenard has merged his py3k stuff back in... so we don't get any many conflicts. As I noticed he's already touched the color.c. We shouldn't ever be returning a long I don't think. So perhaps we can do a conversion from python long to python int at the end of the functions. For endian checking, you can use this define... #if SDL_BYTEORDER == SDL_LIL_ENDIAN // lil endian code here... #else // big endian code here... #endif However, I'm not positive the color code *should* be endian safe... without using the map/unmap methods on Surface for example. However I think maybe it should be. We will have to study how it is being used at the moment... and how the old behaviour worked(as some code might rely on it being endian unsafe). ps. with patches it's good to check them to make sure they're only for the change you made... not for other issues at the same time. eg, there were lots of windows end of line characters in the color test before, and your patch removes them. pps. just a note, that a request has been put in to the lovely server administrators at seul.org for adding svn accounts for the all the GSOC peoples. So you should get your svn account within a week or so. cu, On Sat, May 2, 2009 at 11:42 AM, Tyler Laing trinio...@gmail.com wrote: Hmm, just noticed another issue. I had to make the change from INT_MAX to LONG_MAX because the outputs for the specific number had an 'L' on the end of them, where the number exceeds INT_MAX, and so a 'L' is appended to the end of the outputs from oct and hex, which causes a lot of fails, as when Python converts the numbers to hex/int, there is no 'L' on the end of that value. Basically this line: self.assertEquals (hex (c), str(hex (0xCC00CC11)) fails with this message: == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 465, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' My fix, which I do not like, at all, is: self.assertEquals (str(hex (c))[:-1], str(hex (0xCC00CCFF))) I don't know if this would behave differently on a 32 bit platform. Here is the patch.diff. -Tyler On Fri, May 1, 2009 at 6:23 PM, René Dudfield ren...@gmail.com wrote: Hi, cool, nice one. make your change to the file/files, make sure it compiles and passes the tests... Then run: svn diff patch.diff Then send the patch to the mailing list... or upload it somewhere, and send a link to it if it's really big... or just paste it into the email if it's tiny. cu, On Sat, May 2, 2009 at 11:21 AM, Tyler Laing trinio...@gmail.com wrote: Rene, Okay, so I've got a fix. You have to prefix color-r with (long), and then for hex and oct functions, you need to change INT_MAX to LONG_MAX for a 64 bit platform. How do I make a patch for submission? -Tyler On Fri, May 1, 2009 at 5:33 PM, Tyler Laing trinio...@gmail.com wrote: Rene, You are right. I isolated the specific issue, and here's a sample .c file that shows the error on the 64 bit platform. When I get something that works on the the test file, I'll try it on the actual pygame code and see how the test performs. -Tyler On Fri, May 1, 2009 at 4:30 PM, Tyler Laing trinio...@gmail.com wrote: I'll try that then. For reference, I am using an AMD Athlon 64 X2 5200+ processor. What would be the proper way to make it endian safe? Change the unsigned long tmp to unsigned int tmp? -Tyler On Fri, May 1, 2009 at 4:24 PM, René Dudfield ren...@gmail.com wrote: hi, there's some parts like this... static PyObject* _color_float (PyColor *color) { unsigned long tmp = (color-r 24) + (color-g 16) + (color-b 8) + color-a; return PyFloat_FromDouble ((double) tmp); } this code isn't endian or 64bit safe... since it is using bit shifting for packing. On different platforms, this produces different outputs. I think it has to convert into the same 32bit unsigned int, and then return that. On Sat, May 2, 2009 at 8:54 AM, Tyler Laing trinio...@gmail.com wrote: Taking a look at color.c, I believe the bug may actually rest in the Pytype_FromUnsignedLong/Pytype_FromDouble/Pytype_FromString functions provided by the Python libs. There is no logical or numerical reason why, from the numbers we have, we would get those values with those operations. The tests beforehand affirm that the r, g, b, and a variables all the proper values, it just happens to be the one step in the code. I'll examine further. -Tyler On Fri, May 1, 2009 at 3:28 PM, René Dudfield
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Rene, Oops, about the windows line ends. I'll make sure that doesn't happen again. Sorry about that. I do have SVN write access now, I just wanted to start with the patch first. I honestly don't know much about pygame.color, so I can't help there. However, if we never want to return a long, then, we can change: /** * oct(color) */ static PyObject* _color_oct (PyColor *color) { char buf[100]; unsigned long tmp = ((long)color-r 24) + ((long)color-g 16) + ((long)color-b 8) + color-a; if (tmp INT_MAX) PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); else PyOS_snprintf (buf, sizeof (buf), 0%loL, tmp); return PyString_FromString (buf); } to static PyObject* _color_oct (PyColor *color) { char buf[100]; unsigned long tmp = ((long)color-r 24) + ((long)color-g 16) + ((long)color-b 8) + color-a; if (tmp INT_MAX) PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); else PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); return PyString_FromString (buf); } as an example, where we remove the 'L' from the else branch. I've got a fixed patch.diff now, where we don't return longs, and its a lot smaller, because color_test.py does not need the fixes now. I only have one error in the tests, and that results from not having the right permissions, which is solved by a simple sudo. -Tyler On Fri, May 1, 2009 at 6:59 PM, René Dudfield ren...@gmail.com wrote: Cool, thanks. I think we can look applying this patch after Lenard has merged his py3k stuff back in... so we don't get any many conflicts. As I noticed he's already touched the color.c. We shouldn't ever be returning a long I don't think. So perhaps we can do a conversion from python long to python int at the end of the functions. For endian checking, you can use this define... #if SDL_BYTEORDER == SDL_LIL_ENDIAN // lil endian code here... #else // big endian code here... #endif However, I'm not positive the color code *should* be endian safe... without using the map/unmap methods on Surface for example. However I think maybe it should be. We will have to study how it is being used at the moment... and how the old behaviour worked(as some code might rely on it being endian unsafe). ps. with patches it's good to check them to make sure they're only for the change you made... not for other issues at the same time. eg, there were lots of windows end of line characters in the color test before, and your patch removes them. pps. just a note, that a request has been put in to the lovely server administrators at seul.org for adding svn accounts for the all the GSOC peoples. So you should get your svn account within a week or so. cu, On Sat, May 2, 2009 at 11:42 AM, Tyler Laing trinio...@gmail.com wrote: Hmm, just noticed another issue. I had to make the change from INT_MAX to LONG_MAX because the outputs for the specific number had an 'L' on the end of them, where the number exceeds INT_MAX, and so a 'L' is appended to the end of the outputs from oct and hex, which causes a lot of fails, as when Python converts the numbers to hex/int, there is no 'L' on the end of that value. Basically this line: self.assertEquals (hex (c), str(hex (0xCC00CC11)) fails with this message: == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 465, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' My fix, which I do not like, at all, is: self.assertEquals (str(hex (c))[:-1], str(hex (0xCC00CCFF))) I don't know if this would behave differently on a 32 bit platform. Here is the patch.diff. -Tyler On Fri, May 1, 2009 at 6:23 PM, René Dudfield ren...@gmail.com wrote: Hi, cool, nice one. make your change to the file/files, make sure it compiles and passes the tests... Then run: svn diff patch.diff Then send the patch to the mailing list... or upload it somewhere, and send a link to it if it's really big... or just paste it into the email if it's tiny. cu, On Sat, May 2, 2009 at 11:21 AM, Tyler Laing trinio...@gmail.com wrote: Rene, Okay, so I've got a fix. You have to prefix color-r with (long), and then for hex and oct functions, you need to change INT_MAX to LONG_MAX for a 64 bit platform. How do I make a patch for submission? -Tyler On Fri, May 1, 2009 at 5:33 PM, Tyler Laing trinio...@gmail.com wrote: Rene, You are right. I isolated the specific issue, and here's a sample .c file that shows the error on the 64 bit platform. When I get something that works on the the test file, I'll try it on the
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Hi Tyler, This patch breaks things for 32bit machines. Give me a few minutes and I will see if I can cook something up. Lenard Tyler Laing wrote: Rene, Oops, about the windows line ends. I'll make sure that doesn't happen again. Sorry about that. I do have SVN write access now, I just wanted to start with the patch first. I honestly don't know much about pygame.color, so I can't help there. However, if we never want to return a long, then, we can change: /** * oct(color) */ static PyObject* _color_oct (PyColor *color) { char buf[100]; unsigned long tmp = ((long)color-r 24) + ((long)color-g 16) + ((long)color-b 8) + color-a; if (tmp INT_MAX) PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); else PyOS_snprintf (buf, sizeof (buf), 0%loL, tmp); return PyString_FromString (buf); } to static PyObject* _color_oct (PyColor *color) { char buf[100]; unsigned long tmp = ((long)color-r 24) + ((long)color-g 16) + ((long)color-b 8) + color-a; if (tmp INT_MAX) PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); else PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); return PyString_FromString (buf); } as an example, where we remove the 'L' from the else branch. I've got a fixed patch.diff now, where we don't return longs, and its a lot smaller, because color_test.py does not need the fixes now. I only have one error in the tests, and that results from not having the right permissions, which is solved by a simple sudo. -Tyler On Fri, May 1, 2009 at 6:59 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: Cool, thanks. I think we can look applying this patch after Lenard has merged his py3k stuff back in... so we don't get any many conflicts. As I noticed he's already touched the color.c. We shouldn't ever be returning a long I don't think. So perhaps we can do a conversion from python long to python int at the end of the functions. For endian checking, you can use this define... #if SDL_BYTEORDER == SDL_LIL_ENDIAN // lil endian code here... #else // big endian code here... #endif However, I'm not positive the color code *should* be endian safe... without using the map/unmap methods on Surface for example. However I think maybe it should be. We will have to study how it is being used at the moment... and how the old behaviour worked(as some code might rely on it being endian unsafe). ps. with patches it's good to check them to make sure they're only for the change you made... not for other issues at the same time. eg, there were lots of windows end of line characters in the color test before, and your patch removes them. pps. just a note, that a request has been put in to the lovely server administrators at seul.org http://seul.org for adding svn accounts for the all the GSOC peoples. So you should get your svn account within a week or so. cu, On Sat, May 2, 2009 at 11:42 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com wrote: Hmm, just noticed another issue. I had to make the change from INT_MAX to LONG_MAX because the outputs for the specific number had an 'L' on the end of them, where the number exceeds INT_MAX, and so a 'L' is appended to the end of the outputs from oct and hex, which causes a lot of fails, as when Python converts the numbers to hex/int, there is no 'L' on the end of that value. Basically this line: self.assertEquals (hex (c), str(hex (0xCC00CC11)) fails with this message: == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 465, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' My fix, which I do not like, at all, is: self.assertEquals (str(hex (c))[:-1], str(hex (0xCC00CCFF))) I don't know if this would behave differently on a 32 bit platform. Here is the patch.diff. -Tyler On Fri, May 1, 2009 at 6:23 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: Hi, cool, nice one. make your change to the file/files, make sure it compiles and passes the tests... Then run: svn diff patch.diff Then send the patch to the mailing list... or upload it somewhere, and send a link to it if it's really big... or just paste it into the email if it's tiny. cu, On Sat, May 2, 2009 at 11:21 AM, Tyler Laing trinio...@gmail.com
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Are you using the second patch I provided? I had to make some modifications initially to the color_test.py, which I had a feeling would break on 32 bit machines. The second patch avoids modifying color_test.py, and instead does not cast the results from hex and oct as longs, which was adding a 'L' to the end of the result, but rather as ints every time. -Tyler On Fri, May 1, 2009 at 8:41 PM, Lenard Lindstrom le...@telus.net wrote: Hi Tyler, This patch breaks things for 32bit machines. Give me a few minutes and I will see if I can cook something up. Lenard Tyler Laing wrote: Rene, Oops, about the windows line ends. I'll make sure that doesn't happen again. Sorry about that. I do have SVN write access now, I just wanted to start with the patch first. I honestly don't know much about pygame.color, so I can't help there. However, if we never want to return a long, then, we can change: /** * oct(color) */ static PyObject* _color_oct (PyColor *color) { char buf[100]; unsigned long tmp = ((long)color-r 24) + ((long)color-g 16) + ((long)color-b 8) + color-a; if (tmp INT_MAX) PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); else PyOS_snprintf (buf, sizeof (buf), 0%loL, tmp); return PyString_FromString (buf); } to static PyObject* _color_oct (PyColor *color) { char buf[100]; unsigned long tmp = ((long)color-r 24) + ((long)color-g 16) + ((long)color-b 8) + color-a; if (tmp INT_MAX) PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); else PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); return PyString_FromString (buf); } as an example, where we remove the 'L' from the else branch. I've got a fixed patch.diff now, where we don't return longs, and its a lot smaller, because color_test.py does not need the fixes now. I only have one error in the tests, and that results from not having the right permissions, which is solved by a simple sudo. -Tyler On Fri, May 1, 2009 at 6:59 PM, René Dudfield ren...@gmail.com mailto: ren...@gmail.com wrote: Cool, thanks. I think we can look applying this patch after Lenard has merged his py3k stuff back in... so we don't get any many conflicts. As I noticed he's already touched the color.c. We shouldn't ever be returning a long I don't think. So perhaps we can do a conversion from python long to python int at the end of the functions. For endian checking, you can use this define... #if SDL_BYTEORDER == SDL_LIL_ENDIAN // lil endian code here... #else // big endian code here... #endif However, I'm not positive the color code *should* be endian safe... without using the map/unmap methods on Surface for example. However I think maybe it should be. We will have to study how it is being used at the moment... and how the old behaviour worked(as some code might rely on it being endian unsafe). ps. with patches it's good to check them to make sure they're only for the change you made... not for other issues at the same time. eg, there were lots of windows end of line characters in the color test before, and your patch removes them. pps. just a note, that a request has been put in to the lovely server administrators at seul.org http://seul.org for adding svn accounts for the all the GSOC peoples. So you should get your svn account within a week or so. cu, On Sat, May 2, 2009 at 11:42 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com wrote: Hmm, just noticed another issue. I had to make the change from INT_MAX to LONG_MAX because the outputs for the specific number had an 'L' on the end of them, where the number exceeds INT_MAX, and so a 'L' is appended to the end of the outputs from oct and hex, which causes a lot of fails, as when Python converts the numbers to hex/int, there is no 'L' on the end of that value. Basically this line: self.assertEquals (hex (c), str(hex (0xCC00CC11)) fails with this message: == FAIL: ColorTypeTest.test_webstyle -- Traceback (most recent call last): File /usr/lib/python2.5/site-packages/pygame/tests/color_test.py, line 465, in test_webstyle self.assertEquals (hex (c), hex (0xCC00CC11)) AssertionError: '0xcc00cc11L' != '0xcc00cc11' My fix, which I do not like, at all, is: self.assertEquals (str(hex (c))[:-1], str(hex (0xCC00CCFF))) I don't know if this would behave differently on a 32 bit platform. Here is the patch.diff. -Tyler On Fri, May 1, 2009 at 6:23 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: Hi,
Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You
Hi, Yes, I was using the second patch which only modifies color.c. However the 'L's are necessary on 32 bit machines since 0xCC00CC00 can only be represented as a Python long. So try this patch. It keeps the Ls but replaces INT_MAX with LONG_MAX, which is the proper test for a Python int (*). Lenard (*) ints are longs and longs are, well, something else. Tyler Laing wrote: Are you using the second patch I provided? I had to make some modifications initially to the color_test.py, which I had a feeling would break on 32 bit machines. The second patch avoids modifying color_test.py, and instead does not cast the results from hex and oct as longs, which was adding a 'L' to the end of the result, but rather as ints every time. -Tyler On Fri, May 1, 2009 at 8:41 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: Hi Tyler, This patch breaks things for 32bit machines. Give me a few minutes and I will see if I can cook something up. Lenard Tyler Laing wrote: Rene, Oops, about the windows line ends. I'll make sure that doesn't happen again. Sorry about that. I do have SVN write access now, I just wanted to start with the patch first. I honestly don't know much about pygame.color, so I can't help there. However, if we never want to return a long, then, we can change: /** * oct(color) */ static PyObject* _color_oct (PyColor *color) { char buf[100]; unsigned long tmp = ((long)color-r 24) + ((long)color-g 16) + ((long)color-b 8) + color-a; if (tmp INT_MAX) PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); else PyOS_snprintf (buf, sizeof (buf), 0%loL, tmp); return PyString_FromString (buf); } to static PyObject* _color_oct (PyColor *color) { char buf[100]; unsigned long tmp = ((long)color-r 24) + ((long)color-g 16) + ((long)color-b 8) + color-a; if (tmp INT_MAX) PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); else PyOS_snprintf (buf, sizeof (buf), 0%lo, tmp); return PyString_FromString (buf); } as an example, where we remove the 'L' from the else branch. I've got a fixed patch.diff now, where we don't return longs, and its a lot smaller, because color_test.py does not need the fixes now. I only have one error in the tests, and that results from not having the right permissions, which is solved by a simple sudo. -Tyler On Fri, May 1, 2009 at 6:59 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com wrote: Cool, thanks. I think we can look applying this patch after Lenard has merged his py3k stuff back in... so we don't get any many conflicts. As I noticed he's already touched the color.c. We shouldn't ever be returning a long I don't think. So perhaps we can do a conversion from python long to python int at the end of the functions. For endian checking, you can use this define... #if SDL_BYTEORDER == SDL_LIL_ENDIAN // lil endian code here... #else // big endian code here... #endif However, I'm not positive the color code *should* be endian safe... without using the map/unmap methods on Surface for example. However I think maybe it should be. We will have to study how it is being used at the moment... and how the old behaviour worked(as some code might rely on it being endian unsafe). ps. with patches it's good to check them to make sure they're only for the change you made... not for other issues at the same time. eg, there were lots of windows end of line characters in the color test before, and your patch removes them. pps. just a note, that a request has been put in to the lovely server administrators at seul.org http://seul.org http://seul.org for adding svn accounts for the all the GSOC peoples. So you should get your svn account within a week or so. cu, On Sat, May 2, 2009 at 11:42 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com wrote: Hmm, just noticed another issue. I had to make the change from INT_MAX to LONG_MAX because the outputs for the specific number had an 'L'