Re: unsubscribe

Re: Pygame2 SDL_mixer segmentation fault

On, Mon Jan 18, 2010, Evan Kroske wrote:

> I'm running 64-bit Ubuntu Karmic Koala with Linux kernel version
> 2.6.31-17-generic, and I get a segmentation fault when I call
> pygame2.sdlmixer.init(). Has anybody else compiled the latest Pygame2 svn
> revision and used sdlmixer on a 64-bit system? Here's the gdb output:
[...]

It looks, like opening the audio device requires thread support on some
platforms. I changed the sdlmixer.open_audio() call to support threads,
which seems to fix the problem.
While working on that, sdlmixer.init() was changed to support the
optional INIT_FLAC/INIT_MOD... arguments properly, so do not forget to
initialize sdlmixer with something like:

    import pygame2.sdlmixer as sdlmixer
    import pygame2.sdlmixer.constants as const
    ...
    sdlmixer.init (const.INIT_FLAC|const.INIT_MOD...)
    ...

if you want support for additional audio formats.

The changes are committed in SVN revision 2740.

Regards
Marcus

BUG: The behavior of the Group.has method vs. its documentation

In the pygame.sprite module, I think that the Group.has method does not behave according to its
documentation. The online documentation states that Group.has will return True if the Group contains
ALL of the given sprites. However, in a certain case, Group.has will return True if the Group contains ANY
of the given sprites. In the following interactive code example, grp1.has(spr1, spr2) should return
False, but it returns True:

>>> import pygame
>>> spr1 = pygame.sprite.Sprite()
>>> spr2 = pygame.sprite.Sprite()
>>> grp1 = pygame.sprite.Group(spr1)
>>> grp1.has(spr1)
True
>>> grp1.has(spr2)
False
>>> grp1.has(spr2, spr1)
False
>>> grp1.has(spr1, spr2)
True
>>> 

I'm already in the process of tidying up the pygame.sprite module so that it'll make fewer function calls,
make fewer hash table look-ups and conform to PEP 8 better. So far, I haven't made any changes that could
break any existing code, but if I change the AbstractGroup.has code to match the documentation, then
someone's game could break if it depends on the incorrect behavior of Group.has.

Would it be OK with all of you if I change Group.has to match the documentation? 

Thanks,
Jason

Re: BUG: The behavior of the Group.has method vs. its documentation

On Mon, Feb 1, 2010 at 7:15 PM, Jason M. Marshall <jmm0@...> wrote:
> In the pygame.sprite module, I think that the Group.has method does not behave according to its
documentation. The online documentation states that Group.has will return True if the Group contains
ALL of the given sprites. However, in a certain case, Group.has will return True if the Group contains ANY
of the given sprites. In the following interactive code example, grp1.has(spr1, spr2) should return
False, but it returns True:
>
>>>> import pygame
>>>> spr1 = pygame.sprite.Sprite()
>>>> spr2 = pygame.sprite.Sprite()
>>>> grp1 = pygame.sprite.Group(spr1)
>>>> grp1.has(spr1)
> True
>>>> grp1.has(spr2)
> False
>>>> grp1.has(spr2, spr1)
> False
>>>> grp1.has(spr1, spr2)
> True
>>>>
>
> I'm already in the process of tidying up the pygame.sprite module so that it'll make fewer function calls,
make fewer hash table look-ups and conform to PEP 8 better. So far, I haven't made any changes that could
break any existing code, but if I change the AbstractGroup.has code to match the documentation, then
someone's game could break if it depends on the incorrect behavior of Group.has.
>
> Would it be OK with all of you if I change Group.has to match the documentation?
>
> Thanks,
> Jason
>

Best to fix the docs, and add another method.

Also, there are not full unittests for the sprite module, so it would
be good to get some unittests completed first... so that it would be
sure to catch any errors with your refactoring.

cu,

Re: BUG: The behavior of the Group.has method vs. its documentation

