Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Lenard Lindstrom]

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 
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 know if it would break 32 bit code. Now I know. Thanks. 
:) Here's an updated patch that covers all the conversion functions.


-Tyler

On Fri, May 1, 2009 at 9:34 PM, Lenard Lindstrom > wrote:


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 (*).

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
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
   mailto:ren...@gmail.com>
>
   

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Tyler Laing]

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 know if
it would break 32 bit code. Now I know. Thanks. :) Here's an updated patch
that covers all the conversion functions.

-Tyler

On Fri, May 1, 2009 at 9:34 PM, Lenard Lindstrom  wrote:

> 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
> (*).
>
> 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>> 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
>>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 yo

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Lenard Lindstrom]

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 (*).


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 > 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
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 
 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
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: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Tyler Laing]

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  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>> 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 >> 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

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Lenard Lindstrom]

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 > 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 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 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:

Re: [pygame] nokia s60 branch merge...

[Lenard Lindstrom]

I've just committed the changes to SVN. As for the mixer crash, there is 
a know cleanup problem with SDL_mixer 1.2.8 that has been fixed in SVN. 
I use the SVN version in Windows. It doesn't seem to help in Debian 
though. I will double check that the proper library is used. As for 
smpeg there is some recent activity (three months ago), but for the most 
part nothing has been checked in for nearly two years. The sndarray test 
also fails, though the sound_array_demos.py works.


Lenard

René Dudfield wrote:

hi,

awesome.

As for the mixer crash... I think it might be smpeg related.  I think
on win/mac/source we are using svn smpeg with some patches that
haven't made it into Debian as smpeg hasn't had any releases in ages.
I haven't confirmed this yet though.  I noticed Tyler had a crash on
mixer/ubuntu too.




On Sat, May 2, 2009 at 10:57 AM, Lenard Lindstrom  wrote:
  

Hi René,

Good timing. I am preparing to merge python3 back into trunk. It builds and
passes all tests in Python 2.5 on Windows. There is a mixer.music problem on
Debian Linux though, causing mixer_music_test.py to crash. I think it is an
SDL_mixer issue (not recent SVN), but am not sure. Otherwise mixer and
mixer.music work. I will commit what I have then try a Python 3.1 build.
Even if it doesn't build right away there are enough other fixes, basically
in error checking and removing outdated coding, to make it worthwhile as is.

Lenard


René Dudfield wrote:


hello,

I have spoken to Jussi Toivola, about merging his pys60 branch into
trunk before pygame 1.9 is released.

So... the process we have decided is to slowly merge in changes... in
small groups if possible.  This will allow us to discuss his changes,
and to try and make sure things still build and run ok on various
platforms.

We can discuss any issues on the mailing list as they come up.

Is this ok?  Lenard... what do you think?   How does this go with the
py3k branch?  Should we try and merge more of that first... or at the
same time... or after?




  

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Tyler Laing]

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  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  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  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 
> 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 
> wrote:
> >> >>
> >> >> Rene,
> >> >>
> >> >> You are right.

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[René Dudfield]

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  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  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  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  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 
>> >> 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 
>> >>> 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 
>>  wrote:
>>  > 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

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Tyler Laing]

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
> 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. 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  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  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 
 wrote:
 > 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 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 
 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))
 

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[René Dudfield]

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  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  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  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  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  wrote:
 > 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 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 
 > 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 

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Tyler Laing]

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. 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  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  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  wrote:
>>> > 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 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 
>>> 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/s

Re: [pygame] nokia s60 branch merge...

[René Dudfield]

hi,

awesome.

As for the mixer crash... I think it might be smpeg related.  I think
on win/mac/source we are using svn smpeg with some patches that
haven't made it into Debian as smpeg hasn't had any releases in ages.
I haven't confirmed this yet though.  I noticed Tyler had a crash on
mixer/ubuntu too.




On Sat, May 2, 2009 at 10:57 AM, Lenard Lindstrom  wrote:
> Hi René,
>
> Good timing. I am preparing to merge python3 back into trunk. It builds and
> passes all tests in Python 2.5 on Windows. There is a mixer.music problem on
> Debian Linux though, causing mixer_music_test.py to crash. I think it is an
> SDL_mixer issue (not recent SVN), but am not sure. Otherwise mixer and
> mixer.music work. I will commit what I have then try a Python 3.1 build.
> Even if it doesn't build right away there are enough other fixes, basically
> in error checking and removing outdated coding, to make it worthwhile as is.
>
> Lenard
>
>
> René Dudfield wrote:
>>
>> hello,
>>
>> I have spoken to Jussi Toivola, about merging his pys60 branch into
>> trunk before pygame 1.9 is released.
>>
>> So... the process we have decided is to slowly merge in changes... in
>> small groups if possible.  This will allow us to discuss his changes,
>> and to try and make sure things still build and run ok on various
>> platforms.
>>
>> We can discuss any issues on the mailing list as they come up.
>>
>> Is this ok?  Lenard... what do you think?   How does this go with the
>> py3k branch?  Should we try and merge more of that first... or at the
>> same time... or after?
>>
>>
>>
>>
>
>

