Re: [pygame] fmodf on msvc transform.c... any ideas brian?
Yeah, you can use the run_tests_sub.py that Nicholas made to run each of the tests in a separate process. I think it runs each of the suites in a separate process, rather than each test. On Mon, Jun 30, 2008 at 2:52 PM, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > The setUp and tearDown methods. These can be useful. There is also a > solution in the works wherel each unit test is run as an independent > program. This means no changes will be needed. > > Lenard > > > Charlie Nolan wrote: >> >> Correct me if I'm wrong, but doesn't unittest specifically give you a >> way to perform setup and tear-down actions before/after each test? >> Seems like that would be a good candidate for calling init and quit. >> >> -FM >> >> On 6/29/08, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: >> > > [...] >>> >>> [O]ne should be able to rely on the default >>> pre-pygame.init() setting, 32 bpp, for each unit test. A unit test that >>> confirms this default could fail. Too much interference between test >>> modules. >>> >>> > >
Re: [pygame] Licensing
On Sun, Jun 29, 2008 at 10:16:53PM -0400, Chris wrote: > The more I read about software licenses, the more confused I get. > > In general terms... > > LGPL is "use but don't alter." Not quite. "Use but don't alter unless the alterations are also LGPL" > AGPL is "use but whatever you make must be AGPL." (I don't know this one, sorry) > GPL is "use and alter but only if the derivative is free." Close. "use and alter but only if the derivative is GPL" > Artistic is "use but alter only with permission." (I don't know) > BSD is "use it for whatever." Again, close. "Use for whatever but don't remove copyright notice" > I notice LGPL is used on a lot of pygame projects. Is that because > pygame itself uses LGPL? It makes sense for pygame to use LGPL because > it's a huge, widely used library but it's not apparent as to why the > game projects themselves to use LGPL. Yes, the fact that pygame, and python are both LGPL is a main reason why many pygame games are LGPL. But unless you modify pygame itself, your projects can be of absolutely any license you choose. > I'm using the following chart for reference: > http://en.wikipedia.org/wiki/Comparison_of_free_software_licences > > I'd like to hear why users of pygame chose the license they chose. > > I'm leaning towards the Artistic License 2.0. > > Peace.--Chris > > James Paige
Re: [pygame] fmodf on msvc transform.c... any ideas brian?
The setUp and tearDown methods. These can be useful. There is also a solution in the works wherel each unit test is run as an independent program. This means no changes will be needed. Lenard Charlie Nolan wrote: Correct me if I'm wrong, but doesn't unittest specifically give you a way to perform setup and tear-down actions before/after each test? Seems like that would be a good candidate for calling init and quit. -FM On 6/29/08, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: [...] [O]ne should be able to rely on the default pre-pygame.init() setting, 32 bpp, for each unit test. A unit test that confirms this default could fail. Too much interference between test modules.
Re: [pygame] fmodf on msvc transform.c... any ideas brian?
Correct me if I'm wrong, but doesn't unittest specifically give you a way to perform setup and tear-down actions before/after each test? Seems like that would be a good candidate for calling init and quit. -FM On 6/29/08, Lenard Lindstrom <[EMAIL PROTECTED]> wrote: > Marcus von Appen wrote: >> On, Sun Jun 29, 2008, Lenard Lindstrom wrote: >> >> >>> Lenard Lindstrom wrote: >>> >> >> [...] >> >>> I take that back. Rearranging the test execution to that of the >>> automated build site gives me an error. It is unrelated to PixelArray. >>> >>> ERROR: test_surfarray_ref (surflock_test.SurfaceLockTest) >>> -- >>> Traceback (most recent call last): >>> File "test\surflock_test.py", line 141, in test_surfarray_ref >>> ar = pygame.surfarray.pixels2d (sf) >>> File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line >>> 122, in pix >>> els2d >>> return numericsf.pixels2d (surface) >>> ValueError: unsupport bit depth for 2D reference array >>> >>> -- >>> Ran 469 tests in 24.000s >>> >>> FAILED (errors=1) >>> >>> >>> My experience is such errors are related to the display's settings. One >>> or more unit tests which call pygame.display.set_mode fail to do proper >>> cleanup by later calling pygame.quit . >>> >> >> Probably you've got a 24bpp setting active, which caused the surflock >> test to fail as I forgot to explicitly set the surface depth to 32 >> bit. Fixed in rev. >> >> > Okay, it works. But one should be able to rely on the default > pre-pygame.init() setting, 32 bpp, for each unit test. A unit test that > confirms this default could fail. Too much interference between test > modules. > > -- > Lenard Lindstrom > <[EMAIL PROTECTED]> > >
Re: [pygame] fmodf on msvc transform.c... any ideas brian?
Marcus von Appen wrote: On, Sun Jun 29, 2008, Lenard Lindstrom wrote: Lenard Lindstrom wrote: [...] I take that back. Rearranging the test execution to that of the automated build site gives me an error. It is unrelated to PixelArray. ERROR: test_surfarray_ref (surflock_test.SurfaceLockTest) -- Traceback (most recent call last): File "test\surflock_test.py", line 141, in test_surfarray_ref ar = pygame.surfarray.pixels2d (sf) File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line 122, in pix els2d return numericsf.pixels2d (surface) ValueError: unsupport bit depth for 2D reference array -- Ran 469 tests in 24.000s FAILED (errors=1) My experience is such errors are related to the display's settings. One or more unit tests which call pygame.display.set_mode fail to do proper cleanup by later calling pygame.quit . Probably you've got a 24bpp setting active, which caused the surflock test to fail as I forgot to explicitly set the surface depth to 32 bit. Fixed in rev. Okay, it works. But one should be able to rely on the default pre-pygame.init() setting, 32 bpp, for each unit test. A unit test that confirms this default could fail. Too much interference between test modules. -- Lenard Lindstrom <[EMAIL PROTECTED]>
[pygame] Licensing
The more I read about software licenses, the more confused I get. In general terms... LGPL is "use but don't alter." AGPL is "use but whatever you make must be AGPL." GPL is "use and alter but only if the derivative is free." Artistic is "use but alter only with permission." BSD is "use it for whatever." I notice LGPL is used on a lot of pygame projects. Is that because pygame itself uses LGPL? It makes sense for pygame to use LGPL because it's a huge, widely used library but it's not apparent as to why the game projects themselves to use LGPL. I'm using the following chart for reference: http://en.wikipedia.org/wiki/Comparison_of_free_software_licences I'd like to hear why users of pygame chose the license they chose. I'm leaning towards the Artistic License 2.0. Peace.--Chris
Re: [pygame] fmodf on msvc transform.c... any ideas brian?
On, Sun Jun 29, 2008, Lenard Lindstrom wrote: > Lenard Lindstrom wrote: [...] > I take that back. Rearranging the test execution to that of the > automated build site gives me an error. It is unrelated to PixelArray. > > ERROR: test_surfarray_ref (surflock_test.SurfaceLockTest) > -- > Traceback (most recent call last): > File "test\surflock_test.py", line 141, in test_surfarray_ref > ar = pygame.surfarray.pixels2d (sf) > File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line > 122, in pix > els2d > return numericsf.pixels2d (surface) > ValueError: unsupport bit depth for 2D reference array > > -- > Ran 469 tests in 24.000s > > FAILED (errors=1) > > > My experience is such errors are related to the display's settings. One > or more unit tests which call pygame.display.set_mode fail to do proper > cleanup by later calling pygame.quit . Probably you've got a 24bpp setting active, which caused the surflock test to fail as I forgot to explicitly set the surface depth to 32 bit. Fixed in rev. Regards Marcus pgpVP3qy39tXe.pgp Description: PGP signature
Re: [pygame] fmodf on msvc transform.c... any ideas brian?
Lenard Lindstrom wrote: Lenard Lindstrom wrote: Marcus von Appen wrote: On, Sun Jun 29, 2008, Lenard Lindstrom wrote: Lenard Lindstrom wrote: Hi René, René Dudfield wrote: ah, nice one. I think Lenard made some fixes not long ago to the pixel array stuff, maybe that has something to do with it. I chased down one memory access violation in pixelarray.c. A patch should be commited shortly. The other patch simply removes a memory leak. Fixed in revision 1419. And really fixed (to work as initially supposed) in rev. 1421 :-). I confirm rev 1422 compiles and links and that all unit tests pass for both Pythons 2.4 and 2.5. I take that back. Rearranging the test execution to that of the automated build site gives me an error. It is unrelated to PixelArray. ERROR: test_surfarray_ref (surflock_test.SurfaceLockTest) -- Traceback (most recent call last): File "test\surflock_test.py", line 141, in test_surfarray_ref ar = pygame.surfarray.pixels2d (sf) File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line 122, in pix els2d return numericsf.pixels2d (surface) ValueError: unsupport bit depth for 2D reference array -- Ran 469 tests in 24.000s FAILED (errors=1) My experience is such errors are related to the display's settings. One or more unit tests which call pygame.display.set_mode fail to do proper cleanup by later calling pygame.quit . P.S. Setting the display to High Color (16 bit) causes the Python 2.5 interpreter to hang after the "FAILED (failures=3, errors=1)" message. There is definitely a bug involving 16 bit surfaces. But where? -- Lenard Lindstrom <[EMAIL PROTECTED]>
Re: [pygame] fmodf on msvc transform.c... any ideas brian?
Lenard Lindstrom wrote: Marcus von Appen wrote: On, Sun Jun 29, 2008, Lenard Lindstrom wrote: Lenard Lindstrom wrote: Hi René, René Dudfield wrote: ah, nice one. I think Lenard made some fixes not long ago to the pixel array stuff, maybe that has something to do with it. I chased down one memory access violation in pixelarray.c. A patch should be commited shortly. The other patch simply removes a memory leak. Fixed in revision 1419. And really fixed (to work as initially supposed) in rev. 1421 :-). I confirm rev 1422 compiles and links and that all unit tests pass for both Pythons 2.4 and 2.5. I take that back. Rearranging the test execution to that of the automated build site gives me an error. It is unrelated to PixelArray. ERROR: test_surfarray_ref (surflock_test.SurfaceLockTest) -- Traceback (most recent call last): File "test\surflock_test.py", line 141, in test_surfarray_ref ar = pygame.surfarray.pixels2d (sf) File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line 122, in pix els2d return numericsf.pixels2d (surface) ValueError: unsupport bit depth for 2D reference array -- Ran 469 tests in 24.000s FAILED (errors=1) My experience is such errors are related to the display's settings. One or more unit tests which call pygame.display.set_mode fail to do proper cleanup by later calling pygame.quit . -- Lenard Lindstrom <[EMAIL PROTECTED]>
Re: [pygame] fmodf on msvc transform.c... any ideas brian?
Marcus von Appen wrote: On, Sun Jun 29, 2008, Lenard Lindstrom wrote: Lenard Lindstrom wrote: Hi René, René Dudfield wrote: ah, nice one. I think Lenard made some fixes not long ago to the pixel array stuff, maybe that has something to do with it. I chased down one memory access violation in pixelarray.c. A patch should be commited shortly. The other patch simply removes a memory leak. Fixed in revision 1419. And really fixed (to work as initially supposed) in rev. 1421 :-). I confirm rev 1422 compiles and links and that all unit tests pass for both Pythons 2.4 and 2.5. -- Lenard Lindstrom <[EMAIL PROTECTED]>
Re: [pygame] The gsoc physics module, bug fixing?
Hi Marcus! OK, I'll hold with the Python API testing. Tell me when. :) /Peter On 2008-06-29 (Sun) 15:30, Marcus von Appen wrote: > On, Sun Jun 29, 2008, Peter Gebauer wrote: > > > Hi Zhang and others! > > [Python wrapper issues] > > The wrapper implementation is not really started yet, so it's a bit > early. In order to keep argument parsing flexible, I'd recommend using > METH_VARARGS and PyArg_ParseTuple() instead of the _0, ... macros. This > let's one easily enhance anything without the need to change too much > code. Additionally you can let the parser handle argument checking > without the need to deal with ex- or implicit object conversions. > > Regards > Marcus
Re: [pygame] The gsoc physics module, bug fixing?
On, Sun Jun 29, 2008, Peter Gebauer wrote: > Hi Zhang and others! [Python wrapper issues] The wrapper implementation is not really started yet, so it's a bit early. In order to keep argument parsing flexible, I'd recommend using METH_VARARGS and PyArg_ParseTuple() instead of the _0, ... macros. This let's one easily enhance anything without the need to change too much code. Additionally you can let the parser handle argument checking without the need to deal with ex- or implicit object conversions. Regards Marcus pgpVS1Q7sTWyJ.pgp Description: PGP signature
Re: [pygame] fmodf on msvc transform.c... any ideas brian?
On, Sun Jun 29, 2008, Lenard Lindstrom wrote: > Lenard Lindstrom wrote: > > Hi René, > > > > René Dudfield wrote: > >> ah, nice one. > >> > >> I think Lenard made some fixes not long ago to the pixel array stuff, > >> maybe that has something to do with it. > >> > >> > > I chased down one memory access violation in pixelarray.c. A patch > > should be commited shortly. The other patch simply removes a memory leak. > > > Fixed in revision 1419. And really fixed (to work as initially supposed) in rev. 1421 :-). Regards Marcus pgpBUkgrVTTvg.pgp Description: PGP signature
Re: [pygame] The gsoc physics module, bug fixing?
Hi Zhang and others!
Is it too early to test for bugs? I don't know what method you are using for
development, mine is to test every new thing I write and make sure it works
before I proceed. Depending on your aproach you may not want bug reports
already?
Anyway, after calling world.update(1.0) any following function call will
yield this error:
TypeError: a float is required
Fatal Python error: (pygame parachute) Segmentation Fault
Aborted
Unfortunately, Debian testing has some serious issues with it's python-dbg
package on 64-bit, it thinks it's missing Py_InitModule4_64, so I cannot
debug further using gdb, but I know this error from before.
The problem line is in pgWorldObject.c:
static PyObject* _world_update(pgWorldObject* world,PyObject* pyfloat)
{
double dt = PyFloat_AsDouble(pyfloat); <-- problem line
pyfloat is tuple instance, you have METH_VARARGS there which indicates that
the second argument will be a tuple containing the arguments from the Python
call. What you want though is the METH_O, just pass ONE object to the C
call.
So:
{ "update", (PyCFunction) _world_update, METH_VARARGS, "" },
changes to
{ "update", (PyCFunction) _world_update, METH_O, "" },
and the function _world_update should look something like:
static PyObject* _world_update(pgWorldObject* world, PyObject* pyfloat)
{
if (!PyFloat_Check(pyfloat)) {
PyErr_SetString(PyExc_TypeError, "World update requires a float");
return NULL;
}
double dt = PyFloat_AsDouble(pyfloat);
PG_Update(world,dt);
Py_RETURN_NONE;
}
That will make a safe and correct call to update using one float. Your other
alternative, if you want more than one argument, is to stick with
METH_VARARGS and do do this:
static PyObject* _world_update(pgWorldObject *world, PyObject *args)
{
PyFloatObject *farg;
if (!PyArg_ParseTuple(args, "f", &farg))
return NULL; // fail if the argument isn't a float
However, if you're only looking for a single float argument, it makes no
sense for Python to first create a tuple argument list just so you can parse
out one single argument.
I don't know if you want patches of the files, commits to svn or keep
explaining the problems in emails like this, whatever works best and most
efficiently for you.
I'm really looking forward to test some more!
Best regards, Peter
