Ok, great. color_test.py passes for me. FYI, Python 2.x ints are C
longs, whatever size that may be on a particular machine.
Lenard
Tyler Laing wrote:
Lenard,
Thanks a lot! :) I incorporated your fix into the baseline code, and
there just needed to be some slight modifications for the other
Lenard,
Thanks a lot! :) I incorporated your fix into the baseline code, and there
just needed to be some slight modifications for the other conversion
functions, long, int, float, in addition to float and oct. I had initially
considered LONG_MAX, but I wasn't sure what it would do, and didn't kno
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 "L"s but
replaces INT_MAX with LONG_MAX, which is the proper test for a Python
int (*
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'
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 wan
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
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 p
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 wrote:
> Rene,
>
> Okay, so I've got a fix. You have to prefix color->r with (long), and then
> fo
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
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 wrote:
> Rene,
>
> You are right.
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 Lai
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 wrote:
> hi,
>
> there's some parts like this...
>
> st
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 shi
Taking a look at color.c, I believe the bug may actually rest in the
Py_FromUnsignedLong/Py_FromDouble/Py_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 af
hi,
Below are the failing unittests for Color on 64bit ubuntu.
==
> FAIL: ColorTypeTest.test_float
> --
> Traceback (most recent call last):
> File "/usr/li
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.te
On Sat, Apr 25, 2009 at 3:26 AM, Tyler Laing 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 f
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
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.
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
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_dep
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
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,
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,
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 wrote:
> One last step, run the unit test s
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 L
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 wrote:
> python setup.py build --compiler=mingw32 install
>
> setup.py allows multiple steps, like build and install, to be listed in one
> command.
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 o
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 wrote:
> This would be from a patch msys_build_deps.py makes to work a
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_bui
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:
Okay, it compiled both SDL and zlib, but it failed on freetype. Here's the
error message:
from freetype-2.3.7/src/base/ftsysem.c:29:
../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, 2
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 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
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 expli
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 tha
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 P
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 dir
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
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_
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 wrote:
> Hi Tyler,
>
> I wrote msys_build_deps.py and look after the Windows depende
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 X
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
Tyler Laing wrote:
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 t
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 rel
44 matches
Mail list logo