Re: [pygame] nokia s60 branch merge...

[Lenard Lindstrom]

Hi René,

Good timing. I am preparing to merge python3 back into trunk. It builds 
and passes all tests in Python 2.5 on Windows. There is a mixer.music 
problem on Debian Linux though, causing mixer_music_test.py to crash. I 
think it is an SDL_mixer issue (not recent SVN), but am not sure. 
Otherwise mixer and mixer.music work. I will commit what I have then try 
a Python 3.1 build. Even if it doesn't build right away there are enough 
other fixes, basically in error checking and removing outdated coding, 
to make it worthwhile as is.


Lenard


René Dudfield wrote:

hello,

I have spoken to Jussi Toivola, about merging his pys60 branch into
trunk before pygame 1.9 is released.

So... the process we have decided is to slowly merge in changes... in
small groups if possible.  This will allow us to discuss his changes,
and to try and make sure things still build and run ok on various
platforms.

We can discuss any issues on the mailing list as they come up.

Is this ok?  Lenard... what do you think?   How does this go with the
py3k branch?  Should we try and merge more of that first... or at the
same time... or after?



  

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Tyler Laing]

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  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  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  wrote:
>> > 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 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  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 

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Tyler Laing]

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...
>
> 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  wrote:
> > 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 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  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

[René Dudfield]

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  wrote:
> 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 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  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] pygame 2001-2009(8 years), 1100+ projects at super speed.

[Ian Mallett]

Wow, quite amazing!  Looks like it took a while to make too.  I recognized
quite a few projects, as well as many of mine.

Re: [pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[Tyler Laing]

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 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  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

[pygame] BUG: pygame.Color bugs - 64bit. Re: beginning GSOC preparations: was Re: [pygame] Thank You

[René Dudfield]

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] vector type: mutable or immutable

[Gregor Lingl]

René Dudfield schrieb:

hrmmm.  Good question.

Thinking in terms of how much I use lists VS tuples...
   I'd use mutable lists for 96% of cases...  but occasionally
would like to use an immutable tuple.

Another argument is that Rect, Surface, and Color are mutable - so it
would be somewhat consistent with the other types.
  
Although I'm rather new on this list (yet), I'd like to contribute to 
this important thread:


Imho vectors should preferably behave like numbers (as we need them for 
calculations) instead of like Rects, Surface
etc. In other words, it should be consistent more with number types than 
with 'other types'. A code line like


x = x + v * dt

with x, v vectors is more clear and useful if I don't have to think 
which other names there are for
the object x (and thus will be changed together with x). I suspect thie 
use of a mutable vector type

would make the use of it more error-prone.

So in the first place we should have immutable vectors. Maybe there are 
also use cases which would
benefit from a mutable vector type, so to have both would be beneficial. 
If so a careful consideration
of the names of the datatypes would be necessary. VectorConst for 
something which is not a constant
doesn't seem appropriate to me. (Or would you agree to name the int 
type  intconst?)


Moreover I think, that implementation details  (memory management etc) 
should not override

problem domain arguments.

Regards,
Gregor





Note that Sprite, and Surface are mutable, but can be used as
dictionary keys.  They don't use their values as the keys.

However Rect can not be used for keys... so that's an inconsistency -
but maybe a good one.  Since generally you would want to use the
values of the Rect as the keys - so it forces a conversion to tuple.

I wonder how much effort it would be to make immutable and mutable?  I
think maybe too much.

overall... +1 for mutable.




cu,


On Sat, May 2, 2009 at 12:07 AM, Lorenz Quack  wrote:
  

Hi

as a follow up to the "API draft for vector type" I would like to discuss
the merits of having a mutable or immutable vector type.


Arguments for an immutable vector type:

Brian Fisher pointed out two advantages of immutable vector types:
1) they prevent bugs in programs like the following (adopted from Brian):


class Angel(object)
def __init__(self, offset):
self.offset = offset

t = Angel()
halo_pos = t.offset
halo_pos.y -= 5  # BUG: this changes the offset in t
  

2) if vectors are immutable you can use them as keys in dicts



Arguments for a mutable vector type:

1) operations such as rotate() and scale_to_length() are more elegant when
operation in-place. for immutable types you would have to do "v =
v.rotate()" or use a module level rotate function "v =
pygame.math.rotate_vector(v)" or something similar.

2) a priori I would expect mutable vectors to perform better than immutable
ones because you don't have to create new objects for every operation.



So are there anymore arguments?
And where do people stand on this issue?


yours

//Lorenz





  

