[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'
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Did you do python config.py first? This takes Setup.in and creates a new Setup file used by setup.py. When running config.py specify 'y' to msys build. It will tell you if it finds the files or not. Why there is a separate config step is because dependencies may be provided in several ways. If config.py does not provide an 'msys' option then set environment variable MINGW_ROOT_DIRECTORY to the MinGW root directory (eg C:\MinGW) and LOCALBASE to C:\msys\1.0\local . Lenard Tyler Laing wrote: So that worked, thank you Lenard. All of them compiled. I'm now getting this error: $ /c/Python25/python.exe setup.py build --compiler=mingw32 WARNING, DLL for smpeg library not found. WARNING, DLL for tiff library not found. WARNING, DLL for SDL_ttf library not found. WARNING, DLL for SDL_image library not found. WARNING, DLL for vorbisfile library not found. WARNING, DLL for jpeg library not found. WARNING, DLL for vorbis library not found. WARNING, DLL for SDL library not found. WARNING, DLL for portmidi library not found. WARNING, DLL for SDL_mixer library not found. WARNING, DLL for ogg library not found. WARNING, DLL for z library not found. WARNING, DLL for png library not found. running build running build_py running build_ext Traceback (most recent call last): File setup.py, line 459, in module setup(**PACKAGEDATA) File C:\Python25\lib\distutils\core.py, line 151, in setup dist.run_commands() File C:\Python25\lib\distutils\dist.py, line 974, in run_commands self.run_command(cmd) File C:\Python25\lib\distutils\dist.py, line 994, in run_command cmd_obj.run() File C:\Python25\lib\distutils\command\build.py, line 112, in run self.run_command(cmd_name) File C:\Python25\lib\distutils\cmd.py, line 333, in run_command self.distribution.run_command(command) File C:\Python25\lib\distutils\dist.py, line 994, in run_command cmd_obj.run() File setup.py, line 324, in run sys.version_info[:2]) RuntimeError: The dependencies are linked to the wrong C runtime for Python 2.5 But beforehand, we had this: SDL : Installed new DLL c:\msys\1.0\local\bin\SDL.dll Z : Installed new DLL c:\msys\1.0\local\bin\zlib1.dll FREETYPE : Installed new DLL c:\msys\1.0\local\bin\libfreetype-6.dll FONT : Installed new DLL c:\msys\1.0\local\bin\SDL_ttf.dll PNG : Installed new DLL c:\msys\1.0\local\bin\libpng12-0.dll JPEG : Installed new DLL c:\msys\1.0\local\bin\jpeg.dll TIFF : Installed new DLL c:\msys\1.0\local\bin\libtiff.dll IMAGE : Installed new DLL c:\msys\1.0\local\bin\SDL_image.dll SMPEG : Installed new DLL c:\msys\1.0\local\bin\smpeg.dll OGG : Installed new DLL c:\msys\1.0\local\bin\libogg-0.dll VORBIS: Installed new DLL c:\msys\1.0\local\bin\libvorbis-0.dll VORBIS: Installed new DLL c:\msys\1.0\local\bin\libvorbisfile-3.dll MIXER : Installed new DLL c:\msys\1.0\local\bin\SDL_mixer.dll PORTMIDI : Installed new DLL c:\msys\1.0\local\bin\portmidi.dll So the DLL's did install. I'm sorry I keep bothering you guys with questions, but once it works, I won't bother you! -Tyler On Thu, Apr 23, 2009 at 5:58 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: Hi Tyler, I assume you checked out a clean copy of Pygame rather than update the 1.8 checkout. If you had edited msys_build_deps.py then it will not be properly updated. Other than that try to clean up freetype and rebuild: python msys_build_deps.py --clean-only freetype python msys_build_deps.py freetype font I added font (SDL_ttf) to the build list to make sure is built, since it depends on freetype. Lenard Tyler Laing wrote: Okay, with the new compile, everything works... except for Freetype. Again. It appears that the dll is not being compiled as it should be. Here's the error message: -- for P in /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/freetype.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbbox.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbdf.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbitmap.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftcache.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftchapters.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftcid.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fterrdef.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fterrors.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgasp.h
Re: beginning GSOC preparations: was Re: [pygame] Thank You
And it works! Thank you very much Lenard and Rene for all your help. Now, as to the tests. On my linux desktop, five of the tests failed because its a 64bit platform, and the asserts are assuming a 32 bit integer. The other two tests failed because of a library that has a slightly different api to what they expected. As for the windows platform, the only errors arose when subprocess timed out several times, which is to be expected on a VM. Again, thank both of you very much, and I look forward to contributing to the community. :) -Tyler On Fri, Apr 24, 2009 at 9:53 AM, Lenard Lindstrom le...@telus.net wrote: Did you do python config.py first? This takes Setup.in and creates a new Setup file used by setup.py. When running config.py specify 'y' to msys build. It will tell you if it finds the files or not. Why there is a separate config step is because dependencies may be provided in several ways. If config.py does not provide an 'msys' option then set environment variable MINGW_ROOT_DIRECTORY to the MinGW root directory (eg C:\MinGW) and LOCALBASE to C:\msys\1.0\local . Lenard Tyler Laing wrote: So that worked, thank you Lenard. All of them compiled. I'm now getting this error: $ /c/Python25/python.exe setup.py build --compiler=mingw32 WARNING, DLL for smpeg library not found. WARNING, DLL for tiff library not found. WARNING, DLL for SDL_ttf library not found. WARNING, DLL for SDL_image library not found. WARNING, DLL for vorbisfile library not found. WARNING, DLL for jpeg library not found. WARNING, DLL for vorbis library not found. WARNING, DLL for SDL library not found. WARNING, DLL for portmidi library not found. WARNING, DLL for SDL_mixer library not found. WARNING, DLL for ogg library not found. WARNING, DLL for z library not found. WARNING, DLL for png library not found. running build running build_py running build_ext Traceback (most recent call last): File setup.py, line 459, in module setup(**PACKAGEDATA) File C:\Python25\lib\distutils\core.py, line 151, in setup dist.run_commands() File C:\Python25\lib\distutils\dist.py, line 974, in run_commands self.run_command(cmd) File C:\Python25\lib\distutils\dist.py, line 994, in run_command cmd_obj.run() File C:\Python25\lib\distutils\command\build.py, line 112, in run self.run_command(cmd_name) File C:\Python25\lib\distutils\cmd.py, line 333, in run_command self.distribution.run_command(command) File C:\Python25\lib\distutils\dist.py, line 994, in run_command cmd_obj.run() File setup.py, line 324, in run sys.version_info[:2]) RuntimeError: The dependencies are linked to the wrong C runtime for Python 2.5 But beforehand, we had this: SDL : Installed new DLL c:\msys\1.0\local\bin\SDL.dll Z : Installed new DLL c:\msys\1.0\local\bin\zlib1.dll FREETYPE : Installed new DLL c:\msys\1.0\local\bin\libfreetype-6.dll FONT : Installed new DLL c:\msys\1.0\local\bin\SDL_ttf.dll PNG : Installed new DLL c:\msys\1.0\local\bin\libpng12-0.dll JPEG : Installed new DLL c:\msys\1.0\local\bin\jpeg.dll TIFF : Installed new DLL c:\msys\1.0\local\bin\libtiff.dll IMAGE : Installed new DLL c:\msys\1.0\local\bin\SDL_image.dll SMPEG : Installed new DLL c:\msys\1.0\local\bin\smpeg.dll OGG : Installed new DLL c:\msys\1.0\local\bin\libogg-0.dll VORBIS: Installed new DLL c:\msys\1.0\local\bin\libvorbis-0.dll VORBIS: Installed new DLL c:\msys\1.0\local\bin\libvorbisfile-3.dll MIXER : Installed new DLL c:\msys\1.0\local\bin\SDL_mixer.dll PORTMIDI : Installed new DLL c:\msys\1.0\local\bin\portmidi.dll So the DLL's did install. I'm sorry I keep bothering you guys with questions, but once it works, I won't bother you! -Tyler On Thu, Apr 23, 2009 at 5:58 PM, Lenard Lindstrom le...@telus.netmailto: le...@telus.net wrote: Hi Tyler, I assume you checked out a clean copy of Pygame rather than update the 1.8 checkout. If you had edited msys_build_deps.py then it will not be properly updated. Other than that try to clean up freetype and rebuild: python msys_build_deps.py --clean-only freetype python msys_build_deps.py freetype font I added font (SDL_ttf) to the build list to make sure is built, since it depends on freetype. Lenard Tyler Laing wrote: Okay, with the new compile, everything works... except for Freetype. Again. It appears that the dll is not being compiled as it should be. Here's the error message: -- for P in /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/freetype.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbbox.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbdf.h
Re: beginning GSOC preparations: was Re: [pygame] Thank You
On Sat, Apr 25, 2009 at 3:26 AM, Tyler Laing trinio...@gmail.com wrote: And it works! Thank you very much Lenard and Rene for all your help. Now, as to the tests. On my linux desktop, five of the tests failed because its a 64bit platform, and the asserts are assuming a 32 bit integer. The other two tests failed because of a library that has a slightly different api to what they expected. Can you please paste those errors? We currently don't have a 64bit build bot... so we've missed them. As for the windows platform, the only errors arose when subprocess timed out several times, which is to be expected on a VM. ah, cool. There's an option for run_tests.py for that. To see all the test runners options: python run_tests.py --help To timeout after 20 seconds... python run_tests.py -t 20 cu. Again, thank both of you very much, and I look forward to contributing to the community. :) -Tyler
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Sure! Here they are: import pygame.tests.go loading pygame.tests.base_test loading pygame.tests.blit_test loading pygame.tests.bufferproxy_test loading pygame.tests.cdrom_test loading pygame.tests.color_test loading pygame.tests.cursors_test loading pygame.tests.display_test loading pygame.tests.draw_test loading pygame.tests.event_test loading pygame.tests.fastevent_test loading pygame.tests.font_test loading pygame.tests.image__save_gl_surface_test loading pygame.tests.image_test loading pygame.tests.joystick_test loading pygame.tests.key_test loading pygame.tests.mask_test loading pygame.tests.mixer_music_test *** glibc detected *** /usr/bin/python: free(): invalid next size (normal): 0x01e8ba40 *** === Backtrace: = /lib/libc.so.6[0x7f7086b9aa58] /lib/libc.so.6(cfree+0x76)[0x7f7086b9d0a6] /usr/lib/libsmpeg-0.4.so.0(_ZN10MPEGsystem9TotalTimeEv+0x1d1)[0x7f7080d9e871] /usr/lib/libsmpeg-0.4.so.0(_ZN4MPEG13GetSystemInfoEP15MPEG_SystemInfo+0x38)[0x7f7080d9a498] /usr/lib/libsmpeg-0.4.so.0(SMPEG_getinfo+0x68)[0x7f7080d9fe48] /usr/lib/libsmpeg-0.4.so.0(SMPEG_new+0x61)[0x7f7080da0151] /usr/lib/libSDL_mixer-1.2.so.0(Mix_LoadMUS+0x4bb)[0x7f708145085b] /usr/lib/python2.5/site-packages/pygame/mixer_music.so[0x7f708169fc96] /usr/bin/python(PyEval_EvalFrameEx+0x57e2)[0x491052] /usr/bin/python(PyEval_EvalFrameEx+0x6872)[0x4920e2] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python[0x4dd5b9] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python(PyEval_EvalFrameEx+0x40b7)[0x48f927] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python[0x4dd4c2] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python[0x41fb08] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python[0x46615c] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python(PyEval_EvalFrameEx+0x3d12)[0x48f582] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python[0x4dd5b9] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python(PyEval_EvalFrameEx+0x40b7)[0x48f927] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python[0x4dd4c2] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python[0x41fb08] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python[0x46615c] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python(PyEval_EvalFrameEx+0x3d12)[0x48f582] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python[0x4dd5b9] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python(PyEval_EvalFrameEx+0x40b7)[0x48f927] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python[0x4dd4c2] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python[0x41fb08] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python[0x46615c] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python(PyEval_EvalFrameEx+0x3d12)[0x48f582] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python[0x4dd5b9] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python(PyEval_EvalFrameEx+0x40b7)[0x48f927] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python[0x4dd4c2] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python[0x41fb08] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python[0x46615c] /usr/bin/python(PyObject_Call+0x13)[0x418c33] /usr/bin/python(PyEval_EvalFrameEx+0x3d12)[0x48f582] /usr/bin/python(PyEval_EvalFrameEx+0x6872)[0x4920e2] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python(PyEval_EvalFrameEx+0x5483)[0x490cf3] /usr/bin/python(PyEval_EvalCodeEx+0x6ad)[0x4927cd] /usr/bin/python(PyEval_EvalCode+0x32)[0x4929c2] === Memory map: 0040-00525000 r-xp 08:01 278565 /usr/bin/python2.5 00724000-00725000 r--p 00124000 08:01 278565 /usr/bin/python2.5 00725000-00757000 rw-p 00125000 08:01 278565 /usr/bin/python2.5 00757000-0075f000 rw-p 00757000 00:00 0 016d-01e93000 rw-p 016d 00:00 0 [heap] 405a6000-405a7000 ---p 405a6000 00:00 0 405a7000-40da7000 rwxp 405a7000 00:00 0 415d-415d1000 ---p 415d 00:00 0 415d1000-41dd1000 rwxp 415d1000 00:00 0 7f70784fb000-7f70786fc000 rw-s 00:15 135264 /dev/shm/pulse-shm-2421610446 7f70786fc000-7f70786ff000 r-xp 08:01 2187305 /lib/libcap.so.1.10 7f70786ff000-7f70788ff000 ---p 3000 08:01 2187305 /lib/libcap.so.1.10 7f70788ff000-7f707890 rw-p 3000 08:01 2187305 /lib/libcap.so.1.10 7f707890-7f7078917000 r-xp 08:01 1557770 /usr/lib/libICE.so.6.3.0 7f7078917000-7f7078b16000 ---p 00017000 08:01 1557770 /usr/lib/libICE.so.6.3.0 7f7078b16000-7f7078b18000 rw-p 00016000 08:01 1557770 /usr/lib/libICE.so.6.3.0 7f7078b18000-7f7078b1b000 rw-p 7f7078b18000 00:00 0 7f7078b1b000-7f7078b23000 r-xp 08:01 1558608 /usr/lib/libSM.so.6.0.0 7f7078b23000-7f7078d22000 ---p 8000 08:01 1558608 /usr/lib/libSM.so.6.0.0 7f7078d22000-7f7078d23000 r--p 7000 08:01 1558608 /usr/lib/libSM.so.6.0.0 7f7078d23000-7f7078d24000 rw-p 8000 08:01 1558608 /usr/lib/libSM.so.6.0.0
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Okay, with the new compile, everything works... except for Freetype. Again. It appears that the dll is not being compiled as it should be. Here's the error message: -- for P in /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/freetype.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbbox.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbdf.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbitmap.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftcache.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftchapters.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftcid.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fterrdef.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fterrors.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgasp.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftglyph.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgxval.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgzip.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftimage.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftincrem.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftlcdfil.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftlist.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftlzw.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftmac.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftmm.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftmodapi.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftmoderr.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftotval.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftoutln.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftpfr.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftrender.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftsizes.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftsnames.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftstroke.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftsynth.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftsystem.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fttrigon.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fttypes.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftwinfnt.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftxf86.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/t1tables.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ttnameid.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/tttables.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/tttags.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ttunpat.h ; do \ /mingw/bin/install -c -m 644\ $P /usr/local/include/freetype2/freetype ; \ done for P in /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftconfig.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftheader.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftmodule.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftoption.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftstdlib.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/objs/ftmodule.h ; do \ /mingw/bin/install -c -m 644 \ $P /usr/local/include/freetype2/freetype/config ; \ done rm -f /usr/local/include/freetype2/freetype/cache/* rmdir /usr/local/include/freetype2/freetype/cache rm -f /usr/local/include/freetype2/freetype/internal/* rmdir /usr/local/include/freetype2/freetype/internal rmdir: /usr/local/include/freetype2/freetype/internal: No such file or directory make: [install] Error 1 (ignored)
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Hi Tyler, I assume you checked out a clean copy of Pygame rather than update the 1.8 checkout. If you had edited msys_build_deps.py then it will not be properly updated. Other than that try to clean up freetype and rebuild: python msys_build_deps.py --clean-only freetype python msys_build_deps.py freetype font I added font (SDL_ttf) to the build list to make sure is built, since it depends on freetype. Lenard Tyler Laing wrote: Okay, with the new compile, everything works... except for Freetype. Again. It appears that the dll is not being compiled as it should be. Here's the error message: -- for P in /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/freetype.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbbox.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbdf.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbitmap.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftcache.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftchapters.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftcid.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fterrdef.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fterrors.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgasp.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftglyph.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgxval.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgzip.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftimage.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftincrem.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftlcdfil.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftlist.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftlzw.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftmac.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftmm.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftmodapi.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftmoderr.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftotval.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftoutln.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftpfr.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftrender.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftsizes.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftsnames.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftstroke.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftsynth.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftsystem.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fttrigon.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fttypes.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftwinfnt.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftxf86.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/t1tables.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ttnameid.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/tttables.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/tttags.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ttunpat.h ; do \ /mingw/bin/install -c -m 644\ $P /usr/local/include/freetype2/freetype ; \ done for P in /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftconfig.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftheader.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftmodule.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftoption.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/config/ftstdlib.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/objs/ftmodule.h ; do
Re: beginning GSOC preparations: was Re: [pygame] Thank You
So that worked, thank you Lenard. All of them compiled. I'm now getting this error: $ /c/Python25/python.exe setup.py build --compiler=mingw32 WARNING, DLL for smpeg library not found. WARNING, DLL for tiff library not found. WARNING, DLL for SDL_ttf library not found. WARNING, DLL for SDL_image library not found. WARNING, DLL for vorbisfile library not found. WARNING, DLL for jpeg library not found. WARNING, DLL for vorbis library not found. WARNING, DLL for SDL library not found. WARNING, DLL for portmidi library not found. WARNING, DLL for SDL_mixer library not found. WARNING, DLL for ogg library not found. WARNING, DLL for z library not found. WARNING, DLL for png library not found. running build running build_py running build_ext Traceback (most recent call last): File setup.py, line 459, in module setup(**PACKAGEDATA) File C:\Python25\lib\distutils\core.py, line 151, in setup dist.run_commands() File C:\Python25\lib\distutils\dist.py, line 974, in run_commands self.run_command(cmd) File C:\Python25\lib\distutils\dist.py, line 994, in run_command cmd_obj.run() File C:\Python25\lib\distutils\command\build.py, line 112, in run self.run_command(cmd_name) File C:\Python25\lib\distutils\cmd.py, line 333, in run_command self.distribution.run_command(command) File C:\Python25\lib\distutils\dist.py, line 994, in run_command cmd_obj.run() File setup.py, line 324, in run sys.version_info[:2]) RuntimeError: The dependencies are linked to the wrong C runtime for Python 2.5 But beforehand, we had this: SDL : Installed new DLL c:\msys\1.0\local\bin\SDL.dll Z : Installed new DLL c:\msys\1.0\local\bin\zlib1.dll FREETYPE : Installed new DLL c:\msys\1.0\local\bin\libfreetype-6.dll FONT : Installed new DLL c:\msys\1.0\local\bin\SDL_ttf.dll PNG : Installed new DLL c:\msys\1.0\local\bin\libpng12-0.dll JPEG : Installed new DLL c:\msys\1.0\local\bin\jpeg.dll TIFF : Installed new DLL c:\msys\1.0\local\bin\libtiff.dll IMAGE : Installed new DLL c:\msys\1.0\local\bin\SDL_image.dll SMPEG : Installed new DLL c:\msys\1.0\local\bin\smpeg.dll OGG : Installed new DLL c:\msys\1.0\local\bin\libogg-0.dll VORBIS: Installed new DLL c:\msys\1.0\local\bin\libvorbis-0.dll VORBIS: Installed new DLL c:\msys\1.0\local\bin\libvorbisfile-3.dll MIXER : Installed new DLL c:\msys\1.0\local\bin\SDL_mixer.dll PORTMIDI : Installed new DLL c:\msys\1.0\local\bin\portmidi.dll So the DLL's did install. I'm sorry I keep bothering you guys with questions, but once it works, I won't bother you! -Tyler On Thu, Apr 23, 2009 at 5:58 PM, Lenard Lindstrom le...@telus.net wrote: Hi Tyler, I assume you checked out a clean copy of Pygame rather than update the 1.8 checkout. If you had edited msys_build_deps.py then it will not be properly updated. Other than that try to clean up freetype and rebuild: python msys_build_deps.py --clean-only freetype python msys_build_deps.py freetype font I added font (SDL_ttf) to the build list to make sure is built, since it depends on freetype. Lenard Tyler Laing wrote: Okay, with the new compile, everything works... except for Freetype. Again. It appears that the dll is not being compiled as it should be. Here's the error message: -- for P in /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/freetype.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbbox.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbdf.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftbitmap.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftcache.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftchapters.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftcid.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fterrdef.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/fterrors.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgasp.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftglyph.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgxval.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftgzip.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftimage.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftincrem.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftlcdfil.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftlist.h /c/pygame/pygame_mingw32_compile_pack/PyGame/freetype-2.3.7/include/freetype/ftlzw.h
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Rene, Okay, I am able to compile pygame on my linux desktop, and I've run into some issues with compiling for the windows guest vm I have. I already had my own blog, which I've made a relevant post on(as you can see from the posts to here and to soc2009-general). I've also added my blog to the relevant pygame page. I have plenty of experience with svn, so thats not an issue. My issue with compiling pygame is an error I'm getting from msys, for which I've included a screenshot. I used the msys automatic installer, and the mingw automatic installer, but those don't seem to be an issue. The error says that it Couldn't reserve space for cygwin's heap, Win32 error 6 when sh.exe was executed. -Tyler On Tue, Apr 21, 2009 at 8:50 PM, René Dudfield ren...@gmail.com wrote: Hi Tyler, I'm going to be your main mentor, with Marcus, and Nirav being backup/co-mentors. To start preparing for your work, here's a few things you can do... - make sure you can compile pygame. - see the wiki for instructions for your platform(s) - http://pygame.org/wiki/Compilation - as pygame is multi platform, you'll have to work on multiplatforms too. - prepare a separate platform to work on if you can. Like setting up linux if you don't have it already. - not entirely necessary, but it'd make things easier for yourself. - set up your blog, which you'll be writing about your project as you go. - mark related posts with tags pygame, python, gsoc2009 - add your blog to this wiki page: - http://www.pygame.org/wiki/rsslinks - email the pygame mailing list about your blog (once you have at least one related post). - email the soc2009-general with your blog details, and ask them to list your blog on soc.python.org. - if you don't have a blog already, you can set up a free one with blogspot.com or wordpress.com. - prepare a reading list. - start looking at some related materials to read. - like for ffmpeg, read through some of the development mailing list, and development docs etc. - if you haven't used svn before much, read some of the svn book. - svn commit access. - I'll have this arranged. - first, post a patch to some small change to the mailing list, with svn diff your-patch.diff cheers, On Tue, Apr 21, 2009 at 11:46 PM, Tyler Laing trinio...@gmail.com wrote: I just wanted to thank everyone that worked on helping me and others with our applications, and I also wanted to thank all the people that worked hard on approving the applications. Your efforts are appreciated. :) On that note, I was wondering who would be my mentor, for my project? -Tyler Laing -- Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog attachment: msys2.png
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Not python under cygwin. Thats a leftover string from msys using cygwin code. The command I was trying to execute was python msys_build_deps.py --all Python is installed. Msys is installed, but throwing that error. And no worries. I just wasn't clear enough. :) -Tyler On Wed, Apr 22, 2009 at 10:24 AM, Evan Kroske e.kro...@gmail.com wrote: Tyler Laing wrote: snip / The error says that it Couldn't reserve space for cygwin's heap, Win32 error 6 when sh.exe was executed. Why are you trying to install Python under CygWin? From what I understand, most programmers consider that a separate platform from Windows. You should probably try to install the native windows version, instead of the linux version running under cygwin. Sorry if I misunderstood you. Regards, Evan Kroske -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Tyler Laing wrote: snip / The error says that it Couldn't reserve space for cygwin's heap, Win32 error 6 when sh.exe was executed. Why are you trying to install Python under CygWin? From what I understand, most programmers consider that a separate platform from Windows. You should probably try to install the native windows version, instead of the linux version running under cygwin. Sorry if I misunderstood you. Regards, Evan Kroske
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before. I run the program on both Win 98 and XP. If you are using Msys 1.0.10 try upgrading to 1.0.11. I only user 1.0.10 because 1.0.11 doesn't work on Win 98 and I have limited access to XP. Msys 1.0.11 will be needed to build ffmpeg anyway, since the bash shell in 1.0.10 is apparently too old for the ffmpeg configure script. If you continue having problems then just use the prebuilt dependencies for now: http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr71-win32.zip (for Python 2.4-2.5) (md5sum 0c9b5c65dbd10b5469d2523cf58b7890) http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr90-win32.zip (for Python 2.6-3.x) (md5sum 8dcd7e7c840d656c3ca7576095777c81) Install the prebuilt directory into the Pygame root directory, run config.py and answer 'n' to msys built, 'y' to use prebuilts. I suppose now I must really try to get ffmpeg built. Lenard Tyler Laing wrote: Not python under cygwin. Thats a leftover string from msys using cygwin code. The command I was trying to execute was python msys_build_deps.py --all Python is installed. Msys is installed, but throwing that error. And no worries. I just wasn't clear enough. :) -Tyler On Wed, Apr 22, 2009 at 10:24 AM, Evan Kroske e.kro...@gmail.com mailto:e.kro...@gmail.com wrote: Tyler Laing wrote: snip / The error says that it Couldn't reserve space for cygwin's heap, Win32 error 6 when sh.exe was executed. Why are you trying to install Python under CygWin? From what I understand, most programmers consider that a separate platform from Windows. You should probably try to install the native windows version, instead of the linux version running under cygwin. Sorry if I misunderstood you.
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory Any idea whats going on here? On Wed, Apr 22, 2009 at 11:18 AM, Lenard Lindstrom le...@telus.net wrote: Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before. I run the program on both Win 98 and XP. If you are using Msys 1.0.10 try upgrading to 1.0.11. I only user 1.0.10 because 1.0.11 doesn't work on Win 98 and I have limited access to XP. Msys 1.0.11 will be needed to build ffmpeg anyway, since the bash shell in 1.0.10 is apparently too old for the ffmpeg configure script. If you continue having problems then just use the prebuilt dependencies for now: http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr71-win32.zip (for Python 2.4-2.5) (md5sum 0c9b5c65dbd10b5469d2523cf58b7890) http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr90-win32.zip (for Python 2.6-3.x) (md5sum 8dcd7e7c840d656c3ca7576095777c81) Install the prebuilt directory into the Pygame root directory, run config.py and answer 'n' to msys built, 'y' to use prebuilts. I suppose now I must really try to get ffmpeg built. Lenard Tyler Laing wrote: Not python under cygwin. Thats a leftover string from msys using cygwin code. The command I was trying to execute was python msys_build_deps.py --all Python is installed. Msys is installed, but throwing that error. And no worries. I just wasn't clear enough. :) -Tyler On Wed, Apr 22, 2009 at 10:24 AM, Evan Kroske e.kro...@gmail.commailto: e.kro...@gmail.com wrote: Tyler Laing wrote: snip / The error says that it Couldn't reserve space for cygwin's heap, Win32 error 6 when sh.exe was executed. Why are you trying to install Python under CygWin? From what I understand, most programmers consider that a separate platform from Windows. You should probably try to install the native windows version, instead of the linux version running under cygwin. Sorry if I misunderstood you. -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Which package are you trying to build. Unless the thing crashed completely msys_build_deps.py should have displayed a listing at the end showing where it stalled, that is, it will show which DLL were not installed. The packages taken straight form SVN may not have a .configure file. msys_build_deps.py will create those automatically for SDL, SDL_mixer and smpeg. If any other packages were taken from SVN then it will fail. To manually create a configure file start the Msys console, go into the package's root directory and type './autogen.sh'. Anyway, the general Unix steps msys_build_deps.py takes to installing a package are: ./autogen.sh # only for SVN packages ./configure make make install strip /usr/local/bin/lib-name.DLL The msys shell scripts run to build the packages are found at the end of msys_build_deps.py Lenard Tyler Laing wrote: Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory Any idea whats going on here? On Wed, Apr 22, 2009 at 11:18 AM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before. I run the program on both Win 98 and XP. If you are using Msys 1.0.10 try upgrading to 1.0.11. I only user 1.0.10 because 1.0.11 doesn't work on Win 98 and I have limited access to XP. Msys 1.0.11 will be needed to build ffmpeg anyway, since the bash shell in 1.0.10 is apparently too old for the ffmpeg configure script. If you continue having problems then just use the prebuilt dependencies for now: http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr71-win32.zip (for Python 2.4-2.5) (md5sum 0c9b5c65dbd10b5469d2523cf58b7890) http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr90-win32.zip (for Python 2.6-3.x) (md5sum 8dcd7e7c840d656c3ca7576095777c81) Install the prebuilt directory into the Pygame root directory, run config.py and answer 'n' to msys built, 'y' to use prebuilts. I suppose now I must really try to get ffmpeg built. Lenard Tyler Laing wrote: Not python under cygwin. Thats a leftover string from msys using cygwin code. The command I was trying to execute was python msys_build_deps.py --all Python is installed. Msys is installed, but throwing that error. And no worries. I just wasn't clear enough. :) -Tyler On Wed, Apr 22, 2009 at 10:24 AM, Evan Kroske e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com wrote: Tyler Laing wrote: snip / The error says that it Couldn't reserve space for cygwin's heap, Win32 error 6 when sh.exe was executed. Why are you trying to install Python under CygWin? From what I understand, most programmers consider that a separate platform from Windows. You should probably try to install the native windows version, instead of the linux version running under cygwin. Sorry if I misunderstood you.
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should be... including the update automake, autoconf and m4 tars. $ ./autogen.sh Generating build information using autoconf This may take a while ... Can't locate object method path via package Request (perhaps you forgot to load Request?) at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. Couldn't find autoconf, aborting On Wed, Apr 22, 2009 at 1:44 PM, Lenard Lindstrom le...@telus.net wrote: Which package are you trying to build. Unless the thing crashed completely msys_build_deps.py should have displayed a listing at the end showing where it stalled, that is, it will show which DLL were not installed. The packages taken straight form SVN may not have a .configure file. msys_build_deps.py will create those automatically for SDL, SDL_mixer and smpeg. If any other packages were taken from SVN then it will fail. To manually create a configure file start the Msys console, go into the package's root directory and type './autogen.sh'. Anyway, the general Unix steps msys_build_deps.py takes to installing a package are: ./autogen.sh # only for SVN packages ./configure make make install strip /usr/local/bin/lib-name.DLL The msys shell scripts run to build the packages are found at the end of msys_build_deps.py Lenard Tyler Laing wrote: Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory Any idea whats going on here? On Wed, Apr 22, 2009 at 11:18 AM, Lenard Lindstrom le...@telus.netmailto: le...@telus.net wrote: Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before. I run the program on both Win 98 and XP. If you are using Msys 1.0.10 try upgrading to 1.0.11. I only user 1.0.10 because 1.0.11 doesn't work on Win 98 and I have limited access to XP. Msys 1.0.11 will be needed to build ffmpeg anyway, since the bash shell in 1.0.10 is apparently too old for the ffmpeg configure script. If you continue having problems then just use the prebuilt dependencies for now: http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr71-win32.zip (for Python 2.4-2.5) (md5sum 0c9b5c65dbd10b5469d2523cf58b7890) http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr90-win32.zip (for Python 2.6-3.x) (md5sum 8dcd7e7c840d656c3ca7576095777c81) Install the prebuilt directory into the Pygame root directory, run config.py and answer 'n' to msys built, 'y' to use prebuilts. I suppose now I must really try to get ffmpeg built. Lenard Tyler Laing wrote: Not python under cygwin. Thats a leftover string from msys using cygwin code. The command I was trying to execute was python msys_build_deps.py --all Python is installed. Msys is installed, but throwing that error. And no worries. I just wasn't clear enough. :) -Tyler On Wed, Apr 22, 2009 at 10:24 AM, Evan Kroske e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com wrote: Tyler Laing wrote: snip / The error says that it Couldn't reserve space for cygwin's heap, Win32 error 6 when sh.exe was executed. Why are you trying to install Python under CygWin? From what I understand, most programmers consider that a separate platform from Windows. You should probably try to install the native windows version, instead of the linux version running under cygwin. Sorry if I misunderstood you. -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Did you install the Msys autoconf, automake and m4 packages from sourceforge? They are found under the MSYS Supplementary section of the MinGW download page. I suggest using the most recent versions available. Lenard Tyler Laing wrote: Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should be... including the update automake, autoconf and m4 tars. $ ./autogen.sh Generating build information using autoconf This may take a while ... Can't locate object method path via package Request (perhaps you forgot to load Request?) at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. Couldn't find autoconf, aborting On Wed, Apr 22, 2009 at 1:44 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: Which package are you trying to build. Unless the thing crashed completely msys_build_deps.py should have displayed a listing at the end showing where it stalled, that is, it will show which DLL were not installed. The packages taken straight form SVN may not have a .configure file. msys_build_deps.py will create those automatically for SDL, SDL_mixer and smpeg. If any other packages were taken from SVN then it will fail. To manually create a configure file start the Msys console, go into the package's root directory and type './autogen.sh'. Anyway, the general Unix steps msys_build_deps.py takes to installing a package are: ./autogen.sh # only for SVN packages ./configure make make install strip /usr/local/bin/lib-name.DLL The msys shell scripts run to build the packages are found at the end of msys_build_deps.py Lenard Tyler Laing wrote: Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory Any idea whats going on here? On Wed, Apr 22, 2009 at 11:18 AM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net mailto:le...@telus.net mailto:le...@telus.net wrote: Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before. I run the program on both Win 98 and XP. If you are using Msys 1.0.10 try upgrading to 1.0.11. I only user 1.0.10 because 1.0.11 doesn't work on Win 98 and I have limited access to XP. Msys 1.0.11 will be needed to build ffmpeg anyway, since the bash shell in 1.0.10 is apparently too old for the ffmpeg configure script. If you continue having problems then just use the prebuilt dependencies for now: http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr71-win32.zip (for Python 2.4-2.5) (md5sum 0c9b5c65dbd10b5469d2523cf58b7890) http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr90-win32.zip (for Python 2.6-3.x) (md5sum 8dcd7e7c840d656c3ca7576095777c81) Install the prebuilt directory into the Pygame root directory, run config.py and answer 'n' to msys built, 'y' to use prebuilts. I suppose now I must really try to get ffmpeg built. Lenard Tyler Laing wrote: Not python under cygwin. Thats a leftover string from msys using cygwin code. The command I was trying to execute was python msys_build_deps.py --all Python is installed. Msys is installed, but throwing that error. And no worries. I just wasn't clear enough. :) -Tyler On Wed, Apr 22, 2009 at 10:24 AM, Evan Kroske e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com wrote: Tyler Laing wrote: snip / The error says that it Couldn't reserve space for cygwin's heap, Win32 error 6 when sh.exe was executed. Why are you trying to install Python under CygWin? From what I understand, most programmers consider that a separate platform from Windows. You should probably try to install the native windows version, instead of the linux version running under cygwin. Sorry if I misunderstood you. -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Unfortunately, it doesn't work. Does anyone have a better guide or series of steps to compiling pygame? Those steps should include properly install msys and associated packages. If not, I'll go over and start using the prebuilts. Thanks for the effort Lenard. -Tyler On Wed, Apr 22, 2009 at 2:55 PM, Lenard Lindstrom le...@telus.net wrote: Did you install the Msys autoconf, automake and m4 packages from sourceforge? They are found under the MSYS Supplementary section of the MinGW download page. I suggest using the most recent versions available. Lenard Tyler Laing wrote: Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should be... including the update automake, autoconf and m4 tars. $ ./autogen.sh Generating build information using autoconf This may take a while ... Can't locate object method path via package Request (perhaps you forgot to load Request?) at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. Couldn't find autoconf, aborting On Wed, Apr 22, 2009 at 1:44 PM, Lenard Lindstrom le...@telus.netmailto: le...@telus.net wrote: Which package are you trying to build. Unless the thing crashed completely msys_build_deps.py should have displayed a listing at the end showing where it stalled, that is, it will show which DLL were not installed. The packages taken straight form SVN may not have a .configure file. msys_build_deps.py will create those automatically for SDL, SDL_mixer and smpeg. If any other packages were taken from SVN then it will fail. To manually create a configure file start the Msys console, go into the package's root directory and type './autogen.sh'. Anyway, the general Unix steps msys_build_deps.py takes to installing a package are: ./autogen.sh # only for SVN packages ./configure make make install strip /usr/local/bin/lib-name.DLL The msys shell scripts run to build the packages are found at the end of msys_build_deps.py Lenard Tyler Laing wrote: Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory Any idea whats going on here? On Wed, Apr 22, 2009 at 11:18 AM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net mailto:le...@telus.net mailto:le...@telus.net wrote: Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before. I run the program on both Win 98 and XP. If you are using Msys 1.0.10 try upgrading to 1.0.11. I only user 1.0.10 because 1.0.11 doesn't work on Win 98 and I have limited access to XP. Msys 1.0.11 will be needed to build ffmpeg anyway, since the bash shell in 1.0.10 is apparently too old for the ffmpeg configure script. If you continue having problems then just use the prebuilt dependencies for now: http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr71-win32.zip (for Python 2.4-2.5) (md5sum 0c9b5c65dbd10b5469d2523cf58b7890) http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr90-win32.zip (for Python 2.6-3.x) (md5sum 8dcd7e7c840d656c3ca7576095777c81) Install the prebuilt directory into the Pygame root directory, run config.py and answer 'n' to msys built, 'y' to use prebuilts. I suppose now I must really try to get ffmpeg built. Lenard Tyler Laing wrote: Not python under cygwin. Thats a leftover string from msys using cygwin code. The command I was trying to execute was python msys_build_deps.py --all Python is installed. Msys is installed, but throwing that error. And no worries. I just wasn't clear enough. :) -Tyler On Wed, Apr 22, 2009 at 10:24 AM, Evan Kroske e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com wrote: Tyler Laing wrote: snip / The error says that it Couldn't reserve space for cygwin's heap, Win32 error 6 when sh.exe was executed. Why are you trying to install Python under CygWin? From what I understand, most programmers consider that a separate platform from Windows. You should probably try to install the native windows version, instead of the linux
Re: beginning GSOC preparations: was Re: [pygame] Thank You
hi, try this: http://rene.f0o.com/~rene/pygame_mingw32_compile_pack.zip They are the installers for mingw stuff I last installed on my windows machine to compile pygame. Other people have used those to successfully compile it too... so it should work. Also, if you get the dependency sources that Lenard collected on his page in one bundle: http://www3.telus.net/len_l/pygame/Pygame-1.9.0-deps-src.zip I think the directory structure matters too: # directory with all the source deps in it: pygame/ # the trunk is here: pygame/PyGame/ cu, On Thu, Apr 23, 2009 at 8:39 AM, Tyler Laing trinio...@gmail.com wrote: Unfortunately, it doesn't work. Does anyone have a better guide or series of steps to compiling pygame? Those steps should include properly install msys and associated packages. If not, I'll go over and start using the prebuilts. Thanks for the effort Lenard. -Tyler On Wed, Apr 22, 2009 at 2:55 PM, Lenard Lindstrom le...@telus.net wrote: Did you install the Msys autoconf, automake and m4 packages from sourceforge? They are found under the MSYS Supplementary section of the MinGW download page. I suggest using the most recent versions available. Lenard Tyler Laing wrote: Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should be... including the update automake, autoconf and m4 tars. $ ./autogen.sh Generating build information using autoconf This may take a while ... Can't locate object method path via package Request (perhaps you forgot to load Request?) at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. Couldn't find autoconf, aborting On Wed, Apr 22, 2009 at 1:44 PM, Lenard Lindstrom le...@telus.netmailto: le...@telus.net wrote: Which package are you trying to build. Unless the thing crashed completely msys_build_deps.py should have displayed a listing at the end showing where it stalled, that is, it will show which DLL were not installed. The packages taken straight form SVN may not have a .configure file. msys_build_deps.py will create those automatically for SDL, SDL_mixer and smpeg. If any other packages were taken from SVN then it will fail. To manually create a configure file start the Msys console, go into the package's root directory and type './autogen.sh'. Anyway, the general Unix steps msys_build_deps.py takes to installing a package are: ./autogen.sh # only for SVN packages ./configure make make install strip /usr/local/bin/lib-name.DLL The msys shell scripts run to build the packages are found at the end of msys_build_deps.py Lenard Tyler Laing wrote: Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory Any idea whats going on here? On Wed, Apr 22, 2009 at 11:18 AM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net mailto:le...@telus.net mailto:le...@telus.net wrote: Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before. I run the program on both Win 98 and XP. If you are using Msys 1.0.10 try upgrading to 1.0.11. I only user 1.0.10 because 1.0.11 doesn't work on Win 98 and I have limited access to XP. Msys 1.0.11 will be needed to build ffmpeg anyway, since the bash shell in 1.0.10 is apparently too old for the ffmpeg configure script. If you continue having problems then just use the prebuilt dependencies for now: http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr71-win32.zip (for Python 2.4-2.5) (md5sum 0c9b5c65dbd10b5469d2523cf58b7890) http://www3.telus.net/len_l/pygame/prebuilt-pygame1.9.0-msvcr90-win32.zip (for Python 2.6-3.x) (md5sum 8dcd7e7c840d656c3ca7576095777c81) Install the prebuilt directory into the Pygame root directory, run config.py and answer 'n' to msys built, 'y' to use prebuilts. I suppose now I must really try to get ffmpeg built. Lenard Tyler Laing wrote: Not python under cygwin. Thats a leftover string from msys using cygwin code. The command I was trying to execute was python msys_build_deps.py --all Python is installed. Msys is installed, but throwing that error. And no worries. I just wasn't clear enough. :) -Tyler On Wed, Apr 22, 2009 at 10:24 AM, Evan Kroske e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com mailto:e.kro...@gmail.com
Re: beginning GSOC preparations: was Re: [pygame] Thank You
I'm sorry if I seem dense throughout all of this, XD. Okay, so I take your package there, unzip it. I copy the pygame source code trunk into there. I then use the windows cmd, and cd into that directory, and run python setup.py --compiler=mingw32 install ? I'm sorry, but you're going to need explicate more steps, and that, because nothing is working for me. Doing the above, after I removed mingw32, and msys, then reinstalled them, then unzipped the msyscore archive in the msys directory to update to 1.0.11, I get this: Hunting dependencies /bin/sh/ : sdl-config: No such directory or file WARNING: sdl-config failed! /bin/shL smpeg-config: No such directory or file WARNING: smpeg-config failed! Normally things work for me, but I'm having a lot of trouble here, because nothing is clear, and Windows has the worst command-line utility around. This is by no means a condemnation of you guys, just that you guys are expecting more out of me, and its just not happening. -Tyler On Wed, Apr 22, 2009 at 4:34 PM, René Dudfield ren...@gmail.com wrote: hi, try this: http://rene.f0o.com/~rene/pygame_mingw32_compile_pack.ziphttp://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip They are the installers for mingw stuff I last installed on my windows machine to compile pygame. Other people have used those to successfully compile it too... so it should work. Also, if you get the dependency sources that Lenard collected on his page in one bundle: http://www3.telus.net/len_l/pygame/Pygame-1.9.0-deps-src.zip I think the directory structure matters too: # directory with all the source deps in it: pygame/ # the trunk is here: pygame/PyGame/ cu, On Thu, Apr 23, 2009 at 8:39 AM, Tyler Laing trinio...@gmail.com wrote: Unfortunately, it doesn't work. Does anyone have a better guide or series of steps to compiling pygame? Those steps should include properly install msys and associated packages. If not, I'll go over and start using the prebuilts. Thanks for the effort Lenard. -Tyler On Wed, Apr 22, 2009 at 2:55 PM, Lenard Lindstrom le...@telus.netwrote: Did you install the Msys autoconf, automake and m4 packages from sourceforge? They are found under the MSYS Supplementary section of the MinGW download page. I suggest using the most recent versions available. Lenard Tyler Laing wrote: Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should be... including the update automake, autoconf and m4 tars. $ ./autogen.sh Generating build information using autoconf This may take a while ... Can't locate object method path via package Request (perhaps you forgot to load Request?) at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. Couldn't find autoconf, aborting On Wed, Apr 22, 2009 at 1:44 PM, Lenard Lindstrom le...@telus.netmailto: le...@telus.net wrote: Which package are you trying to build. Unless the thing crashed completely msys_build_deps.py should have displayed a listing at the end showing where it stalled, that is, it will show which DLL were not installed. The packages taken straight form SVN may not have a .configure file. msys_build_deps.py will create those automatically for SDL, SDL_mixer and smpeg. If any other packages were taken from SVN then it will fail. To manually create a configure file start the Msys console, go into the package's root directory and type './autogen.sh'. Anyway, the general Unix steps msys_build_deps.py takes to installing a package are: ./autogen.sh # only for SVN packages ./configure make make install strip /usr/local/bin/lib-name.DLL The msys shell scripts run to build the packages are found at the end of msys_build_deps.py Lenard Tyler Laing wrote: Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory Any idea whats going on here? On Wed, Apr 22, 2009 at 11:18 AM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net mailto:le...@telus.net mailto:le...@telus.net wrote: Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before. I run the program on both Win 98 and XP. If you are using Msys 1.0.10 try upgrading to 1.0.11. I only user 1.0.10 because 1.0.11 doesn't work on Win 98 and I have limited access to XP. Msys 1.0.11 will be needed to build ffmpeg anyway, since the bash shell in 1.0.10 is apparently too old for the ffmpeg configure script. If you continue having problems then just use the prebuilt dependencies for now:
Re: beginning GSOC preparations: was Re: [pygame] Thank You
hi, try this: python msys_build_deps.py --all then this: python setup.py build --compiler=mingw32 install On Thu, Apr 23, 2009 at 10:18 AM, Tyler Laing trinio...@gmail.com wrote: I'm sorry if I seem dense throughout all of this, XD. Okay, so I take your package there, unzip it. I copy the pygame source code trunk into there. I then use the windows cmd, and cd into that directory, and run python setup.py --compiler=mingw32 install ? I'm sorry, but you're going to need explicate more steps, and that, because nothing is working for me. Doing the above, after I removed mingw32, and msys, then reinstalled them, then unzipped the msyscore archive in the msys directory to update to 1.0.11, I get this: Hunting dependencies /bin/sh/ : sdl-config: No such directory or file WARNING: sdl-config failed! /bin/shL smpeg-config: No such directory or file WARNING: smpeg-config failed! Normally things work for me, but I'm having a lot of trouble here, because nothing is clear, and Windows has the worst command-line utility around. This is by no means a condemnation of you guys, just that you guys are expecting more out of me, and its just not happening. -Tyler On Wed, Apr 22, 2009 at 4:34 PM, René Dudfield ren...@gmail.com wrote: hi, try this: http://rene.f0o.com/~rene/pygame_mingw32_compile_pack.ziphttp://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip They are the installers for mingw stuff I last installed on my windows machine to compile pygame. Other people have used those to successfully compile it too... so it should work. Also, if you get the dependency sources that Lenard collected on his page in one bundle: http://www3.telus.net/len_l/pygame/Pygame-1.9.0-deps-src.zip I think the directory structure matters too: # directory with all the source deps in it: pygame/ # the trunk is here: pygame/PyGame/ cu, On Thu, Apr 23, 2009 at 8:39 AM, Tyler Laing trinio...@gmail.com wrote: Unfortunately, it doesn't work. Does anyone have a better guide or series of steps to compiling pygame? Those steps should include properly install msys and associated packages. If not, I'll go over and start using the prebuilts. Thanks for the effort Lenard. -Tyler On Wed, Apr 22, 2009 at 2:55 PM, Lenard Lindstrom le...@telus.netwrote: Did you install the Msys autoconf, automake and m4 packages from sourceforge? They are found under the MSYS Supplementary section of the MinGW download page. I suggest using the most recent versions available. Lenard Tyler Laing wrote: Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should be... including the update automake, autoconf and m4 tars. $ ./autogen.sh Generating build information using autoconf This may take a while ... Can't locate object method path via package Request (perhaps you forgot to load Request?) at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. Couldn't find autoconf, aborting On Wed, Apr 22, 2009 at 1:44 PM, Lenard Lindstrom le...@telus.netmailto: le...@telus.net wrote: Which package are you trying to build. Unless the thing crashed completely msys_build_deps.py should have displayed a listing at the end showing where it stalled, that is, it will show which DLL were not installed. The packages taken straight form SVN may not have a .configure file. msys_build_deps.py will create those automatically for SDL, SDL_mixer and smpeg. If any other packages were taken from SVN then it will fail. To manually create a configure file start the Msys console, go into the package's root directory and type './autogen.sh'. Anyway, the general Unix steps msys_build_deps.py takes to installing a package are: ./autogen.sh # only for SVN packages ./configure make make install strip /usr/local/bin/lib-name.DLL The msys shell scripts run to build the packages are found at the end of msys_build_deps.py Lenard Tyler Laing wrote: Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory Any idea whats going on here? On Wed, Apr 22, 2009 at 11:18 AM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net mailto:le...@telus.net mailto:le...@telus.net wrote: Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before. I run the program on both Win 98 and XP. If you are using Msys 1.0.10 try upgrading to 1.0.11. I only user 1.0.10 because 1.0.11 doesn't work on Win 98 and I have limited access to XP. Msys 1.0.11 will be needed to build ffmpeg anyway, since the bash shell in 1.0.10 is apparently
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Okay, it compiled both SDL and zlib, but it failed on freetype. Here's the error message: from snip freetype-2.3.7/src/base/ftsysem.c:29: snip../include/stdlib.h:317: error: syntax error before double Right now I'm compiling the rest, so we'll see if there's any other errors. -Tyler On Wed, Apr 22, 2009 at 5:49 PM, René Dudfield ren...@gmail.com wrote: hi, try this: python msys_build_deps.py --all then this: python setup.py build --compiler=mingw32 install On Thu, Apr 23, 2009 at 10:18 AM, Tyler Laing trinio...@gmail.com wrote: I'm sorry if I seem dense throughout all of this, XD. Okay, so I take your package there, unzip it. I copy the pygame source code trunk into there. I then use the windows cmd, and cd into that directory, and run python setup.py --compiler=mingw32 install ? I'm sorry, but you're going to need explicate more steps, and that, because nothing is working for me. Doing the above, after I removed mingw32, and msys, then reinstalled them, then unzipped the msyscore archive in the msys directory to update to 1.0.11, I get this: Hunting dependencies /bin/sh/ : sdl-config: No such directory or file WARNING: sdl-config failed! /bin/shL smpeg-config: No such directory or file WARNING: smpeg-config failed! Normally things work for me, but I'm having a lot of trouble here, because nothing is clear, and Windows has the worst command-line utility around. This is by no means a condemnation of you guys, just that you guys are expecting more out of me, and its just not happening. -Tyler On Wed, Apr 22, 2009 at 4:34 PM, René Dudfield ren...@gmail.com wrote: hi, try this: http://rene.f0o.com/~rene/pygame_mingw32_compile_pack.ziphttp://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip They are the installers for mingw stuff I last installed on my windows machine to compile pygame. Other people have used those to successfully compile it too... so it should work. Also, if you get the dependency sources that Lenard collected on his page in one bundle: http://www3.telus.net/len_l/pygame/Pygame-1.9.0-deps-src.zip I think the directory structure matters too: # directory with all the source deps in it: pygame/ # the trunk is here: pygame/PyGame/ cu, On Thu, Apr 23, 2009 at 8:39 AM, Tyler Laing trinio...@gmail.comwrote: Unfortunately, it doesn't work. Does anyone have a better guide or series of steps to compiling pygame? Those steps should include properly install msys and associated packages. If not, I'll go over and start using the prebuilts. Thanks for the effort Lenard. -Tyler On Wed, Apr 22, 2009 at 2:55 PM, Lenard Lindstrom le...@telus.netwrote: Did you install the Msys autoconf, automake and m4 packages from sourceforge? They are found under the MSYS Supplementary section of the MinGW download page. I suggest using the most recent versions available. Lenard Tyler Laing wrote: Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should be... including the update automake, autoconf and m4 tars. $ ./autogen.sh Generating build information using autoconf This may take a while ... Can't locate object method path via package Request (perhaps you forgot to load Request?) at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. Couldn't find autoconf, aborting On Wed, Apr 22, 2009 at 1:44 PM, Lenard Lindstrom le...@telus.netmailto: le...@telus.net wrote: Which package are you trying to build. Unless the thing crashed completely msys_build_deps.py should have displayed a listing at the end showing where it stalled, that is, it will show which DLL were not installed. The packages taken straight form SVN may not have a .configure file. msys_build_deps.py will create those automatically for SDL, SDL_mixer and smpeg. If any other packages were taken from SVN then it will fail. To manually create a configure file start the Msys console, go into the package's root directory and type './autogen.sh'. Anyway, the general Unix steps msys_build_deps.py takes to installing a package are: ./autogen.sh # only for SVN packages ./configure make make install strip /usr/local/bin/lib-name.DLL The msys shell scripts run to build the packages are found at the end of msys_build_deps.py Lenard Tyler Laing wrote: Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory Any idea whats going on here? On Wed, Apr 22, 2009 at 11:18 AM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net mailto:le...@telus.net mailto:le...@telus.net wrote: Hi Tyler, I wrote msys_build_deps.py and look after the Windows dependencies. I haven't seen this error before.
Re: beginning GSOC preparations: was Re: [pygame] Thank You
You can run everything from the Msys console, which is more Unix like. In Msys a Windows drive letter translates to a top level Msys directory of the same name. So C:\windows\system32 becomes /c/windows/system32. Add the Python root directory to the executable path and everything should work: export PATH=python root path:$PATH The path must be in Msys form. msys_build_deps.py installs everything to /usr/local in the Msys path (msys\1.0\local in Windows). DLLs go into the bin subdirectory. Lenard Tyler Laing wrote: Normally things work for me, but I'm having a lot of trouble here, because nothing is clear, and Windows has the worst command-line utility around. This is by no means a condemnation of you guys, just that you guys are expecting more out of me, and its just not happening. -Tyler On Wed, Apr 22, 2009 at 4:34 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: hi, try this: http://rene.f0o.com/~rene/pygame_mingw32_compile_pack.zip http://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip They are the installers for mingw stuff I last installed on my windows machine to compile pygame. Other people have used those to successfully compile it too... so it should work. Also, if you get the dependency sources that Lenard collected on his page in one bundle: http://www3.telus.net/len_l/pygame/Pygame-1.9.0-deps-src.zip I think the directory structure matters too: # directory with all the source deps in it: pygame/ # the trunk is here: pygame/PyGame/ cu, On Thu, Apr 23, 2009 at 8:39 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com wrote: Unfortunately, it doesn't work. Does anyone have a better guide or series of steps to compiling pygame? Those steps should include properly install msys and associated packages. If not, I'll go over and start using the prebuilts. Thanks for the effort Lenard. -Tyler On Wed, Apr 22, 2009 at 2:55 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: Did you install the Msys autoconf, automake and m4 packages from sourceforge? They are found under the MSYS Supplementary section of the MinGW download page. I suggest using the most recent versions available. Lenard Tyler Laing wrote: Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should be... including the update automake, autoconf and m4 tars. $ ./autogen.sh Generating build information using autoconf This may take a while ... Can't locate object method path via package Request (perhaps you forgot to load Request?) at /usr/share/autoconf/Autom4te/C4che.pm line 69, GEN1 line 111. Couldn't find autoconf, aborting On Wed, Apr 22, 2009 at 1:44 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net mailto:le...@telus.net mailto:le...@telus.net wrote: Which package are you trying to build. Unless the thing crashed completely msys_build_deps.py should have displayed a listing at the end showing where it stalled, that is, it will show which DLL were not installed. The packages taken straight form SVN may not have a .configure file. msys_build_deps.py will create those automatically for SDL, SDL_mixer and smpeg. If any other packages were taken from SVN then it will fail. To manually create a configure file start the Msys console, go into the package's root directory and type './autogen.sh'. Anyway, the general Unix steps msys_build_deps.py takes to installing a package are: ./autogen.sh # only for SVN packages ./configure make make install strip /usr/local/bin/lib-name.DLL The msys shell scripts run to build the packages are found at the end of msys_build_deps.py Lenard Tyler Laing wrote: Okay, thanks! It went past that, but now its getting an error that says: /bin/sh: line 17: ./configure: No such file or directory
Re: beginning GSOC preparations: was Re: [pygame] Thank You
This would be from a patch msys_build_deps.py makes to work around freetypes being built in strict mode, that is, no extensions like 'inline'. The MinGW stdlib.h has an inlined function, causing the compile to fail. I believe René used a different fix from mine. So to disable mine edit msys_build_deps.py and comment out line 549 with a '#': export CPPFLAGS=-Dinline=__inline__ $CPPFLAGS If that fails with some error about 'inline' not recognized then the MinGW header include\stdlib.h will have to be edited on line 317 to replace 'inline' with '__inline__'. By the way, which version of gcc are you using? This gave me no problems with gcc 3.4.5. Lenard Tyler Laing wrote: Okay, it compiled both SDL and zlib, but it failed on freetype. Here's the error message: from snip freetype-2.3.7/src/base/ftsysem.c:29: snip../include/stdlib.h:317: error: syntax error before double Right now I'm compiling the rest, so we'll see if there's any other errors. -Tyler On Wed, Apr 22, 2009 at 5:49 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: hi, try this: python msys_build_deps.py --all then this: python setup.py build --compiler=mingw32 install On Thu, Apr 23, 2009 at 10:18 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com wrote: I'm sorry if I seem dense throughout all of this, XD. Okay, so I take your package there, unzip it. I copy the pygame source code trunk into there. I then use the windows cmd, and cd into that directory, and run python setup.py --compiler=mingw32 install ? I'm sorry, but you're going to need explicate more steps, and that, because nothing is working for me. Doing the above, after I removed mingw32, and msys, then reinstalled them, then unzipped the msyscore archive in the msys directory to update to 1.0.11, I get this: Hunting dependencies /bin/sh/ : sdl-config: No such directory or file WARNING: sdl-config failed! /bin/shL smpeg-config: No such directory or file WARNING: smpeg-config failed! Normally things work for me, but I'm having a lot of trouble here, because nothing is clear, and Windows has the worst command-line utility around. This is by no means a condemnation of you guys, just that you guys are expecting more out of me, and its just not happening. -Tyler On Wed, Apr 22, 2009 at 4:34 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: hi, try this: http://rene.f0o.com/~rene/pygame_mingw32_compile_pack.zip http://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip They are the installers for mingw stuff I last installed on my windows machine to compile pygame. Other people have used those to successfully compile it too... so it should work. Also, if you get the dependency sources that Lenard collected on his page in one bundle: http://www3.telus.net/len_l/pygame/Pygame-1.9.0-deps-src.zip I think the directory structure matters too: # directory with all the source deps in it: pygame/ # the trunk is here: pygame/PyGame/ cu, On Thu, Apr 23, 2009 at 8:39 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com wrote: Unfortunately, it doesn't work. Does anyone have a better guide or series of steps to compiling pygame? Those steps should include properly install msys and associated packages. If not, I'll go over and start using the prebuilts. Thanks for the effort Lenard. -Tyler On Wed, Apr 22, 2009 at 2:55 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: Did you install the Msys autoconf, automake and m4 packages from sourceforge? They are found under the MSYS Supplementary section of the MinGW download page. I suggest using the most recent versions available. Lenard Tyler Laing wrote: Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should be... including the update automake, autoconf and m4 tars. $ ./autogen.sh Generating build information using autoconf This may take a while ... Can't locate object method path
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Thanks guys, I've got it all working now. The second step with: python setup.py --compiler=mingw32 install throws an error, saying that --compiler is not recognized. -Tyler On Wed, Apr 22, 2009 at 8:40 PM, Lenard Lindstrom le...@telus.net wrote: This would be from a patch msys_build_deps.py makes to work around freetypes being built in strict mode, that is, no extensions like 'inline'. The MinGW stdlib.h has an inlined function, causing the compile to fail. I believe René used a different fix from mine. So to disable mine edit msys_build_deps.py and comment out line 549 with a '#': export CPPFLAGS=-Dinline=__inline__ $CPPFLAGS If that fails with some error about 'inline' not recognized then the MinGW header include\stdlib.h will have to be edited on line 317 to replace 'inline' with '__inline__'. By the way, which version of gcc are you using? This gave me no problems with gcc 3.4.5. Lenard Tyler Laing wrote: Okay, it compiled both SDL and zlib, but it failed on freetype. Here's the error message: from snip freetype-2.3.7/src/base/ftsysem.c:29: snip../include/stdlib.h:317: error: syntax error before double Right now I'm compiling the rest, so we'll see if there's any other errors. -Tyler On Wed, Apr 22, 2009 at 5:49 PM, René Dudfield ren...@gmail.com mailto: ren...@gmail.com wrote: hi, try this: python msys_build_deps.py --all then this: python setup.py build --compiler=mingw32 install On Thu, Apr 23, 2009 at 10:18 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com wrote: I'm sorry if I seem dense throughout all of this, XD. Okay, so I take your package there, unzip it. I copy the pygame source code trunk into there. I then use the windows cmd, and cd into that directory, and run python setup.py --compiler=mingw32 install ? I'm sorry, but you're going to need explicate more steps, and that, because nothing is working for me. Doing the above, after I removed mingw32, and msys, then reinstalled them, then unzipped the msyscore archive in the msys directory to update to 1.0.11, I get this: Hunting dependencies /bin/sh/ : sdl-config: No such directory or file WARNING: sdl-config failed! /bin/shL smpeg-config: No such directory or file WARNING: smpeg-config failed! Normally things work for me, but I'm having a lot of trouble here, because nothing is clear, and Windows has the worst command-line utility around. This is by no means a condemnation of you guys, just that you guys are expecting more out of me, and its just not happening. -Tyler On Wed, Apr 22, 2009 at 4:34 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: hi, try this: http://rene.f0o.com/~rene/pygame_mingw32_compile_pack.ziphttp://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip http://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip They are the installers for mingw stuff I last installed on my windows machine to compile pygame. Other people have used those to successfully compile it too... so it should work. Also, if you get the dependency sources that Lenard collected on his page in one bundle: http://www3.telus.net/len_l/pygame/Pygame-1.9.0-deps-src.zip I think the directory structure matters too: # directory with all the source deps in it: pygame/ # the trunk is here: pygame/PyGame/ cu, On Thu, Apr 23, 2009 at 8:39 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com wrote: Unfortunately, it doesn't work. Does anyone have a better guide or series of steps to compiling pygame? Those steps should include properly install msys and associated packages. If not, I'll go over and start using the prebuilts. Thanks for the effort Lenard. -Tyler On Wed, Apr 22, 2009 at 2:55 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: Did you install the Msys autoconf, automake and m4 packages from sourceforge? They are found under the MSYS Supplementary section of the MinGW download page. I suggest using the most recent versions available. Lenard Tyler Laing wrote: Its failing on SDL. I tried running .autogen.sh in the directory, and this is what I got. I just made sure all the extra packages had been extracted to where they should
Re: beginning GSOC preparations: was Re: [pygame] Thank You
python setup.py build --compiler=mingw32 install setup.py allows multiple steps, like build and install, to be listed in one command. The install option doesn't recognize the --compiler option, but the build option. The build option, which install uses when need, does recognize --compiler. I once submitted a Python bug report about install and --compiler, but accepted this work around. Lenard yler Laing wrote: Thanks guys, I've got it all working now. The second step with: python setup.py --compiler=mingw32 install throws an error, saying that --compiler is not recognized. -Tyler On Wed, Apr 22, 2009 at 8:40 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: This would be from a patch msys_build_deps.py makes to work around freetypes being built in strict mode, that is, no extensions like 'inline'. The MinGW stdlib.h has an inlined function, causing the compile to fail. I believe René used a different fix from mine. So to disable mine edit msys_build_deps.py and comment out line 549 with a '#': export CPPFLAGS=-Dinline=__inline__ $CPPFLAGS If that fails with some error about 'inline' not recognized then the MinGW header include\stdlib.h will have to be edited on line 317 to replace 'inline' with '__inline__'. By the way, which version of gcc are you using? This gave me no problems with gcc 3.4.5. Lenard Tyler Laing wrote: Okay, it compiled both SDL and zlib, but it failed on freetype. Here's the error message: from snip freetype-2.3.7/src/base/ftsysem.c:29: snip../include/stdlib.h:317: error: syntax error before double Right now I'm compiling the rest, so we'll see if there's any other errors. -Tyler On Wed, Apr 22, 2009 at 5:49 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com wrote: hi, try this: python msys_build_deps.py --all then this: python setup.py build --compiler=mingw32 install On Thu, Apr 23, 2009 at 10:18 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com wrote: I'm sorry if I seem dense throughout all of this, XD. Okay, so I take your package there, unzip it. I copy the pygame source code trunk into there. I then use the windows cmd, and cd into that directory, and run python setup.py --compiler=mingw32 install ? I'm sorry, but you're going to need explicate more steps, and that, because nothing is working for me. Doing the above, after I removed mingw32, and msys, then reinstalled them, then unzipped the msyscore archive in the msys directory to update to 1.0.11, I get this: Hunting dependencies /bin/sh/ : sdl-config: No such directory or file WARNING: sdl-config failed! /bin/shL smpeg-config: No such directory or file WARNING: smpeg-config failed! Normally things work for me, but I'm having a lot of trouble here, because nothing is clear, and Windows has the worst command-line utility around. This is by no means a condemnation of you guys, just that you guys are expecting more out of me, and its just not happening. -Tyler On Wed, Apr 22, 2009 at 4:34 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com wrote: hi, try this: http://rene.f0o.com/~rene/pygame_mingw32_compile_pack.zip http://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip http://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip They are the installers for mingw stuff I last installed on my windows machine to compile pygame. Other people have used those to successfully compile it too... so it should work. Also, if you get the dependency sources that Lenard collected on his page in one bundle: http://www3.telus.net/len_l/pygame/Pygame-1.9.0-deps-src.zip I think the directory structure matters too: # directory with all the source deps in it: pygame/ # the trunk is here: pygame/PyGame/ cu, On Thu, Apr 23, 2009 at 8:39 AM, Tyler Laing trinio...@gmail.com
Re: beginning GSOC preparations: was Re: [pygame] Thank You
And that works! Fantastic, thank you gentlemen for all the assistance. Much appreciated. -Tyler On Wed, Apr 22, 2009 at 9:22 PM, Lenard Lindstrom le...@telus.net wrote: python setup.py build --compiler=mingw32 install setup.py allows multiple steps, like build and install, to be listed in one command. The install option doesn't recognize the --compiler option, but the build option. The build option, which install uses when need, does recognize --compiler. I once submitted a Python bug report about install and --compiler, but accepted this work around. Lenard yler Laing wrote: Thanks guys, I've got it all working now. The second step with: python setup.py --compiler=mingw32 install throws an error, saying that --compiler is not recognized. -Tyler On Wed, Apr 22, 2009 at 8:40 PM, Lenard Lindstrom le...@telus.netmailto: le...@telus.net wrote: This would be from a patch msys_build_deps.py makes to work around freetypes being built in strict mode, that is, no extensions like 'inline'. The MinGW stdlib.h has an inlined function, causing the compile to fail. I believe René used a different fix from mine. So to disable mine edit msys_build_deps.py and comment out line 549 with a '#': export CPPFLAGS=-Dinline=__inline__ $CPPFLAGS If that fails with some error about 'inline' not recognized then the MinGW header include\stdlib.h will have to be edited on line 317 to replace 'inline' with '__inline__'. By the way, which version of gcc are you using? This gave me no problems with gcc 3.4.5. Lenard Tyler Laing wrote: Okay, it compiled both SDL and zlib, but it failed on freetype. Here's the error message: from snip freetype-2.3.7/src/base/ftsysem.c:29: snip../include/stdlib.h:317: error: syntax error before double Right now I'm compiling the rest, so we'll see if there's any other errors. -Tyler On Wed, Apr 22, 2009 at 5:49 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com wrote: hi, try this: python msys_build_deps.py --all then this: python setup.py build --compiler=mingw32 install On Thu, Apr 23, 2009 at 10:18 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com wrote: I'm sorry if I seem dense throughout all of this, XD. Okay, so I take your package there, unzip it. I copy the pygame source code trunk into there. I then use the windows cmd, and cd into that directory, and run python setup.py --compiler=mingw32 install ? I'm sorry, but you're going to need explicate more steps, and that, because nothing is working for me. Doing the above, after I removed mingw32, and msys, then reinstalled them, then unzipped the msyscore archive in the msys directory to update to 1.0.11, I get this: Hunting dependencies /bin/sh/ : sdl-config: No such directory or file WARNING: sdl-config failed! /bin/shL smpeg-config: No such directory or file WARNING: smpeg-config failed! Normally things work for me, but I'm having a lot of trouble here, because nothing is clear, and Windows has the worst command-line utility around. This is by no means a condemnation of you guys, just that you guys are expecting more out of me, and its just not happening. -Tyler On Wed, Apr 22, 2009 at 4:34 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com wrote: hi, try this: http://rene.f0o.com/~rene/pygame_mingw32_compile_pack.ziphttp://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip http://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip http://rene.f0o.com/%7Erene/pygame_mingw32_compile_pack.zip They are the installers for mingw stuff I last installed on my windows machine to compile pygame. Other people have used those to successfully compile it too... so it should work. Also, if you get the dependency sources that Lenard collected on his page in one bundle: http://www3.telus.net/len_l/pygame/Pygame-1.9.0-deps-src.zip I think the directory structure matters too: # directory with all the source deps in it: pygame/ #
Re: beginning GSOC preparations: was Re: [pygame] Thank You
One last step, run the unit test suite. I will only take a few minutes (still under construction). python -c import pygame.tests.go Tyler Laing wrote: And that works! Fantastic, thank you gentlemen for all the assistance. Much appreciated. -Tyler On Wed, Apr 22, 2009 at 9:22 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: python setup.py build --compiler=mingw32 install setup.py allows multiple steps, like build and install, to be listed in one command. The install option doesn't recognize the --compiler option, but the build option. The build option, which install uses when need, does recognize --compiler. I once submitted a Python bug report about install and --compiler, but accepted this work around. Lenard yler Laing wrote: Thanks guys, I've got it all working now. The second step with: python setup.py --compiler=mingw32 install throws an error, saying that --compiler is not recognized. -Tyler On Wed, Apr 22, 2009 at 8:40 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net mailto:le...@telus.net mailto:le...@telus.net wrote: This would be from a patch msys_build_deps.py makes to work around freetypes being built in strict mode, that is, no extensions like 'inline'. The MinGW stdlib.h has an inlined function, causing the compile to fail. I believe René used a different fix from mine. So to disable mine edit msys_build_deps.py and comment out line 549 with a '#': export CPPFLAGS=-Dinline=__inline__ $CPPFLAGS If that fails with some error about 'inline' not recognized then the MinGW header include\stdlib.h will have to be edited on line 317 to replace 'inline' with '__inline__'. By the way, which version of gcc are you using? This gave me no problems with gcc 3.4.5. Lenard Tyler Laing wrote: Okay, it compiled both SDL and zlib, but it failed on freetype. Here's the error message: from snip freetype-2.3.7/src/base/ftsysem.c:29: snip../include/stdlib.h:317: error: syntax error before double Right now I'm compiling the rest, so we'll see if there's any other errors. -Tyler On Wed, Apr 22, 2009 at 5:49 PM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com mailto:ren...@gmail.com wrote: hi, try this: python msys_build_deps.py --all then this: python setup.py build --compiler=mingw32 install On Thu, Apr 23, 2009 at 10:18 AM, Tyler Laing trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com mailto:trinio...@gmail.com wrote: I'm sorry if I seem dense throughout all of this, XD. Okay, so I take your package there, unzip it. I copy the pygame source code trunk into there. I then use the windows cmd, and cd into that directory, and run python setup.py --compiler=mingw32 install ? I'm sorry, but you're going to need explicate more steps, and that, because nothing is working for me. Doing the above, after I removed mingw32, and msys, then reinstalled them, then unzipped the msyscore archive in the msys directory to update to 1.0.11, I get this: Hunting dependencies /bin/sh/ : sdl-config: No such directory or file WARNING: sdl-config failed! /bin/shL smpeg-config: No such directory or file WARNING: smpeg-config failed! Normally things work for me, but I'm having a lot of trouble here, because nothing is clear, and Windows has the worst command-line utility around. This is by no means a condemnation of you guys, just that you guys are expecting more out of me, and its just not happening. -Tyler On Wed,
Re: beginning GSOC preparations: was Re: [pygame] Thank You
That reminds me... should we make the tests run at the end of an install automatically? Should make it easier for people to figure out if there are problems... but might cause it's own problems too. On Thu, Apr 23, 2009 at 2:39 PM, Lenard Lindstrom le...@telus.net wrote: One last step, run the unit test suite. I will only take a few minutes (still under construction). python -c import pygame.tests.go Tyler Laing wrote: And that works! Fantastic, thank you gentlemen for all the assistance. Much appreciated. -Tyler
Re: beginning GSOC preparations: was Re: [pygame] Thank You
We could add it as an optional 'test' command option. Lenard René Dudfield wrote: That reminds me... should we make the tests run at the end of an install automatically? Should make it easier for people to figure out if there are problems... but might cause it's own problems too. On Thu, Apr 23, 2009 at 2:39 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: One last step, run the unit test suite. I will only take a few minutes (still under construction). python -c import pygame.tests.go Tyler Laing wrote: And that works! Fantastic, thank you gentlemen for all the assistance. Much appreciated. -Tyler
Re: beginning GSOC preparations: was Re: [pygame] Thank You
Biggest problems I could see are in two areas, misinterpretation and structural. Depending on the filesystem, and current hardware setup, some of the files may still be being written to disk(say a network drive or during lots of other writes) when the tests are run. In terms of misinterepretation, you'd have to make it clear that it is in its test phase, and that installation finished without a hitch. Those are all I can see happening. And as to the test's you asked me to run... I realize now I was supposed to use the svn trunk of pygame, not the 1.8 release. Redoing it all over right now, but with the problems fixed, I don't forsee any issues. :) -Tyler On Wed, Apr 22, 2009 at 9:42 PM, René Dudfield ren...@gmail.com wrote: That reminds me... should we make the tests run at the end of an install automatically? Should make it easier for people to figure out if there are problems... but might cause it's own problems too. On Thu, Apr 23, 2009 at 2:39 PM, Lenard Lindstrom le...@telus.net wrote: One last step, run the unit test suite. I will only take a few minutes (still under construction). python -c import pygame.tests.go Tyler Laing wrote: And that works! Fantastic, thank you gentlemen for all the assistance. Much appreciated. -Tyler -- Visit my blog at http://oddco.ca/zeroth/zblog
[pygame] Thank You
I just wanted to thank everyone that worked on helping me and others with our applications, and I also wanted to thank all the people that worked hard on approving the applications. Your efforts are appreciated. :) On that note, I was wondering who would be my mentor, for my project? -Tyler Laing -- Visit my blog at http://oddco.ca/zeroth/zblog
beginning GSOC preparations: was Re: [pygame] Thank You
Hi Tyler, I'm going to be your main mentor, with Marcus, and Nirav being backup/co-mentors. To start preparing for your work, here's a few things you can do... - make sure you can compile pygame. - see the wiki for instructions for your platform(s) - http://pygame.org/wiki/Compilation - as pygame is multi platform, you'll have to work on multiplatforms too. - prepare a separate platform to work on if you can. Like setting up linux if you don't have it already. - not entirely necessary, but it'd make things easier for yourself. - set up your blog, which you'll be writing about your project as you go. - mark related posts with tags pygame, python, gsoc2009 - add your blog to this wiki page: - http://www.pygame.org/wiki/rsslinks - email the pygame mailing list about your blog (once you have at least one related post). - email the soc2009-general with your blog details, and ask them to list your blog on soc.python.org. - if you don't have a blog already, you can set up a free one with blogspot.com or wordpress.com. - prepare a reading list. - start looking at some related materials to read. - like for ffmpeg, read through some of the development mailing list, and development docs etc. - if you haven't used svn before much, read some of the svn book. - svn commit access. - I'll have this arranged. - first, post a patch to some small change to the mailing list, with svn diff your-patch.diff cheers, On Tue, Apr 21, 2009 at 11:46 PM, Tyler Laing trinio...@gmail.com wrote: I just wanted to thank everyone that worked on helping me and others with our applications, and I also wanted to thank all the people that worked hard on approving the applications. Your efforts are appreciated. :) On that note, I was wondering who would be my mentor, for my project? -Tyler Laing -- Visit my blog at http://oddco.ca/zeroth/zblog