On Mon, 1 Feb 2010 19:42:38 +0800, René Dudfield <renesd@...> wrote:
> On Mon, Feb 1, 2010 at 7:15 PM, Jason M. Marshall <jmm0@...>
wrote:
>> In the pygame.sprite module, I think that the Group.has method does not
>> behave according to its documentation. The online documentation states
>> that Group.has will return True if the Group contains ALL of the given
>> sprites. However, in a certain case, Group.has will return True if the
>> Group contains ANY of the given sprites. In the following interactive
>> code example, grp1.has(spr1, spr2) should return False, but it returns
>> True:
>>
>>>>> import pygame
>>>>> spr1 = pygame.sprite.Sprite()
>>>>> spr2 = pygame.sprite.Sprite()
>>>>> grp1 = pygame.sprite.Group(spr1)
>>>>> grp1.has(spr1)
>> True
>>>>> grp1.has(spr2)
>> False
>>>>> grp1.has(spr2, spr1)
>> False
>>>>> grp1.has(spr1, spr2)
>> True
>>>>>
>>
>> I'm already in the process of tidying up the pygame.sprite module so
>> that it'll make fewer function calls, make fewer hash table look-ups
and
>> conform to PEP 8 better. So far, I haven't made any changes that could
>> break any existing code, but if I change the AbstractGroup.has code to
>> match the documentation, then someone's game could break if it depends
on
>> the incorrect behavior of Group.has.
>>
>> Would it be OK with all of you if I change Group.has to match the
>> documentation?
>>
>> Thanks,
>> Jason
>>
> 
> 
> Best to fix the docs, and add another method.
> 
> Also, there are not full unittests for the sprite module, so it would
> be good to get some unittests completed first... so that it would be
> sure to catch any errors with your refactoring.
> 

But the current behavior seems to be inconsistent, i.e. it depends on the
order of the sprites. 
Compare the two last examples Jason provided.
Too me, that seems to be a bug.
I also just realized an interesting behavior:

>>> grp1.has()
None

shouldn't that either raise an exception or return True like grp1.has([])
does?

//Lorenz

Re: BUG: The behavior of the Group.has method vs. its documentation

Unfortunately, correcting the documentation will make it complicated. If we correct the documentation,
then we'll have to explain why Group.has checks for membership of ANY sprites that are passed as arbitrary
arguments but checks for membership of ALL sprites that are passed as objects within an iterable.

>>> grp1.has(spr1, spr2)
True
>>> grp1.has([spr1, spr2])
False

Since the actual implementation is nuanced, would it still be best to update the documentation rather than
change the code? (We could consider the nuance a feature!)

unittests are a good idea. I'll add those.

Jason

----- Original Message ----
From: René Dudfield <renesd@...>
To: pygame-users@...
Sent: Mon, February 1, 2010 5:42:38 AM
Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its  documentation

On Mon, Feb 1, 2010 at 7:15 PM, Jason M. Marshall <jmm0@...> wrote:
> In the pygame.sprite module, I think that the Group.has method does not behave according to its
documentation. The online documentation states that Group.has will return True if the Group contains
ALL of the given sprites. However, in a certain case, Group.has will return True if the Group contains ANY
of the given sprites. In the following interactive code example, grp1.has(spr1, spr2) should return
False, but it returns True:
>
>>>> import pygame
>>>> spr1 = pygame.sprite.Sprite()
>>>> spr2 = pygame.sprite.Sprite()
>>>> grp1 = pygame.sprite.Group(spr1)
>>>> grp1.has(spr1)
> True
>>>> grp1.has(spr2)
> False
>>>> grp1.has(spr2, spr1)
> False
>>>> grp1.has(spr1, spr2)
> True
>>>>
>
> I'm already in the process of tidying up the pygame.sprite module so that it'll make fewer function calls,
make fewer hash table look-ups and conform to PEP 8 better. So far, I haven't made any changes that could
break any existing code, but if I change the AbstractGroup.has code to match the documentation, then
someone's game could break if it depends on the incorrect behavior of Group.has.
>
> Would it be OK with all of you if I change Group.has to match the documentation?
>
> Thanks,
> Jason
>