Re: [pygame] starting the rewrite

[Shaun Mahood]

> I would vote that anyone not actually
> working on the website gets no vote in how it is implemented

I completely agree that votes should only count if you are putting
work in. Don't think a vote thread would actually be useful, though -
seems like the kind of thing where everyone would volunteer and then
disappear.

I would be willing to assist if there is any need for direct T-SQL
work or questions. In all the websites and programs I write I do all
the SQL by hand (ORM kind of scare me - when it looks too much like
magic I get really, really suspicious) - so I would be particularly
useless for ORM stuff.

Casey, I found a branch of Django development that uses SqlAlchemy.
http://code.google.com/p/django-sqlalchemy/

It may be possible for everyone to collaborate and get everything with
the databases working with SqlAlchemy, then split and create the rest
using their preferred framework. Might cause enough headaches to
completely ruin the whole reason to use Django, though.

Re: [pygame] starting the rewrite

[Devon Scott-Tunkin]

I don't know either framework, but I'm partial to Django becuase of:

http://en.wikipedia.org/wiki/Django_Reinhardt



--- On Fri, 5/1/09, Casey Duncan  wrote:

> From: Casey Duncan 
> Subject: Re: [pygame] starting the rewrite
> To: pygame-users@seul.org
> Date: Friday, May 1, 2009, 1:35 PM
> I would vote that anyone not actually
> working on the website gets no vote in how it is implemented
> 8^). I think armchair web jockeying should be limited to
> features and aesthetics, if anything.
> 
> How many folks are actually working on this?
> 
> -Casey
> 
> On May 1, 2009, at 12:12 PM, Jake b wrote:
> 
> > Maybe we need a vote thread.
> > 
> > 1st line: pick your framework
> > 2nd like: amount of work you expect to put in.
> > 
> > No discussion, just vote tallies, so we can see if
> it's definitely one
> > sided, and to stick with that. [ keeping discussion in
> another thread
> > ]
> > 
> > I 2nd shaun. I can write css/php/html, but haven't
> volunteered yet
> > since I haven't used django/cherrypy. So I could help
> if you have
> > access to that level. [ Haven't written a website in
> py yet, but it
> > sounds fun. ]
> > --Jake
> 
> 


  

Re: [pygame] vector type: mutable or immutable

[Brian Fisher]

On Fri, May 1, 2009 at 9:56 AM, Casey Duncan  wrote:

> I think that less memory management overhead and batch operations are
> strong arguments for mutable vectors.
>
> The less memory management is a performance vs. correctness thing, and
having used both extensively, and flip-flopped between the two multiple
times on what I regularly use, I find that I end up not using the
in-placeness of operations on mutable vectors very much anyways, because
they keep resulting in subtle and annoying bugs. Also, I find that the
in-place stuff makes much harder to read code vs. having and using lots of
canned functions for all kinds of common useful ops (i.e. doing a change of
basis on a vector for instance). My point being, that in my experience, I'm
not actually getting less memory management in practice from mutable
vectors, cause in the end I'm making copies lots and using higher level
functions as opposed to twiddling vectors manually.

Re: Batch operations, seem to me to be something where you'd really want to
allocate the block of vectors all at once anyways, so they already should be
a different beast than a single vector.



> The predicability of immutable vectors is nice, but IMO the convenience and
> flexibility of mutable vectors, along with the consistency with existing
> type like Rect makes them win.
>
> I agree the convenience and flexibility can be useful (the only case this
matters to me in practice, btw, is wanting to change just one element of the
vector, which is rare, but annoying when you can't do it)

I think consistency with the Rect type is a non-argument for mutability or
not. Practical should win over the notion that all pygame classes should
behave the same. If two things are different in use and results, their
behavior should be adapted to accommodate those differences - in fact having
consistent behavior can drive inconsistency in use.

In my experience, I've never wanted to take the rect property of something,
do some operations on it and introduce a bug that way, and I've never wanted
to use a rect as a key to a dict. However I've written some very confusing
bugs taking a vector property of something and changing it accidentally, and
I've been disappointed I couldn't use a vector as a key to a dict.



> I would argue that it should be possible to treat vectors as immutable if
> you preferred that, which I think is covered by the features proposed so
> far.
>
> There's no good way to get dict-key-ability from a mutable vector. Using
identity (like what surfaces does) would be bad, cause then two vectors that
are equal wouldn't be the same key, and people wouldn't "get" that.

Using a hash of the value has the problems of being prone to errors - it's
just too easy to write code that iterates over the keys and accidentally
changes the value of one, magically messing up your dict

Re: [pygame] vector type: mutable or immutable

[Brian Fisher]

I guess making both would be the most pythonic - python gives you both lists
and tuples...

On Fri, May 1, 2009 at 11:04 AM, Jake b  wrote:

> Could you make both? Default to mutable, and use VectorConst ( insert
> better name ) where needed.
>
>.offset = Vector3Const(1,2,3)
>.vel = Vector3( offset )
>
> (throw exception when you try to modify a const vector?)
> --
> Jake
>

Re: [pygame] starting the rewrite

[Casey Duncan]

I would vote that anyone not actually working on the website gets no  
vote in how it is implemented 8^). I think armchair web jockeying  
should be limited to features and aesthetics, if anything.


How many folks are actually working on this?

-Casey

On May 1, 2009, at 12:12 PM, Jake b wrote:


Maybe we need a vote thread.

1st line: pick your framework
2nd like: amount of work you expect to put in.

No discussion, just vote tallies, so we can see if it's definitely one
sided, and to stick with that. [ keeping discussion in another thread
]

I 2nd shaun. I can write css/php/html, but haven't volunteered yet
since I haven't used django/cherrypy. So I could help if you have
access to that level. [ Haven't written a website in py yet, but it
sounds fun. ]
--
Jake

Re: [pygame] starting the rewrite

[Casey Duncan]

On May 1, 2009, at 12:01 PM, Shaun Mahood wrote:


As much fun as it is to watch everyone split apart to do their own
thing, I have a few questions (not knowing anything about either
Django or cherrypy).

Do both of the frameworks "hide" all the database interactions? If
possible, it could save a ton of headaches later on if a database
structure could be set for both teams to develop on. If there were a
common set of methods written as well to interact with the database,
then you would have a whole lot of common sections between the two
rewrites.


Django comes with a built-in orm, so in that sense it does "hide" db  
interactions, though I'm pretty sure you can plugin whatever you like.


Cherrpy is completely agnositic wrt storage and has no built-in orm.  
Overall Cherrypy is much less of an overall framework than Django is.  
With Cherrypy projects I have done my storage has ranged from  
filesystem only, database via SQLAlchemy (which rocks) and database  
via dbapi (which is really only best for special-purpose needs).



Is there a common set of agreed upon requirements for the new website?
This would at least give people a basis to compare things on, and
perhaps as time went on to make decisions on whether cherrypy or
django is a better fit for what we need.


Which of the two systems gives greater control for low level
operations? I'm attempting to learn Ruby on Rails right now to help
with prototyping and speeding up development, and am finding it to be
quite a pain to learn all sorts of very specific ways to manipulate
things. As much fun as it is to have your framework do all the heavy
lifting for you, I think there needs to be a relatively simple way to
jump into the database and play with the SQL code and the interactions
between the website and the database. I'm kind of assuming that both
frameworks allow you to play with the HTML, javascript and CSS easily
if you need to.


Django is definitely higher level than CherryPy. Which is better  
totally depends on what is being done and who is doing it.


-Casey

Re: [pygame] Pygame font issues

[Jake b]

1) Are you using py2exe?

2) Copy-ing the font to the same folder as the game will probably work.

3) I ripped out my font name matching code, it might help. [It might
be easier if you want the whole font wrapper class.]

class Text(object):
"""...code..."""
def __init__(self, text=None, font=None, size=18,color="black",
bold=False, italic=False):
"""font can be:
1) filepath:
"ttf/arial.ttf"
2) list of names to search: ( calls 
self.match_font(list) )
"arial, verdana, freesans"
3) None
use default font
"""
self.screen = pygame.display.get_surface()
self.font_name = font
self.font_size = size   

self.color = pygame.color.Color( color )
self.text = text
self.antialias = True   
self.color_bg = None
self.rect = pygame.Rect(15,15,0,0)