Best to fix the docs, and add another method.

Also, there are not full unittests for the sprite module, so it would
be good to get some unittests completed first... so that it would be
sure to catch any errors with your refactoring.

cu,

Re: BUG: The behavior of the Group.has method vs. its documentation

PS. Actually, I just realized that Group.has only checks the membership of the first sprite when I call
grp1.has(spr1, spr2). It's not checking the membership of any of the arguments after the first one. This
makes me even more certain that it would be preferable to change the code.

----- Original Message ----
From: Jason M. Marshall <jmm0@...>
To: pygame-users@...
Sent: Mon, February 1, 2010 6:28:59 AM
Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its  documentation

Unfortunately, correcting the documentation will make it complicated. If we correct the documentation,
then we'll have to explain why Group.has checks for membership of ANY sprites that are passed as arbitrary
arguments but checks for membership of ALL sprites that are passed as objects within an iterable.

>>> grp1.has(spr1, spr2)
True
>>> grp1.has([spr1, spr2])
False

Since the actual implementation is nuanced, would it still be best to update the documentation rather than
change the code? (We could consider the nuance a feature!)

unittests are a good idea. I'll add those.

Jason

----- Original Message ----
From: René Dudfield <renesd@...>
To: pygame-users@...
Sent: Mon, February 1, 2010 5:42:38 AM
Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its  documentation

On Mon, Feb 1, 2010 at 7:15 PM, Jason M. Marshall <jmm0@...> wrote:
> In the pygame.sprite module, I think that the Group.has method does not behave according to its
documentation. The online documentation states that Group.has will return True if the Group contains
ALL of the given sprites. However, in a certain case, Group.has will return True if the Group contains ANY
of the given sprites. In the following interactive code example, grp1.has(spr1, spr2) should return
False, but it returns True:
>
>>>> import pygame
>>>> spr1 = pygame.sprite.Sprite()
>>>> spr2 = pygame.sprite.Sprite()
>>>> grp1 = pygame.sprite.Group(spr1)
>>>> grp1.has(spr1)
> True
>>>> grp1.has(spr2)
> False
>>>> grp1.has(spr2, spr1)
> False
>>>> grp1.has(spr1, spr2)
> True
>>>>
>
> I'm already in the process of tidying up the pygame.sprite module so that it'll make fewer function calls,
make fewer hash table look-ups and conform to PEP 8 better. So far, I haven't made any changes that could
break any existing code, but if I change the AbstractGroup.has code to match the documentation, then
someone's game could break if it depends on the incorrect behavior of Group.has.
>
> Would it be OK with all of you if I change Group.has to match the documentation?
>
> Thanks,
> Jason
>

Best to fix the docs, and add another method.

Also, there are not full unittests for the sprite module, so it would
be good to get some unittests completed first... so that it would be
sure to catch any errors with your refactoring.

cu,

Re: BUG: The behavior of the Group.has method vs. its documentation

I suggest that Group.has() and Group.has([]) should always return True. Consider the behavior
of Python's built-in set type:

>>> set1 = set((0, 1, 2, 3))
>>> set2 = set(())
>>> set1.issuperset(set2)
True

>>> set1 = set(())
>>> set2 = set(())
>>> set1.issuperset(set2)
True

Jason

----- Original Message ----
From: "don <at> amberfisharts.com" <don@...>
To: pygame-users@...
Sent: Mon, February 1, 2010 5:54:31 AM
Subject: Re: [pygame] BUG: The behavior of the Group.has method vs. its documentation

But the current behavior seems to be inconsistent, i.e. it depends on the
order of the sprites. 
Compare the two last examples Jason provided.
Too me, that seems to be a bug.
I also just realized an interesting behavior:

>>> grp1.has()
None

shouldn't that either raise an exception or return True like grp1.has([])
does?

//Lorenz

Re: unsubscribe

write sound to file for fast loading?