self.match_font('bitstreamverasans, verdana, arial,lucidia 
console')
self._create_font()

def match_font(self, font_list, bold=False, italic=False):
"""pygame.font.match_font() wrapper, but also sets the font. 
You can
call with a commma deliminated list. It chooses the first valid 
font."""
filename = pygame.font.match_font(font_list, bold, italic)  

if not filename: # if failed, fallback on one that works
filename = pygame.font.match_font('bitstreamverasans, 
verdana,
arial,lucidia console,freesans, freesansbold') # should at least have
freesans[bold] since it comes with pygame
if( filename ):
self.font_name = filename #was: font_list
self._create_font()

def _create_font(self, font=None):
"""create Font() object"""
try:
self.font = pygame.font.Font( self.font_name, 
self.font_size )
except IOError:
if font:
self.match_font(font) #, bold, italic)


-- 
Jake

Re: [pygame] starting the rewrite

[Jake b]

Maybe we need a vote thread.

1st line: pick your framework
2nd like: amount of work you expect to put in.

No discussion, just vote tallies, so we can see if it's definitely one
sided, and to stick with that. [ keeping discussion in another thread
]

I 2nd shaun. I can write css/php/html, but haven't volunteered yet
since I haven't used django/cherrypy. So I could help if you have
access to that level. [ Haven't written a website in py yet, but it
sounds fun. ]
-- 
Jake

Re: [pygame] vector type: mutable or immutable

[Jake b]

Could you make both? Default to mutable, and use VectorConst ( insert
better name ) where needed.

.offset = Vector3Const(1,2,3)
.vel = Vector3( offset )

(throw exception when you try to modify a const vector?)
-- 
Jake

Re: [pygame] starting the rewrite

[Shaun Mahood]

As much fun as it is to watch everyone split apart to do their own
thing, I have a few questions (not knowing anything about either
Django or cherrypy).

Do both of the frameworks "hide" all the database interactions? If
possible, it could save a ton of headaches later on if a database
structure could be set for both teams to develop on. If there were a
common set of methods written as well to interact with the database,
then you would have a whole lot of common sections between the two
rewrites.

Is there a common set of agreed upon requirements for the new website?
This would at least give people a basis to compare things on, and
perhaps as time went on to make decisions on whether cherrypy or
django is a better fit for what we need.

Which of the two systems gives greater control for low level
operations? I'm attempting to learn Ruby on Rails right now to help
with prototyping and speeding up development, and am finding it to be
quite a pain to learn all sorts of very specific ways to manipulate
things. As much fun as it is to have your framework do all the heavy
lifting for you, I think there needs to be a relatively simple way to
jump into the database and play with the SQL code and the interactions
between the website and the database. I'm kind of assuming that both
frameworks allow you to play with the HTML, javascript and CSS easily
if you need to.

I think everyone involved is definitely smart enough to create a very
good website no matter what framework is chosen. For saving the
learning curve of future collaborators, I would put my vote to the
framework that allows the easiest low level manipulation without
having to learn a whole ton of extra stuff (thankfully for everyone,
my vote doesn't count :)

Good luck to everyone
Shaun




On Fri, May 1, 2009 at 10:40 AM, René Dudfield  wrote:
> On Fri, May 1, 2009 at 8:49 PM, Marcus von Appen  wrote:
>> On, Fri May 01, 2009, Nicholas Dudfield wrote:
>>>
>>> Has everyone decided that Django is to be used?
>>
>> From my perspective it was (more or less) settled to go with Django, if
>> Julian and Orcun (and pretty much everyone else, who wants to work on
>> the rewrite) are more comfortable with it than with something else.
>>
>> As far as I can see, noone else explicitly voted against it, but instead
>> cherrypy was mentioned as an alternative.
>> Personally, as I can read from Julian's and Orcun's GSoC proposals, they
>> have a lot of ideas with Django and how to implement the website with
>> it.
>>
>> In order to have a solid solution, I strongly support Django here for
>> the obvious (already mentioned) reasons of having two skilled developers
>> for it.
>>
>> Regards
>> Marcus
>>
>
>
> hi,
>
>
> the discussion never reached a conclusion for me... code just started
> being written.
>
> When the website rewrite process started in late January, cherrypy was
> suggested by pymike.
> http://groups.google.com/group/pygame-mirror-on-google-groups/browse_thread/thread/34a561e3ac7ebc26/1b36d71a37af7216
>
> Also in the rewrite thread cherrypy was suggested by me and Nicholas.
> Other people have said they were happy with either.  We also got a
> promise of support from the main author of cherrypy in case we have
> any nasty problems, and there was another offer of help from another
> person on the cherrypy mailing list to actually help writing the
> website.
>
> There are more than just two people interested in joining the website rewrite.
>
> I think there are more of the most active pygame contributors
> interested in contributing to a cherrypy based website.
>
>
> Since the other website rewrite has been started without concluding
> our discussion,  I too am just going to go forward and write a new
> website for pygame.org.
>
> As one of the people who has been maintaining pygame for a long time,
> and who has also made some(small) changes to the current website code,
> and written many pages on the website - I hope other people join the
> cherrypy based effort.
>
>
> May the best website win!
>
>
> cu,
>

Re: [pygame] vector type: mutable or immutable

[Casey Duncan]

On May 1, 2009, at 8:07 AM, Lorenz Quack wrote:


Hi

as a follow up to the "API draft for vector type" I would like to  
discuss the merits of having a mutable or immutable vector type.



Arguments for an immutable vector type:

Brian Fisher pointed out two advantages of immutable vector types:
1) they prevent bugs in programs like the following (adopted from  
Brian):

> class Angel(object)
> def __init__(self, offset):
> self.offset = offset
>
> t = Angel()
> halo_pos = t.offset
> halo_pos.y -= 5  # BUG: this changes the offset in t

2) if vectors are immutable you can use them as keys in dicts



Arguments for a mutable vector type:

1) operations such as rotate() and scale_to_length() are more  
elegant when operation in-place. for immutable types you would have  
to do "v = v.rotate()" or use a module level rotate function "v =  
pygame.math.rotate_vector(v)" or something similar.


2) a priori I would expect mutable vectors to perform better than  
immutable ones because you don't have to create new objects for  
every operation.




So are there anymore arguments?
And where do people stand on this issue?


I think that less memory management overhead and batch operations are  
strong arguments for mutable vectors.


The predicability of immutable vectors is nice, but IMO the  
convenience and flexibility of mutable vectors, along with the  
consistency with existing type like Rect makes them win.


I would argue that it should be possible to treat vectors as immutable  
if you preferred that, which I think is covered by the features  
proposed so far.


-Casey

Re: [pygame] pygame 2001-2009(8 years), 1100+ projects at super speed.

[Casey Duncan]

8^)

On May 1, 2009, at 10:29 AM, René Dudfield wrote:


hellos,

I have put together a video representing some of the pygame work out  
there.


Enjoy!http://www.youtube.com/watch?v=Qu2Tuo3HPbo

Re: [pygame] starting the rewrite

[René Dudfield]

On Fri, May 1, 2009 at 8:49 PM, Marcus von Appen  wrote:
> On, Fri May 01, 2009, Nicholas Dudfield wrote:
>>
>> Has everyone decided that Django is to be used?
>
> From my perspective it was (more or less) settled to go with Django, if
> Julian and Orcun (and pretty much everyone else, who wants to work on
> the rewrite) are more comfortable with it than with something else.
>
> As far as I can see, noone else explicitly voted against it, but instead
> cherrypy was mentioned as an alternative.
> Personally, as I can read from Julian's and Orcun's GSoC proposals, they
> have a lot of ideas with Django and how to implement the website with
> it.
>
> In order to have a solid solution, I strongly support Django here for
> the obvious (already mentioned) reasons of having two skilled developers
> for it.
>
> Regards
> Marcus
>


hi,


the discussion never reached a conclusion for me... code just started
being written.

When the website rewrite process started in late January, cherrypy was
suggested by pymike.
http://groups.google.com/group/pygame-mirror-on-google-groups/browse_thread/thread/34a561e3ac7ebc26/1b36d71a37af7216

Also in the rewrite thread cherrypy was suggested by me and Nicholas.
Other people have said they were happy with either.  We also got a
promise of support from the main author of cherrypy in case we have
any nasty problems, and there was another offer of help from another
person on the cherrypy mailing list to actually help writing the
website.

There are more than just two people interested in joining the website rewrite.

I think there are more of the most active pygame contributors
interested in contributing to a cherrypy based website.


Since the other website rewrite has been started without concluding
our discussion,  I too am just going to go forward and write a new
website for pygame.org.

As one of the people who has been maintaining pygame for a long time,
and who has also made some(small) changes to the current website code,
and written many pages on the website - I hope other people join the
cherrypy based effort.


May the best website win!


cu,

[pygame] pygame 2001-2009(8 years), 1100+ projects at super speed.

[René Dudfield]

hellos,

I have put together a video representing some of the pygame work out there.

Enjoy!http://www.youtube.com/watch?v=Qu2Tuo3HPbo

Re: [pygame] starting the rewrite

[Mikhail Ramendik]

I am a professional tech writer/editor and will gladly review any docs that
need reviewing - just direct me to them.


2009/5/1 jug 

> Hello,
>
> Today, I started to write some first lines of code for the new 
> pygame.orgwebsite and
> just checked it into SVN. For further questions I'd like to create tickets
> in the
> development-trac (and maybe write here a mail with a link).
> We are still searching for a web-designer, so please help us.
> Over again, please write your name to the list there if you'd like to
> participate.
>
>
> Regards
> Julian
>
>
>


-- 
Yours, Mikhail Ramendik

Re: [pygame] starting the rewrite

[Devon Scott-Tunkin]

>We are still searching for a web-designer, so please help us.
>Over again, please write your name to the list there if you'd like to 
>>participate.

which list where? err what's the link?

I thought I got on the google list, and then I tried to join the first one 
(trac?) but it never sent me the e-mail.

I don't have a lot of web design experience, but I am trying to get some. I 
currently work mostly as a print designer (while also going to grad school for 
game dev), but I know css/html well enough. I can make some photoshop mockups 
for different styles for people to discuss, or hack the current pygame css to 
look pretty in the meantime. I assume there will be a basic css template 
eventually (possibly more) for the whole site with django generating the html 
from a database, but I am not familiar with django or web backends beyond some 
basic php/mysql.

Devon

my website is minimal and very static. I don't like the design much anymore, 
but it does have an interesting css menu system.

http://www.devonscott-tunkin.com

I managed to make my wikka wiki look pretty recently, but since it's a personal 
wiki I haven't yet fixed some of the ie bugs and other rough patches that 
require php hacking:

http://wiki.devonscott-tunkin.com/


--- On Thu, 4/30/09, jug  wrote:

> From: jug 
> Subject: [pygame] starting the rewrite
> To: pygame-users@seul.org
> Date: Thursday, April 30, 2009, 7:08 PM
> Hello,
> 
> Today, I started to write some first lines of code for the
> new pygame.org website and
> just checked it into SVN. For further questions I'd like to
> create tickets in the
> development-trac (and maybe write here a mail with a
> link).
> We are still searching for a web-designer, so please help
> us.
> Over again, please write your name to the list there if
> you'd like to participate.
> 
> 
> Regards
> Julian
> 
> 
> 


  

Re: [pygame] vector type: mutable or immutable

[René Dudfield]

hrmmm.  Good question.

Thinking in terms of how much I use lists VS tuples...
   I'd use mutable lists for 96% of cases...  but occasionally
would like to use an immutable tuple.

Another argument is that Rect, Surface, and Color are mutable - so it
would be somewhat consistent with the other types.

Note that Sprite, and Surface are mutable, but can be used as
dictionary keys.  They don't use their values as the keys.

However Rect can not be used for keys... so that's an inconsistency -
but maybe a good one.  Since generally you would want to use the
values of the Rect as the keys - so it forces a conversion to tuple.

I wonder how much effort it would be to make immutable and mutable?  I
think maybe too much.

overall... +1 for mutable.




cu,


On Sat, May 2, 2009 at 12:07 AM, Lorenz Quack  wrote:
> Hi
>
> as a follow up to the "API draft for vector type" I would like to discuss
> the merits of having a mutable or immutable vector type.
>
>
> Arguments for an immutable vector type:
>
> Brian Fisher pointed out two advantages of immutable vector types:
> 1) they prevent bugs in programs like the following (adopted from Brian):
>> class Angel(object)
>>     def __init__(self, offset):
>>         self.offset = offset
>>
>> t = Angel()
>> halo_pos = t.offset
>> halo_pos.y -= 5  # BUG: this changes the offset in t
>
> 2) if vectors are immutable you can use them as keys in dicts
>
>
>
> Arguments for a mutable vector type:
>
> 1) operations such as rotate() and scale_to_length() are more elegant when
> operation in-place. for immutable types you would have to do "v =
> v.rotate()" or use a module level rotate function "v =
> pygame.math.rotate_vector(v)" or something similar.
>
> 2) a priori I would expect mutable vectors to perform better than immutable
> ones because you don't have to create new objects for every operation.
>
>
>
> So are there anymore arguments?
> And where do people stand on this issue?
>
>
> yours
>
> //Lorenz
>

Re: [pygame] vector type: mutable or immutable

[Stuart Axon]

I guess mutable is more consistent with the rest of the api (things
like rect IIRC)

2009/5/1 Lorenz Quack :
> Hi
>
> as a follow up to the "API draft for vector type" I would like to discuss
> the merits of having a mutable or immutable vector type.
>
>
> Arguments for an immutable vector type:
>
> Brian Fisher pointed out two advantages of immutable vector types:
> 1) they prevent bugs in programs like the following (adopted from Brian):
>> class Angel(object)
>>     def __init__(self, offset):
>>         self.offset = offset
>>
>> t = Angel()
>> halo_pos = t.offset
>> halo_pos.y -= 5  # BUG: this changes the offset in t
>
> 2) if vectors are immutable you can use them as keys in dicts
>
>
>
> Arguments for a mutable vector type:
>
> 1) operations such as rotate() and scale_to_length() are more elegant when
> operation in-place. for immutable types you would have to do "v =
> v.rotate()" or use a module level rotate function "v =
> pygame.math.rotate_vector(v)" or something similar.
>
> 2) a priori I would expect mutable vectors to perform better than immutable
> ones because you don't have to create new objects for every operation.
>
>
>
> So are there anymore arguments?
> And where do people stand on this issue?
>
>
> yours
>
> //Lorenz
>

[pygame] vector type: mutable or immutable

[Lorenz Quack]

Hi

as a follow up to the "API draft for vector type" I would like to discuss the 
merits of having a mutable or immutable vector type.



Arguments for an immutable vector type:

Brian Fisher pointed out two advantages of immutable vector types:
1) they prevent bugs in programs like the following (adopted from Brian):
> class Angel(object)
> def __init__(self, offset):
> self.offset = offset
>
> t = Angel()
> halo_pos = t.offset
> halo_pos.y -= 5  # BUG: this changes the offset in t

2) if vectors are immutable you can use them as keys in dicts



Arguments for a mutable vector type:

1) operations such as rotate() and scale_to_length() are more elegant when 
operation in-place. for immutable types you would have to do "v = v.rotate()" 
or use a module level rotate function "v = pygame.math.rotate_vector(v)" or 
something similar.


2) a priori I would expect mutable vectors to perform better than immutable 
ones because you don't have to create new objects for every operation.




So are there anymore arguments?
And where do people stand on this issue?


yours

//Lorenz

[pygame] nokia s60 branch merge...

[René Dudfield]

hello,

I have spoken to Jussi Toivola, about merging his pys60 branch into
trunk before pygame 1.9 is released.

So... the process we have decided is to slowly merge in changes... in
small groups if possible.  This will allow us to discuss his changes,
and to try and make sure things still build and run ok on various
platforms.

We can discuss any issues on the mailing list as they come up.

Is this ok?  Lenard... what do you think?   How does this go with the
py3k branch?  Should we try and merge more of that first... or at the
same time... or after?



cheers,

Re: [pygame] starting the rewrite

[Marcus von Appen]

On, Fri May 01, 2009, Nicholas Dudfield wrote:

> 
> > Hello,
> >
> > Today, I started to write some first lines of code for the new 
> > pygame.org website and
> > just checked it into SVN. For further questions I'd like to create 
> > tickets in the
> > development-trac (and maybe write here a mail with a link).
> > We are still searching for a web-designer, so please help us.
> > Over again, please write your name to the list there if you'd like to 
> > participate.
> >
> >
> > Regards
> > Julian
> >
> >
> >
> Julian,
> 
> Has everyone decided that Django is to be used?

From my perspective it was (more or less) settled to go with Django, if
Julian and Orcun (and pretty much everyone else, who wants to work on
the rewrite) are more comfortable with it than with something else.

As far as I can see, noone else explicitly voted against it, but instead
cherrypy was mentioned as an alternative.
Personally, as I can read from Julian's and Orcun's GSoC proposals, they
have a lot of ideas with Django and how to implement the website with
it.

In order to have a solid solution, I strongly support Django here for
the obvious (already mentioned) reasons of having two skilled developers
for it.

Regards
Marcus


pgp6R4GVWkEHt.pgp
Description: PGP signature

Re: [pygame] Pygame font issues

[Peter Chant]

On Friday 01 May 2009, René Dudfield wrote:
> where is freesansbold.ttf on your system?  It should be installed with
> pygame.

bash-3.1$ locate freesansbold.ttf
/usr/lib/python2.5/site-packages/pygame/freesansbold.ttf



-- 
Peter Chant
http://www.petezilla.co.uk

Re: [pygame] pygame.midi

[Peter Gebauer]

Hi!

Yes, I also discovered it's using portmidi. I'll check it and the python 
bindings
for more info, thanks!

/Peter

On 2009-05-01 (Fri) 08:08, René Dudfield wrote:
> Hello,
> 
> it uses portmidi, so best to look at that for capabilities.  Also to
> ask on that mailing list for advanced usage.
> 
> 1(not sure of capability detection), 3 ,4 I know of to be true.  Not
> sure of 2, or 5.
> 
> You can download either the source, and build that.  Or you can
> download prebuilt win/mac versions.  You should be able to take just
> the pypm.pyd or pypm.so, and the midi.py... the midi.py might have
> some dependencies on other parts of pygame.  Consider the pypm
> private, and an implementation detail... it might dissapear to be
> replaced by a different one later.
> 
> There's an examples/midi.py with example listing, input and output.
> The documentation hasn't quite been finished yet, but is mostly done
> as docstrings in lib/midi.py
> 
> It's still unfinished, so maybe it will have a few issues and the API
> may change slightly, but expected to stabalise after the pygame 1.9
> release due in approximately 6 weeks.
> 
> Any bug reports, and patches welcome!
> 
> 
> cu,
> 
> 
> On Fri, May 1, 2009 at 12:51 AM, Peter Gebauer
>  wrote:
> > Hello!
> >
> > I recently wrote an application for configuration of Akai's USB EWI
> > and I used PyAlsa's (Python extension of Alsa) sequencer API.
> > After tracking down and fixing at least three bugs (most of which
> > concerning segfaults tediously tracked down in gdb) and mailing
> > back and forth the maintainer I realized it would take a lot of
> > time and energy since I have no easy access to apply patches.
> > I also realized porting would be an issue. Enter pygame.
> >
> > So, enough background, here are some questions: I'm sending
> > NRPN's and Sysex's, does the following functionality work
> > in pygame.midi?
> >
> > 1) List connected MIDI devices (if possible with capabilities)
> > 2) Connect duplex (read/write)
> > 3) Send events
> > 4) Read events
> > 5) List active port connections
> > 6) What other dependencies will be added to Linux, OSX and Windows
> >
> > Is it possible to download just the midi module somewhere and build
> > it to work with my current version of pygame (1.8.1-3)?
> >
> > Anybody else interrested in EWI's who might want to add support for
> > their device, maybe we can work it in with my Akai project.
> >
> > /Peter
> >