Coder Social home page Coder Social logo

pygame-community / pygame-ce Goto Github PK

View Code? Open in Web Editor NEW
672.0 672.0 111.0 37.9 MB

🐍🎮 pygame - Community Edition is a FOSS Python library for multimedia applications (like games). Built on top of the excellent SDL library.

Home Page: https://pyga.me

Makefile 0.09% Python 41.43% Shell 0.58% C 55.50% Cython 1.97% Meson 0.43%
game-dev game-development gamedev pygame python sdl sdl2

pygame-ce's People

Contributors

ankith26 avatar bydariogamer avatar charlesej avatar dependabot[bot] avatar dlon avatar dr0id avatar etrepum avatar grimmys avatar illume avatar itzpr3d4t0r avatar llindstrom avatar marcusva avatar matiiss avatar mightyjosip avatar myremylar avatar notpygame avatar novialriptide avatar nthykier avatar oddbookworm avatar petershinners avatar pmp-p avatar puritylake avatar robertpfeiffer avatar siggisv avatar starbuck5 avatar sublimator avatar takluyver avatar temmie3754 avatar yunline avatar zoldalma999 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pygame-ce's Issues

Surface.subsurface segfaults on a dead surface (2)

Issue №2 opened by illume at 2011-08-12 17:44:39

Originally reported by: Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom)


The Surface.subsurface method fails to check if the surface is alive. The result is a Pygame parachute.

>>> import pygame
>>> s = pygame.Surface.__new__(pygame.Surface)
>>> ss = s.subsurface((0, 0, 0, 0))
Fatal Python error: (pygame parachute) Segmentation Fault
Aborted


Comments

# # illume commented at 2011-08-12 23:08:37

Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):


The problem: in ^^surf_subsurface()^^, ^^surf->format^^ is assigned to ^^format^^ before ^^surf^^ is checked if ^^NULL^^.


# # illume commented at 2011-08-24 16:42:51

Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):


Fixed <<changeset 38cdc3d7302a>>.

Case closed.

Segmentation fault with register_quit (20)

Issue №20 opened by illume at 2011-08-22 09:39:40

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Markos Gogoulos, 2008-08-06 23:57:53 -0700

register_quit results in segfault, check the following:

import pygame

def foo():
    pass

pygame.register_quit(foo)
exit()
Segmentation fault


[784.028418] python[14917]: segfault at 00000008 eip 0811270c esp bf899310 error 4


Tested on Ubuntu hardy with python 2.5.2. I was unable to run pygame 1.8 properly on my system to test is as well. 

Best regards,
Markos Gogoulos

== Lenard Lindstrom, 2009-01-29 18:47:39 -0800

Python 2.5.4, Windows 98, Pygame 1.9.0.

This is also a Windows bug. The example code causes a page fault.

PYTHON caused an invalid page fault in
module PYTHON25.DLL at 015f:1e0711a9.

A Windows related register_quit crash was also noted by Brian Fisher at the automated build site when the Pygame unit test suite was run as a single process. The crash involved __PYGAMEinit__ in base_test.py registering pygame_quit for every pygame.init() call after the base_test.py tests ran. The automated builds started crashing after I added a pygame.init() to surfarray_test.py without a corresponding pygame.quit() call. I found the same problem on my machine, with the error dialog appearing at program completion. The crashes stopped when I pairing every pygame.init() with a pygame.quit() in surfarray_test.py (rev 1874).

== Lenard Lindstrom, 2009-02-06 21:49:29 -0800

Quoted directly from the Python 2.5.4 Python/C API Reference Manual

"5.2 Process Control 

....

int Py_AtExit( void (*func) ()) 

Register a cleanup function to be called by Py_Finalize(). The cleanup function will be called with no arguments and should return no value. At most 32 cleanup functions can be registered. When the registration is successful, Py_AtExit() returns 0; on failure, it returns -1. The cleanup function registered last is called first. Each cleanup function will be called at most once. Since Python's internal finalization will have completed before the cleanup function, no Python APIs should be called by func."

And that is exactly what the Pygame exit function, registered in base.c, does,
it makes Python API calls.

== Lenard Lindstrom, 2009-02-08 11:16:55 -0800

Fixed in revision 1916

Note: Pygame's quit mechanism could stand some reworking at a future date.



Comments

Rect should have a copy method (25)

Issue №25 opened by illume at 2011-08-22 09:39:45

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Nick Welch, 2008-11-21 01:36:44 -0800

The unofficial way, which seems to be in some old documentation cached by google but not in any of the actual documentation anymore, is to do myrect.move(0, 0).  This is non-obvious and mysteriously undocumented now.  A Rect.copy() method is much clearer and should be trivial to implement.

== Nick Welch, 2008-11-21 01:40:46 -0800

Also, Rect(myrect) to do a copy is inconvenient because then it requires an import of Rect in every source file that you want to copy rects in.  A Rect.copy() would lift that requirement, and is in line with Python style, e.g. dict.copy().

== Nick Welch, 2008-11-21 01:48:55 -0800

Err... ok, looking through the docs, there is a copy function available as __copy__ which copy.copy() will use.  So why not just make it Rect.copy() as dict does?

== Lenard Lindstrom, 2009-02-12 12:50:07 -0800

More relevant, it is consistent with Surface.copy.
Added in revision 1924.



Comments

# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

pygame.mixer.music.play only plays once (44)

Issue №44 opened by illume at 2011-08-22 09:40:03

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Joshua, 2010-05-04 20:59:38 -0700

Created attachment 34
Sample script of one example where it does not work.

Using the command pygame.mixer.music.play() only plays the background once no matter what parameter is given.  -1 will cause it to only play once.  > 1 will still only cause it to play once.  I have only tried this with a .mid file.  pygame.mixer.Sound works as it should.

Attachments:
[[http://www.pygame.org/old_bug_attachments/34/dodger.py| dodger.py]]



Comments

# # illume commented at 2011-09-06 16:58:08

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Reported to SDL bug tracker:
http://bugzilla.libsdl.org/show_bug.cgi?id=934

The work around is to loop manually in your main loop by checking if get_busy() is false, and if so play the music again.


# # illume commented at 2012-01-01 05:50:38

Original comment by Anonymous:


FYI, this is fixed for the next SDL_mixer release.

pygame.mixer.music.load doesn't work with unicode symbols in path (37)

Issue №37 opened by illume at 2011-08-22 09:39:56

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Vasiliy, 2009-09-01 11:32:23 -0700

This method doesn't work with unicode symbols in os path.
For example:
audiofile = u'D:/Work/Projects/Programming/iTutor/src/iTutor/dictionaries/Казахо - Русский/3.mp3'
pygame.mixer.music.load(audiofile)

return error:
pygame.error: Couldn't read from 'D:/Work/Projects/Programming/iTutor/src/iTutor/dictionaries/Казахо - Русский/3.mp3'

if i'm delete 'Казахо - Русский/' from audiofile variable then method working normally.



Comments

# # illume commented at 2011-09-06 16:26:45

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


This works with oggs and wavs on OSX.

I assume this is another smpeg error. Or perhaps a windows related error.

== Needs testing on windows.


# # illume commented at 2011-09-13 01:31:31

Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):


According to the Python 2.7 //sys.getfilesystemencoding()// docs no encoding is done to the file path. So the UTF-16 Python string is just passed through. I don't know what encoding Windows uses, thought.


# # illume commented at 2011-09-20 13:26:48

Original comment by Anonymous:


I think this might be a bytes/unicode misunderstanding:
I've tested this only on linux, on an utf8 filesystem, but
pygame.mixer.music.load('')
worked, whereas
pygame.mixer.music.load(u'')
didn't., but
pygame.mixer.music.load(u''.encode('utf8'))
again did.


# # illume commented at 2015-07-16 17:33:16

Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):


My plan is to wrap pygame.mixer.music.load and pygame.mixer.music.queue with a function that uses Python's built-in open function to open Unicode paths.


# # illume commented at 2015-07-16 17:35:38

Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):


Issue # 247 was marked as a duplicate of this issue.


# # illume commented at 2015-07-16 19:18:13

Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):


Actually, the .encode('utf8') trick from Anonymous works on Windows for music.


# # illume commented at 2016-06-01 11:03:12

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


I've found the relevant source in music.c, and it's using RWopsEncodeFilePath to turn a unicode path into a bytes path. This is OK on Unix systems where paths are bytes, but Windows paths are unicode (handled as UTF-16). The 'filesystem encoding' on Windows is 'mbcs', which refers to the current system codepage. However, the typical default codepages (e.g. cp1252 for Western European languages) cannot represent all characters that might be in a path, so encoding a path is lossy. The right fix would be to open files using the unicode/wchar path on Windows.

I haven't tested this, but it looks like it should be possible to work around this by opening the file object in Python first:

with open(path) as f:
    pygame.mixer.music.load(f)

I think Python's open function uses unicode paths on Windows.

Mixer.init claims it takes no kw args, documentation differs. (6)

Issue №6 opened by illume at 2011-08-22 09:39:27

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== James Pettit, 2008-02-16 19:29:03 -0800

Trying out the new sndarray/numpy features and stereo sound. Very short script with error message:

from pygame import mixer, sndarray
from numpy import array

mixer.init(stereo=2)

sndarray.use_array('numpy')
sound = sndarray.make_sound(array([(x, 2*x) for x in xrange(22050)], dtype='int16'))

Traceback (most recent call last):
  File "pygame_snd.py", line 4, in <module>
    mixer.init(stereo=2)
TypeError: init() takes no keyword arguments

== illume, 2008-02-27 19:48:53 -0800

In general pygame functions, and documentation do not support kw args, but the documentation does show defaults.

This should be fixed in the 1.9 release of pygame, to make it more friendly.

== Lenard Lindstrom, 2009-01-29 18:12:01 -0800

Done in revision 1893.



Comments

# # illume commented at 2017-01-11 10:21:42

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: svn (automated comment)

Memory leak with pygame.transform functions (34)

Issue №34 opened by illume at 2011-08-22 09:39:53

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Victor Freire, 2009-06-14 13:52:40 -0700

Created attachment 24
Code demonstrating the leak and the image used.

When using the following pygame.transform functions: scale(), smoothscale() and flip(), memory leaks occur.

Scaling a texture a hundred times per frame consumes a LOT of memory, rendering me unable to use such functions in my game.

I've attached a rar with the code that causes this and the image used.

Operating System: Windows XP SP3
Python version: 2.6.1
Pygame 1.8.1 (the package available at the download section)

Attachments:
[[http://www.pygame.org/old_bug_attachments/24/leaktest.rar| leaktest.rar]]

== illume, 2009-06-28 21:44:16 -0700

With pygame 1.9.0rc1, and python2.5.2 on OSX I can not reproduce this.

Maybe it is a windows, or python2.6 specific bug, or perhaps it has been fixed.

Are you able to try this out with a new pygame?

Binaries here:
  http://thorbrian.com/pygame/builds.php

== Victor Freire, 2009-06-30 18:30:25 -0700

I have been able to bypass this in my game by reusing the same surface, not creating a new temporary one for each loop iteration.

I've tested this in 2.5.2 so it's not only in 2.6.

I'll try the new pygame version when I get some spare time.

== Victor Freire, 2009-06-30 18:45:11 -0700

Created attachment 25
Leak 'workaround' and another leak case

In this .rar there is a 'workaround' for the leak and a sligthly different test case in which leaking also occurs.

Tested with the original configuration.

Attachments:
[[http://www.pygame.org/old_bug_attachments/25/Leaktests.rar| Leaktests.rar]]



Comments

# # illume commented at 2011-09-06 14:51:48

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


The test appears to use pygame.transform.scale when it leaks.

I made this test case from the one given. Then testsed it on OSX, and it does not leak memory. The memory stays between 20MB and 22MB according to activity monitor.

== Stand alone test case (needs testing in windows XP (or windows Vista/7).

import pygame, pygame.examples, time, os
pygame.init()
main_dir = os.path.split(os.path.abspath(pygame.examples.__file__))[0]
data_dir = os.path.join(main_dir, 'data')
image_path = os.path.join(data_dir, "arraydemo.bmp")

screen = pygame.display.set_mode((640, 480), 0, 32)
slice_h = 40
test_tile = pygame.image.load(image_path).convert()
slicescaled = pygame.Surface((1, slice_h))

going = True
while going:
    going = pygame.QUIT not in [e.type for e in pygame.event.get()]

    screen.fill((0, 0, 0)) # clear screen
    for x in xrange(100):
        texoffset = x
        slicepiece = pygame.Surface((1, 128))
        slicepiece.blit(test_tile, (0,0), (texoffset, 0, 1, 128))
        pygame.transform.scale(slicepiece, (1, slice_h), slicescaled)
        screen.blit(slicescaled, (x, 10))
    pygame.display.flip()
    pygame.time.wait(10)
pygame.quit()

# # illume commented at 2011-09-06 15:53:07

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Tested by two people, one on windows 7 and another on XP. No memory leak now.

White lines as called from aaline draw in yellow. (46)

Issue №46 opened by illume at 2011-08-22 09:40:04

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== John M, 2010-05-17 20:46:06 -0700

Created attachment 35
Result of attached code.

Something to do with Snow Leopard? Maybe this should be passed upstream to the SDL-guys but I was baffled.

Drawing over black background, a white line is drawn in yellow.

Very easy to reproduce:
import pygame
screen = pygame.display.set_mode( (200, 200), 0, 32 )
pygame.draw.line( screen, (255, 255, 255), (0,0), (100, 100) )
pygame.draw.aaline( screen, (255, 255, 255), (0,100), (100, 200) )
pygame.display.update()


I've attached what this produces.

Attachments:
[[http://www.pygame.org/old_bug_attachments/35/aalineBug.png| aalineBug.png]]



Comments

# # illume commented at 2011-09-05 16:29:44

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Here is an easier to run example, that also shows the problem is to do with the screen surface and the draw routine.

import pygame
from pygame.locals import *
pygame.init()
screen = pygame.display.set_mode( (200, 200), 0, 32 )
surf = screen
print "screen info", surf.get_masks(), surf.get_shifts(), surf.get_pitch(), surf.get_losses()
surf = pygame.Surface( (200,200), 0, 32)
print "surface info", surf.get_masks(), surf.get_shifts(), surf.get_pitch(), surf.get_losses()

surf.fill((0,0,0,255))
pygame.draw.line( surf, (255, 255, 255), (0,0), (100, 100) )
pygame.draw.aaline( surf, (255, 255, 255), (0,100), (100, 200) )
screen.blit(surf, (0,0))

going = True
while going:
    events = pygame.event.get()
    if QUIT in [e.type for e in events]:
        going = False
    pygame.display.update()

On OSX Lion 64bit python it prints:

screen info (65280, 16711680, 4278190080, 0) (8, 16, 24, 0) 800 (0, 0, 0, 8)
surface info (16711680, 65280, 255, 0) (16, 8, 0, 0) 800 (0, 0, 0, 8)

So we can see that the screen surface, and a normal software surface is laid out differently. So there must be an issue with the draw.aaline method and this type of memory layout.

The example above shows a work around, of blitting to a normal surface and then blitting that surface to the screen. This works as expected and gives a white line, not a yellow one.


# # illume commented at 2012-07-07 16:09:10

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Seems fixed in the repository.


# # carlosgmartin commented at 2018-05-30 16:30:15

I'm getting the same problem with version 1.9.3.

support display.set_mode((0, 0)) (11)

Issue №11 opened by illume at 2011-08-22 09:39:31

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Lorenz Quack, 2008-03-08 07:45:03 -0800

Created attachment 6
support display.set_mode((0,0))

[quote from the SDL_SetVideoMode docs]
As of SDL 1.2.10, if width and height are both 0, it will use the width and height of the current video mode (or the desktop mode, if no mode has been set).
[/quote]

The patch adds support for this behavior to pygame. 
It also makes the (w, h) argument optional.

Attachments:
[[http://www.pygame.org/old_bug_attachments/6/display.diff| display.diff]]

== Thorbrian, 2008-03-09 14:57:00 -0700

marcus modified to support either width or height being 0 with the other arg non-zero, and committed rev. 1150



Comments

# # illume commented at 2017-01-11 10:21:42

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: svn (automated comment)

Enabling OpenGL display, causes different behavior for system events (40)

Issue №40 opened by illume at 2011-08-22 09:39:59

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Thomas Hansen, 2009-11-20 21:12:38 -0800

If I enable OpenGL on my display, teh evebnt system starts behaving differntly.  The following code prints all the events I am interrested in if i do not enable OpenGL.  If I enable it however, events from the touchscreen and stylus are not reaching the event queue.  

Note that this also happens for the simulated mouse events that windows generates for these input devices. When I dont enable OpenGL, and just get the normal mouse events (no fancy windows touchwindow, or using pymt.SYWMEVENT), everything is fine.  If I enable OpenGL however, mouse events are not generated when I use touch or stylus (although they move/controll the system mouse cursor) 

I am using pygame 1.9.1 with Python 2.6.2 on Windows 7.


import pygame
import ctypes

# if I uncomment this line, the window does not produce teh same events
# without it it works just fine!!
# display_flag = pygame.OPENGL

pygame.display.quit()
pygame.display.init()
pygame.display.set_mode((320, 240) display_flag)
pygame.event.set_allowed(pygame.SYSWMEVENT)

pygame.display.set_caption('pymt')
hwnd = ctypes.windll.user32.FindWindowA(None, "pymt")
ctypes.windll.user32.RegisterTouchWindow(hwnd, 0)

while True:
    for event in pygame.event.get():
        if event.type == pygame.SYSWMEVENT:
            print event



Comments

# # illume commented at 2011-09-05 18:22:51

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


This is an SDL issue, or pymt issue. I'm guessing pymt needs to be modified to work with SDL opengl windows.

Closing.

Please reopen if you are still interested.


# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

Font.render() raises a TypeError if background is None (49)

Issue №49 opened by illume at 2011-08-22 09:40:07

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== John, 2010-05-25 20:25:21 -0700

The documentation says that Font.render()'s background argument defaults to None, however if None actually used it raises an exception:

TypeError: Invalid background RGBA argument

This became problematic when I wanted to extend the default Font class with my own render function. I can't simply accept a background argument with a default value of None and pass it on to the original renderer, if the background is None then the argument has to be excluded completely.

== Marco Chieppa, 2010-07-01 08:01:17 -0700

Created attachment 36
proposed patch font render for enable background=None

based on revision 2827

Attachments:
[[http://www.pygame.org/old_bug_attachments/36/pygame_font.c_patch| pygame_font.c_patch]]

== Marco Chieppa, 2010-07-01 16:32:41 -0700

Created attachment 37
test for attachment 36

Attachments:
[[http://www.pygame.org/old_bug_attachments/37/font_test2.py| font_test2.py]]



Comments

# # illume commented at 2011-09-05 16:58:15

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Font.render can set backgound to None. Fixes # 49.
Thanks John and Marco Chieppa!


# # illume commented at 2013-04-02 19:19:53

Original comment by Sami Loone (Bitbucket: dryatu, GitHub: dryatu):


This bug still occurs in pygame-1.9.2a0.win32-py2.7

Compatability bug(s) with virtual mouse input mode when running synergy server (15)

Issue №15 opened by illume at 2011-08-22 09:39:35

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Thorbrian, 2008-05-23 03:47:18 -0700

When running synergy http://synergy2.sourceforge.net/ on a windows xp or vista machine, virtual mouse input mode (automatically on when either mouse grabbed and cursor invisible or fullscreen and cursor invisible) gets all broken. The mouse moves wrong and seems to want to stick to the edge of the window.

The attached script can be used to play with mouse grab, fullscreen and cursor visible

== Thorbrian, 2008-05-23 03:47:59 -0700

Created attachment 10
a test script to play with mouse and fullscreen settings

Attachments:
[[http://www.pygame.org/old_bug_attachments/10/test_buffer.py| test_buffer.py]]

== illume, 2008-05-26 16:37:19 -0700

Hi,

I think this bug should be reported to SDL and synergy bug trackers.

cu,

== Thorbrian, 2008-05-26 18:06:14 -0700

link to synergy bug:
http://sourceforge.net/tracker/index.php?func=detail&aid=1973818&group_id=59275&atid=490467

== Thorbrian, 2008-05-26 21:25:46 -0700

link to SDL bug:
http://bugzilla.libsdl.org/show_bug.cgi?id=590

== illume, 2009-05-27 00:58:35 -0700

No activity from either synergy or sdl at their respective given bug report links.
2009-05-27



Comments

# # illume commented at 2011-09-06 16:17:04

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Closing as wontfix. It is a synergy bug according to the SDL bug tracker.

Color input is inconsistent (45)

Issue №45 opened by illume at 2011-08-22 09:40:03

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== John, 2010-05-09 21:11:41 -0700

I'm using Pygame 1.9 with Python 3.1. The inconsistency with color input is slightly irritating. For example, Pygame.Color() accepts a variety of different input types. It accepts HTML style colors, tuples of integers, and hexadecimals. This is nice, but other parts of Pygame code don't use this. For example, Surface.fill() only accepts a tuple or a Color instance. I can't use the hexadecimal styles. I myself often make the mistake of using the wrong style of color and need to look up the documentation. I think consistency is extremely important for any software, especially a library for an elegant language like Python.



Comments

# # illume commented at 2011-09-06 17:40:53

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Marking as an enhancement proposal.

It would be nice to be able to do things like this:

surf.fill('black')
surf.fill('# FFEECCF0')

I've often wanted this feature myself, and others have suggested it before.

This needs some thought, and a lot of testing to see what side effects this could have. Also, we need to decide on scheduling if this is a much wanted feature or not, and how much work it would take to implement/test.


# # illume commented at 2012-02-14 18:45:49

Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):


This request would take significant refactoring, particularly in pygame.base and pygame.color and pygame.pixelarray. The simplest approach is to add '' and '# ' handling to _RGBAFromColorObj. Then anything in Pygame that accepts a color value would also take a string. It would also mean

# !python
pixel_array[...] = 'black'

would be allowed. I recall some objection to that, but if it is not a problem I can tackle this issue.

Lenard

Segfault when using surfarray and Numpy. (7)

Issue №7 opened by illume at 2011-08-22 09:39:28

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== James Pettit, 2008-02-17 13:49:18 -0800

Created attachment 3
Script that causes the error described above

The attached script will cause a segfault. It creates a Surface called "screen" and gets the pixels2d array for that surface. Calling "del array" to delete the surface array causes the error to disappear, so the error may be a result of trying to free read-only memory during pygame.quit(). SVN revision 1119.

Attachments:
[[http://www.pygame.org/old_bug_attachments/3/segfault.py| segfault.py]]

== Thorbrian, 2008-02-18 13:46:11 -0800

Marcus committed a fix in rev. 1120 - please confirm and close if it's fixed for you



Comments

# # illume commented at 2017-01-11 10:21:42

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: svn (automated comment)

pygame.event.post does not work on OS X with PPC binaries (14)

Issue №14 opened by illume at 2011-08-22 09:39:34

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Aaron Gallagher, 2008-04-25 23:33:51 -0700

I've been working on tracking down a bug for a while now and only just was able to attribute it to pygame failing. In my application, calling pygame.event.post simply does nothing if the binaries have been stripped to only contain the ppc code. The i386 code works, but the ppc code does not work on an i386 machine or a ppc machine. I have not yet tried a fat binary on a ppc machine, but I doubt it will make a difference.

Calling pygame.event.post raises no exception, and the event is not received from the event queue. The event queue still receives events normally, though.

My build environment:
OS: Mac OS 10.5.2
Python: 2.5.2, built with "-Wall -fno-strict-aliasing -g -O2 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch i386 -arch ppc -mmacosx-version-min=10.3.9" as CFLAGS and LDFLAGS.
PyObjC: 1.4, built painfully and using the same CFLAGS and LDFLAGS.
py2app: 0.3.6.

== Aaron Gallagher, 2008-04-26 14:46:03 -0700

Created attachment 9
A simple proof-of-concept

This zipfile contains just enough code to demonstrate the bug. You most likely need a version of python linked against the 10.4u SDK. It might also work built on a PPC machine linked with only PPC binaries, but I don't have access to a PPC machine and I can't try it. At any rate, the event posted on mousedown only shows up in the queue from the i386 binary when I build it. Run mkbuild.sh to invoke py2app and separate the resulting bundle into PPC and i386 bundles.

Attachments:
[[http://www.pygame.org/old_bug_attachments/9/pygametest.zip| pygametest.zip]]

== illume, 2008-05-02 16:10:53 -0700

Hello,

thanks for the report and test case.  I'm not near a mac at the moment, but should have access to one later in the week.



In the mean time...

Which version of SDL are you using?

SDL_PushEvent is the function used in SDL.  Are you able to check to see if that works ok by itself?  Then we will be able to see if it is an SDL specific bug, or a pygame specific bug.

I checked on the sdl bug tracker, and found no bugs to do with SDL_PushEvent listed, and I found none on google.

If you find it to be a SDL specific bug please make a bug report here:
http://bugzilla.libsdl.org/



cheers,

== Aaron Gallagher, 2008-05-02 16:38:00 -0700

I did some more testing, and I found that it was something to do with how I was trying to bootstrap my application. If I don't use the runEventLoop function provided by PyObjC, it works fine. I'd say this is a nonissue because I got it to work. If somebody really wanted to look into why it doesn't work, that's fine, but I think it was partly my nonstandard usage of PyObjC with pygame.



Comments

Patch for a small tutorial correction (4)

Issue №4 opened by illume at 2011-08-22 09:39:25

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Jens Rantil, 2008-01-25 10:24:59 -0800

Created attachment 2
Patch against SVN.

The DisplayModes tutorial contains a small typo.

Attachments:
[[http://www.pygame.org/old_bug_attachments/2/DisplayModes.html.diff| DisplayModes.html.diff]]

== Thorbrian, 2008-01-25 23:30:12 -0800

fixed in svn 1088



Comments

# # illume commented at 2017-01-11 10:21:42

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: svn (automated comment)

Add support for macports dependencies to pygame setup (12)

Issue №12 opened by illume at 2011-08-22 09:39:32

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Peter Enzerink, 2008-03-08 21:31:35 -0800

PNG and JPEG are installed and available via macports but are not detected by the installer because the current config_darwin.py only looks in /usr/local whereas macports uses /opt/local.

Patch adds additional paths for macports headers and libraries.

== Peter Enzerink, 2008-03-08 21:32:30 -0800

Created attachment 7
Patch to add macports paths

Attachments:
[[http://www.pygame.org/old_bug_attachments/7/macports.diff| macports.diff]]

== Thorbrian, 2008-03-09 20:24:54 -0700

committed 1151. Peter, please confirm it works for you now and close bug if it does.

== Peter Enzerink, 2008-03-09 21:48:53 -0700

All good. One step closer to making pygame a little easier on mac.



Comments

usability: no lists of bugs (23)

Issue №23 opened by illume at 2011-08-22 09:39:43

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== , 2008-10-10 22:05:31 -0700

there doesn't seem to be an easy way to list all submitted bugs.

see https://bugs.launchpad.net/gcalctool as example:
Filters
Open 	       14
Critical 	0
New 	        2
Unassigned     14
All bugs ever reported 	54

I had to use the advanced search because you can't make a blank search on the normal search form to find any bugs.

== James Paige, 2008-10-15 08:34:04 -0700

At http://pygame.motherhamster.org/ there is a link labelled "All Open Bugs" which leads you directly to this list:

http://pygame.motherhamster.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&deadlinefrom=&deadlineto=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&known_name=All+Open+Bugs&query_based_on=All+Open+Bugs&field0-0-0=noop&type0-0-0=noop&value0-0-0=

== illume, 2009-05-26 02:03:43 -0700

hi,

I updated the bugzilla link on this page:
http://pygame.org/wiki/patchesandbugs

To point to here: http://pygame.motherhamster.org/

Hopefully that'll solve that usability issue, since people will be directed to the easier to use page from the main pygame.org page.


Closing bug.


cu,



Comments

# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

pygame-1.9.1release - endian problem saving an image in png format (39)

Issue №39 opened by illume at 2011-08-22 09:39:58

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Jens Restemeier, 2009-09-08 12:09:36 -0700

Created attachment 28
Example test script

When saving an image in png format the channels seem to be reversed. I attached
a script, on Windows they produce the same image, on OSX/powerpc they produce
the attached images,

Attachments:
[[http://www.pygame.org/old_bug_attachments/28/pngtest.py| pngtest.py]]

== Jens Restemeier, 2009-09-08 12:10:43 -0700

Created attachment 29
PNG test image produced on MacOS powerpc

Attachments:
[[http://www.pygame.org/old_bug_attachments/29/test.png| test.png]]

== Jens Restemeier, 2009-09-08 12:11:31 -0700

Created attachment 30
TGA test image produced on MacOS powerpc - this is how it should look like.

Attachments:
[[http://www.pygame.org/old_bug_attachments/30/test.tga| test.tga]]



Comments

# # illume commented at 2011-09-06 17:24:09

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Thanks Jens.

Here is the test code inline the comment to make it easier to see.

import pygame, os
from pygame.locals import *

#  Set SDL to use the dummy NULL video driver,
#    so it doesn't need a windowing system.
os.environ["SDL_VIDEODRIVER"] = "dummy"

if True:
    #  Some platforms need to init the display for some parts of pygame.
    import pygame.display
    pygame.display.init()
    screen = pygame.display.set_mode((1,1))

def main():
    test = pygame.Surface((256, 256), flags=SRCALPHA, depth=32)
    for y in xrange(256):
        for x in xrange(256):
            test.set_at((x, y), (x,y,(x + y) % 256, (((x ^ y) >> 4) & 1) * 127 + 128))
    for ext in ["tga", "png", "bmp", "jpg"]:
        pygame.image.save(test, "test.%s" % ext)

if __name__ == "__main__":
    main()

It seems the set_at() call does some bit fiddling, which I'm weary of.

Also need to confirm this fails on PPC, which I don't have access too test on.

The test could be changed to read the lossless formats like tga, png and bmp to make sure they read back the colours correctly. Then this could be used as a unit test easily.


# # illume commented at 2012-07-07 07:27:05

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Fixed SDL_BIG_ENDIAN bug for png write. Fixes and closes # 39


# # illume commented at 2014-04-21 22:14:40

Original comment by Olivier Pirson (Bitbucket: OPiMedia, GitHub: OPiMedia):


I have the same problem (save PNG reverse channels) with this configuration:

  • Debian Wheezy AMD 64
  • Python 3.2.3 (default, Feb 20 2013, 14:44:27) [GCC 4.7.2]
  • Pygame 1.9.2a0

It's ok with:

  • Python 2.7.3 (default, Mar 13 2014, 11:03:55) [GCC 4.7.2]
  • Pygame 1.9.1release

# # illume commented at 2014-12-13 07:00:27

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Merged in OPiMedia/pygame (pull request # 30)

Bug fix: Red and green channels inversion on AMD 64 (see issue # 39).


# # illume commented at 2014-12-13 07:00:27

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Bug fix: Red and green channels inversion on AMD 64 (see issue # 39).


# # illume commented at 2014-12-13 07:00:27

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Merged in OPiMedia/pygame (pull request # 30)

Bug fix: Red and green channels inversion on AMD 64 (see issue # 39).


# # illume commented at 2017-01-11 10:21:45

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

8bpp surface blitting looses colors (32)

Issue №32 opened by illume at 2011-08-22 09:39:52

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== 3TATUK, 2009-04-25 01:59:13 -0700

The attached code will produce ten 64x64 blocks of color,
the first nine being:
white, white/black, red, orange, yellow, green, blue, indigo, and violet
the white comes from the background screen being filled with white, so the first and second blocks are really: transparent and transparent/black

the first two color entries in the palette are both black, but index 0 is used as the color key.

When blitting image1 (the transparent/black) one to special_image surface.. basically, all pixel values of '\x01' are converted to '\x00' because it does an index lookup or some type of bug.

Basically the desired results are the last block to look just like the second (transparent/black) block via a blit() copy. I know this can easily be done with non-8bpp screen/surfaces, but I 8bpp still exists and should work properly. (My project requires it specifically, also)

You can see what is happening to the pixel data by writing the following two objects out to files and viewing with a hex editor (like i said all '\x01' become '\x00' (when they should be identical, in my opinion):

pygame.image.tostring( image1 )
pygame.image.tostring( special_image)

== 3TATUK, 2009-04-25 01:59:50 -0700

Created attachment 21
colors lost

Attachments:
[[http://www.pygame.org/old_bug_attachments/21/example.py| example.py]]

== 3TATUK, 2009-04-25 02:45:35 -0700

my second attachment shows something someone figured out to *make* it work, although it's very hackish and a workaround.. not really making any sense and i can't understand what's happening but take a look

== 3TATUK, 2009-04-25 02:46:22 -0700

Created attachment 22
hackish workaround

Attachments:
[[http://www.pygame.org/old_bug_attachments/22/example2.py| example2.py]]

== Thorbrian, 2009-04-26 12:21:47 -0700

Honestly, I don't understand what you are trying to achieve with this example.

However, it looks like the core of the issue here is that you have duplicate color entries in your palette, and you don't like that pygame is picking to represent colors that match that duplicate entry in your destination pixels as the first entry in the palette.

That behavior is not a bug - it's perfectly appropriate for a palette-based system. If you have duplicate color entries in your palette, you've made it impossible to practically distinguish one entry from the next, and you have to expect stuff like this to happen. I'm closing this as not a bug.

My recommendation would be to make every color entry in your palette distinct.



Comments

FrozenPUZZLE is unavailable (22)

Issue №22 opened by illume at 2011-08-22 09:39:42

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== OsamaK, 2008-10-02 19:37:41 -0700

FrozenPUZZLE source code <http://up.servut.us/dl/8830> is unavailable. It should be removed or new source code link added.

== James Paige, 2008-10-03 10:03:36 -0700

This bug tracker is for problems with the source code of the pygame software. For problems with the pygame.org website/wiki/gamelist you should contact Phil Hassey. His contact info is at the bottom of every page at pygame.org



Comments

# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

test\mask_test.py crashes for Python 2.6 (28)

Issue №28 opened by illume at 2011-08-22 09:39:48

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Lenard Lindstrom, 2008-12-16 19:09:42 -0800

Pygame 1.9.0a0 rev 1749
Python 2.6.1
Windows XP

The test\mask_test.py unit test crashed with a Pygame parachute.

The problem has been traced to the test_from_threshold method. It crashed for all pixel sizes, 16, 24 and 32.

== Lenard Lindstrom, 2008-12-16 20:26:49 -0800

Possible fix in SVN rev. 1750
Passes for Python 2.5; needs Python 2.6 test.

== Lenard Lindstrom, 2008-12-23 16:28:24 -0800

Fixed in revision 1750



Comments

# # illume commented at 2017-01-11 10:21:42

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: svn (automated comment)

Calling repr() on Event causes segfault (50)

Issue №50 opened by illume at 2011-08-22 09:40:08

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== , 2010-07-27 00:48:14 -0700

In my pygame application I use a number of user-defined events to pass objects around the different components. These objects turn out to be relatively large sometimes. Every now and then, my application terminated with a segmentation fault but only when logging was active. The reason for this is the event_str function in src/event.c that returns the Event object's representation, e.g for printing it to stdout. It reserves a fixed length (1024) for the string representation which can overflow easily.

The following code illustrates the problem quite well:

import pygame
print pygame.event.Event(pygame.USEREVENT, data=range(1000))



Comments

# # illume commented at 2011-09-05 16:30:36

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


This is fixed in tip.

cursors.load_xbm requires two arguments (17)

Issue №17 opened by illume at 2011-08-22 09:39:37

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Saul Spatz, 2008-06-29 12:01:01 -0700

The documentation says that pygame.cursors.load_xbm has a default seconed argument of None.  Not only is this not so, but the method will crash if given None as a second argument, since it will then call None.readlines().  I'm afraid I don't know enough about cursors to offer a patch, although is seems like setting the default to None and moving everything that relates to the mask inside an "if mask is not None:" guard might be all it takes.

== Thorbrian, 2008-06-29 22:32:25 -0700

Saul, could you please provide a test case of some sort where you would want to call load_xbm without a mask argument?

It would be essential for me to be able to confirm correct behavior, as I don't know anything about xbm cursor files and how they are used. I can certainly code it to avoid an exception, but that's not sufficient - I need to code it to behave correctly.

If we can't find a way to confirm that calling load_xbm without a mask argument behaves correctly and is useful, then this bug will probably instead get resolved by changing the documentation.

== Thomas Ibbotson, 2009-03-26 04:44:53 -0700

I just came across this bug when trying to make my own custom cursor. Here's what I've discovered.

load_xbm takes two arguments, which are files, or filelike objects. The first file is the data corresponding to the black pixels in the cursor, the second file (or maskfile) corresponds to the white pixels. All other pixels are transparent.

Perhaps you want a cursor which is all black and has no white (this wouldn't be a very good cursor as it might get obscured). In that case you might not want to pass an additional maskfile.

In any case the documentation is wrong as a maskfile of None causes an error. Also it states that maskfile is a keyword argument, which it is not.

I would suggest changing the documentation to say that the maskfile argument is a mandatory argument, as cursors with only black pixels should be avoided, but would still be possible by passing a maskfile with no bits set.

== illume, 2009-05-27 00:40:58 -0700

Updated the documentation for this.

Committed revision 2268.


cheers!



Comments

# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

Alpha wrong when blitting with BLEND_RGBA_MULT on Mac OS X (26)

Issue №26 opened by illume at 2011-08-22 09:39:46

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== James Paige, 2008-12-10 12:13:22 -0800

Created attachment 14
Test script to reproduce the problem

I have some code that takes an image, loads it into a surface, and blits an alpha transparent image with BLEND_RGBA_MULT to erase the corners. It works perfectly on Linux and Windows XP, but when I test it on my Mac the corners do not vanish, they just turn yellow. I would guess this means that the colors are mixed up when blitting in this way. The machine in question is a G7 PowerPC Mac. (I don't have access to an Intel Mac) so this could be an endiannness issue.

I am using python 2.5.2 (the python.org build) and pygame 1.8.1release-svn1537

Attachments:
[[http://www.pygame.org/old_bug_attachments/14/test.py| test.py]]

== James Paige, 2008-12-10 12:14:28 -0800

Created attachment 15
kitten.jpg used by the test script

Attachments:
[[http://www.pygame.org/old_bug_attachments/15/kitten.jpg| kitten.jpg]]

== James Paige, 2008-12-10 12:14:54 -0800

Created attachment 16
alpha_corner.png used by the test script

Attachments:
[[http://www.pygame.org/old_bug_attachments/16/alpha_corner.png| alpha_corner.png]]

== James Paige, 2008-12-10 12:15:20 -0800

Created attachment 17
The entire test in a zip file

Attachments:
[[http://www.pygame.org/old_bug_attachments/17/alphatest.zip| alphatest.zip]]

== James Paige, 2008-12-11 08:23:19 -0800

Lenard Lindstrom notes that adding .convert_alpha() to the line that loads alpha_conrer.png avoids this problem.

See: http://comments.gmane.org/gmane.comp.python.pygame/16810

-  corner = pygame.image.load(os.path.join("data", "alpha_corner.png"))
+  corner = pygame.image.load(os.path.join("data", "alpha_corner.png")).convert_alpha()

== Lenard Lindstrom, 2009-02-11 22:35:41 -0800

I believe rev. 1923 fixes this bug. However, it should be verified on a Mac.

== James Paige, 2009-02-12 11:24:32 -0800

I can confirm that this bug is fixed using the nightly build with subversion revision 1923. I tested on the same PowerPC Mac where I originally noticed the bug.



Comments

pygame 1.91 mixer bug (38)

Issue №38 opened by illume at 2011-08-22 09:39:57

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== saehoon, 2009-09-05 01:10:23 -0700

Python version : 3.1
pygame version : 1.91

pygame.mixer.Channel.play(Sound)

crashes with system error.

the same code works with python 2.4 so this could be python bug. I am not sure.

I am reporting just in case and let you guys to see where the actual bug is.

Thanks.



Comments

# # illume commented at 2011-09-06 13:54:55

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Needs testing with python 3.2. python 3.1 is considered obsolete by python.org and by us.

pygame.mixer.Channel.play(Sound) is not a correct way to call the method. However, maybe that was just short hand.

Here is a test case:

import pygame, pygame.examples, time, os
pygame.init()
main_dir = os.path.split(os.path.abspath(pygame.examples.__file__))[0]
data_dir = os.path.join(main_dir, 'data')
a_sound = pygame.mixer.Sound(os.path.join(data_dir, "whiff.wav"))
c = pygame.mixer.Channel(1);
c.play(a_sound)
time.sleep(3)

# # illume commented at 2011-09-06 17:08:23

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Has been tested on windows. So marking as invalid.

Please reopen if you can supply a complete test case showing the problem.


# # illume commented at 2017-01-11 10:21:45

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

Opening a python file object crashes pygame on windows. (10)

Issue №10 opened by illume at 2011-08-22 09:39:31

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== John Krukoff, 2008-03-05 13:25:30 -0800

With pygame 1.7.1 and python 2.5 on Windows XP SP2, when I try to load an image using a python file object instead of passing a path, pygame crashes.

Reproducing is as simple as:

import pygame
pygame.image.load( open( 'image.png', 'r' ) )

While

pygame.image.load( 'image.png' )

works fine, and is what I converted my code to to work around the issue. It looks like this may be a return of an old bug, as I found some notes from years ago on the mailing list about the same kind of crash bug. My previous environment, pygame 1.7 and python 2.4 did not exhibit the same behaviour.

I have not tested with 1.8, as I didn't see a download option for it on the main pygame.org site.

== Thorbrian, 2008-03-05 14:54:58 -0800

This is fixed in latest (pre-release 1.8)

You can download an installer for the latest (again, pre-release) here:
http://thorbrian.com/pygame/builds.php

For a workaround in 1.7.1, see here:
http://archives.seul.org/pygame/users/Nov-2007/msg00133.html

== Thorbrian, 2008-04-14 17:13:51 -0700

1.8 has been released, and has this problem fixed in it.



Comments

compiled cursor shows white as black and black as white. (8)

Issue №8 opened by illume at 2011-08-22 09:39:29

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Thorbrian, 2008-02-22 21:23:50 -0800

originally reported by inahe to the mailing list.

attached is a script that reproduces the problem.

== Thorbrian, 2008-02-22 21:24:35 -0800

Created attachment 4
Test case

Attachments:
[[http://www.pygame.org/old_bug_attachments/4/CursorColorSwap.py| CursorColorSwap.py]]

== illume, 2009-05-27 00:56:50 -0700

Bug confirmed.

Changing:
    cursor = SDL_CreateCursor (anddata, xordata, w, h, spotx, spoty);
to:
    cursor = SDL_CreateCursor (xordata, anddata, w, h, spotx, spoty);

  in mouse.c just makes the cursor all black.


A test needs to be written for :pygame.mouse.set_cursor:  and also for "pygame.cursors.compile"

Likely to be pygame.cursors.compile I think...

Documentation here for SDL_CreateCursor:
  http://sdl.beuc.net/sdl.wiki/SDL_CreateCursor

== Chaitanya Talnikar, 2010-03-29 05:32:01 -0700

In the SDL_CreateCursor documentation, it is given that white is 0 and black is 1, so in the compile function in cursors.py the following line
fillitem = fillitem | 1
should come in the black section of the if block and not in the white section.
This would set the colours right.

== Chaitanya Talnikar, 2010-03-29 05:44:41 -0700

Created attachment 32
Patch for cursors.py

Attachments:
[[http://www.pygame.org/old_bug_attachments/32/cursors.patch| cursors.patch]]



Comments

# # illume commented at 2011-09-06 17:44:27

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


cursors.compile got black and white mixed up for making cursors.

Thanks to Chaitanya Talnikar for the patch.

Fixes # 8


# # illume commented at 2017-01-11 10:21:41

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: svn (automated comment)

Segfault (pygame parachute) on blit (19)

Issue №19 opened by illume at 2011-08-22 09:39:39

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Ed Blake, 2008-08-01 11:44:03 -0700

Pygame 1.8.1 (downloaded yesterday (July 31, 2008))
WinXP, Python 2.5.1

I had a hard time debugging this and tracking it to a specific pygame call, but I finally did it!  My codebase is large, and separated into several modules/layers of abstraction.  I'm not sure exactly what causes the crash, but I know what I was doing in the area it occurs!

def move(self, offsets):
    """Blits the screen surface to itself with the provided offset (in tiles).

    Note: Old tiles are not cleared!
    """
    x = offsets[0] * self.font_width
    y = offsets[1] * self.font_height
    self.surface.set_colorkey()
    self.surface.blit(self.surface, (x, y))
    self.surface.set_colorkey(self._colorkey)
    self.redraw()

This code works the first time it is called for each surface, but on the second call it crashes.  I just tried blitting a surface to itself in an interactive interpreter, but that crashed on the first try!  Also I think the (new in this version?) surface mask is being modified incorrectly/not being cleared by surface.set_colorkey?

Everything works fine in PyGame 1.7 so this is caused by something in the new surface code.

== Thorbrian, 2008-08-02 21:34:40 -0700

This appears to be an SDL bug (it crashes in SDL, and it doesn't seem to happen with SDL 1.2.7). You are experiencing it with the latest pygame because the latest installs SDL 1.2.13. As far as I know, no SDL bug has been created for this (yet).

== Lenard Lindstrom, 2009-01-29 16:35:57 -0800

The bug fix for overlapping blits has been in the SDL SVN for some time. The Windows dependencies for Pygame 1.9.0 use a post 1.2.13 version of SDL (SVN revision 4114) which incorporates the fix.

As for surface mask, that is a separate issue. If it is a genuine bug it will be assigned its own bug report.

== Lenard Lindstrom, 2009-02-13 17:49:40 -0800

Created attachment 19
Test case showing colorkey blit causing tiling with a self blit

To run:

python test.py

The test case shows how blitting a surface with colorkey to itself causes repetitive patterns with a positive offset. Four blue rectangles are displayed when only two are expected.

Attachments:
[[http://www.pygame.org/old_bug_attachments/19/test.py| test.py]]

== Lenard Lindstrom, 2009-02-13 18:06:03 -0800

A follow-up.

The attached test case shows how a blitting a surface with colorkey to itself causes an unexpected result. The image is repeated multiple times. I believe this is what Ed Blake refers to when questioning if the "surface mask is being modified incorrectly/not being cleared by surface.set_colorkey".

This happens when a positive offset is used in a self blit. It was fixed in SDL, but is still a problem with Pygame specific blits, which involve destination alpha or blend blits. The copy overwrites the uncopied part of the surface, which is then copied itself. The solution is to reverse the copy direction in this case. Correcting self blits will be added to Pygame's todo list.

== Lenard Lindstrom, 2009-02-22 22:14:03 -0800

colorkey self blit support finished in rev 1953.



Comments

pygame.image.save can't save in png format (13)

Issue №13 opened by illume at 2011-08-22 09:39:33

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Nick Irvine, 2008-04-11 04:52:11 -0700

Created attachment 8
Bugfix patch

pygame.image.save doesn't save to the correct format.  This code should demonstrate:

import pygame

# original test file is a 320x240 88.7kB png file 
im = pygame.image.load('/tmp/img0.png')

# yields img1.png, 13.0kB jpeg file
pygame.image.save(im, '/tmp/img1.png')

# yields img2.PNG, 191.5 kB TGA file
pygame.image.save(im, '/tmp/img2.PNG')

# yields img3.tga, 191.5 kB TGA file
pygame.image.save(im, '/tmp/img3.tga')

# yields img4/jpeg, 13.0 kB jpeg file
pygame.image.save(im, '/tmp/img4.jpeg')

# end of script

I believe the problem lies in src/imageext.c, around line 450.  I've attached a patch which I believe fixes the problem.

Attachments:
[[http://www.pygame.org/old_bug_attachments/8/imageext.c| imageext.c]]

== Nick Irvine, 2008-04-11 04:53:28 -0700

By the way, this is one of my first patches ever, so comments on the way I've submitted it are welcome.

== Thorbrian, 2008-04-12 13:58:26 -0700

committed 1205

Nick, please confirm in that revision.

... as far as feedback on the patch goes - what you submitted is a patched file, which is not the same thing as a patch. Subversion can produce patches for you with the diff command.

Your test script was great, btw - turns out there was also a problem with saving .JPEG files (would save as TGA's)

== Nick Irvine, 2008-04-13 02:13:53 -0700

I actually did create a diff, but attached the wrong file.  D'oh!



Comments

# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

pygame.sprite.DirtySprite.__repr__: Invalid reference to 'self.__g' (18)

Issue №18 opened by illume at 2011-08-22 09:39:38

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Håkan Johansson, 2008-06-30 02:52:10 -0700

When looking at the code I noticed that the '__repr__' method of the 'DirtySprite' class uses the 'self.__g' attribute. The problem is that this attribute does not exist for the 'DirtySprite' class. It is a member of the 'Sprite' class but is not easily accessed by subclasses.

It is very easy to reproduce the error. Just start Python (any recent version will do):
>>> import pygame
>>> sp = pygame.sprite.DirtySprite()
>>> repr(sp)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/lib/python2.5/site-packages/pygame/sprite.py", line 213, in __repr__
    return "<%s DirtySprite(in %d groups)>" % (self.__class__.__name__, len(self.__g))
AttributeError: 'DirtySprite' object has no attribute '_DirtySprite__g'


A simple fix is to replace 'len(self.__g)' with 'len(self.groups())'.

== Thorbrian, 2008-07-01 01:43:42 -0700

committed 1441, thanks Hakan!



Comments

error while uploading bmp screenshot to pygame.org project (41)

Issue №41 opened by illume at 2011-08-22 09:40:00

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== , 2009-11-22 22:59:45 -0800

Created attachment 31
The error message.

I tried to upload a bmp file as a screenshot for a project on the website and got the attached error message.

Attachments:
[[http://www.pygame.org/old_bug_attachments/31/error.txt| error.txt]]

== , 2009-11-22 23:02:18 -0800

png works fine by the way.



Comments

# # illume commented at 2011-09-05 18:23:39

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Hello,

yeah, png files or jpeg files should be used.


# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

Example fonty.py crashes with "double free or corruption" on line "font.set_underline(0)" (36)

Issue №36 opened by illume at 2011-08-22 09:39:55

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== A.C.Heron, 2009-08-13 15:28:22 -0700

Example programs fonty.py which come with pygame (pygame-1.9.1release/examples/fonty.py in file pygame-*release.tar.gz) crash with error message:
*** glibc detected *** python: double free or corruption
right after the line “screen.blit(ren, (10, 40 + size[1]))” while executing “font.set_underline(0)”.

Observed on pygame versions 1.8.1 and 1.9.1. Python version 2.6.2-r1, Freetype version  2.3.9-r1, SDL version 1.2.13-r1, SDL-TTF version 2.0.9, Gentoo Linux x86-64.

== A.C.Heron, 2009-08-13 15:33:06 -0700

Created attachment 26
Program output after a crash

Attachments:
[[http://www.pygame.org/old_bug_attachments/26/fonty-output.txt| fonty-output.txt]]

== A.C.Heron, 2009-08-13 15:34:31 -0700

Created attachment 27
Output of "strace python fonty.py"

Attachments:
[[http://www.pygame.org/old_bug_attachments/27/fonty-strace.txt| fonty-strace.txt]]



Comments

# # illume commented at 2011-09-05 18:27:58

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Hi,

this needs testing by a gentoo user.

python -m pygame.examples.fonty


# # illume commented at 2011-09-20 14:47:38

Original comment by Anonymous:


Well, there seems to be some catch here.
My pygame is a bit out of date, as it's still 1.9.1, even though that version went out of the tree awhile ago.

However, if I take fonty.py straight out of the old tarball, I'm unable to reproduce the crash.
Though my system differs significantly from one in the original report:
x86, python-2.7.2-r2, freetype-2.4.6, llibsdl-1.2.14-r6, sdl-ttf-2.0.10.

Though I've seen the post on the mailing list from a user that could reproduce it.
However, pygame-1.9.2_pre3082, that's now in the tree, is a quite recent addition, so I should be able to reproduce, if it were still possible.

Given certain bug, glibc version might matter here - my tests are on 2.13-r4 (the revision will be significant here, if it's that bug).


# # illume commented at 2012-02-14 18:10:35

Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):


This looks like the issue I had with [[http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594824|SDL_ttf 2.0.9 on Debian squeeze]]. It was fixed in [[http://hg.libsdl.org/SDL_ttf/rev/0f803b00e43b|SDL_ttf 2.0.10]].


# # illume commented at 2012-07-07 15:41:33

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Can't reproduce. Looks like it's an old SDL_ttf bug like Lenard says... so closing.

pygame.error: No available video device (31)

Issue №31 opened by illume at 2011-08-22 09:39:51

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== , 2009-04-15 21:42:14 -0700

Traceback (most recent call last):
  File "C:\dpf\AssemblyLine-0.4\run_game.py", line 13, in <module>
    main.main()
  File "C:\dpf\AssemblyLine-0.4\Game\Code\main.py", line 19, in main
    display = pygame.display.set_mode(settings.screen_size, settings.flags)
pygame.error: No available video device

all pygame dependencies installed

== illume, 2009-05-27 00:44:41 -0700

Hi,

looks possibly related to this bug report:
http://groups.google.com/group/pygame-mirror-on-google-groups/browse_thread/thread/423f1d7f3e909c38

Are you able to confirm which version of windows you're on?  


cu,

== Pygame XP, 2011-03-25 06:38:46 -0700

(In reply to comment # 1)
> Hi,
> looks possibly related to this bug report:
> http://groups.google.com/group/pygame-mirror-on-google-groups/browse_thread/thread/423f1d7f3e909c38
> Are you able to confirm which version of windows you're on?  
> cu,

Hi cu,

I'm having the same issue on an XP machine.  When I execute
pygame.display.init() in the shell, I receive (5,1) rather than (6,0)
and when I try to execute pygame.display.set_mode I receive
pygame.error: No available video device.

Is there a way to determine what module is failing in the init() call?

tu,

Pygame XP



Comments

# # illume commented at 2011-09-07 06:40:48

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


import os
os.environ['SDL_VIDEODRIVER']='windib'

I think maybe we should finally switch to windib being the default even on XP. We could try some complicated scheme to try to init the display with directx first in a separate process and if that fails we try windib... but I guess that might be failure prone too.


# # illume commented at 2011-09-13 01:12:53

Original comment by Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom):


The SDL Direct X driver is unreliable. 'windib' is the SDL default. How 'directx' behaves probably depends on which version of Direct X is installed. It would seem Microsoft has given up maintaining compatibility with Direct X 5.


# # illume commented at 2011-12-14 04:26:20

Original comment by Anonymous:


Its a miracle! lol thanks illume for the code! I had issues getting my game working using the pygame library, and this fixed it!


# # illume commented at 2012-01-25 04:39:22

Original comment by Anonymous:


**i was having the same problem too, can somebody help me out, i was working for a pygame project, a lil bit explanation for me to understand it well.. plzzzzz and thanks!!


# # illume commented at 2012-07-12 03:56:25

Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):


I think it's time to make windib the default renderer for Windows XP. With that change, we'll be able to close this issue. In my opinion, the productivity losses due to directx renderer bugs outweigh the performance advantage of the directx renderer on some hardware.

Complicated try-directx-except-windib logic would not be a good idea because sometimes after the directx renderer fails, only a system reboot can restore the PC to proper working order.
http://article.gmane.org/gmane.comp.python.pygame/17527/match=%22system%20reboot%20cleared%22

This is how I think the renderer-choosing logic should work:

Windows 95/98/Me without DirectX 5 or greater → windib

Windows 95/98/Me with DirectX 5 or greater → directx

Windows NT/2000/XP/Vista/7/8... → windib

I'll implement the change if @illume doesn't object to my approach.


# # illume commented at 2012-07-16 13:55:32

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Sounds good to me :)


# # illume commented at 2012-07-25 09:00:06

Original comment by Jason Marshall (Bitbucket: jmm0, GitHub: jmm0):


I have changed pygame/_ init _.py so that windib is the default video driver for almost all Windows users.

blit_array() fails with a 24 bit surface (24)

Issue №24 opened by illume at 2011-08-22 09:39:44

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Lenard Lindstrom, 2008-10-22 13:31:06 -0700

Created attachment 13
Test program that reproduces blit_array() bug.

Pygame-1.9.0a0 (rev. 1668)
numpy 1.0.4
Python 2.5.2

pygame.surfarray.blit_array() raises an exception when a 3d array is copied to a 24 bit surface. The test program is attached.

Traceback (most recent call last):
  File "array_bug.py", line 6, in <module>
    pygame.surfarray.blit_array(s, a)
  File "C:\PRG\PYTHON25\lib\site-packages\pygame\surfarray.py", line 260, in bli
t_array
    return numpysf.blit_array (surface, array)
  File "C:\PRG\PYTHON25\lib\site-packages\pygame\_numpysurfarray.py", line 381,
in blit_array
    (array[:,:,1::3] >> losses[1] << shifts[1]) | \
TypeError: unsupported operand type(s) for >>: 'float' and 'int'

Attachments:
[[http://www.pygame.org/old_bug_attachments/13/array_bug.py| array_bug.py]]

== Lenard Lindstrom, 2009-01-22 01:28:17 -0800

Fixed in SVN revision 1851.



Comments

# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

Building pygame from source fails if no X11 installed (29)

Issue №29 opened by illume at 2011-08-22 09:39:49

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Robert A. Lerche, 2009-03-29 13:20:17 -0700

Created attachment 20
patch to fix compilation errors when X11 not installed

Environment: Linux from Scratch 6.4, SDL 1.2.13, pygame-1.8.1release, *NO* X11.

Symptom: compilation errors in display.c and event.c, for example

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -D_REENTRANT -I/usr/X11R6/include -I/usr/include/SDL -I/usr/include/python2.6 -c src/display.c -o build/temp.linux-i686-2.6/src/display.o
src/display.c: In function 'get_wm_info':
src/display.c:325: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:329: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:333: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:337: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:341: error: 'SDL_SysWMinfo' has no member named 'info'
src/display.c:345: error: 'SDL_SysWMinfo' has no member named 'info'

Solution: use SDL's SDL_VIDEO_DRIVER_X11 symbol instead of !DISABLE_X11 (patch attached).

There are 3 references to DISABLE_X11: display.c, event.c, and scrap.c.  The patch fixes all 3 but I haven't tested scrap.c because I haven't included scrap.

Attachments:
[[http://www.pygame.org/old_bug_attachments/20/pygame-patch| pygame-patch]]

== Thorbrian, 2009-04-26 12:28:25 -0700

Rene, you use Linux right? can you confirm the patch?

== illume, 2009-07-12 23:36:47 -0700

Committed revision 2504.

cheers!



Comments

Pygame segfaults when attempting to save jpeg to folder that does not exist (16)

Issue №16 opened by illume at 2011-08-22 09:39:36

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Devin Jeanpierre, 2008-05-26 00:11:47 -0700

The expected behavior for saving a file to a folder that doesn't exist is to raise a pygame.error . This does happen when I attempt to save in .tga format, however, with .jpg, it causes a segmentation fault. I can save .jpg files to folders that do exist. Here is what I ran in my interpreter to show this:
----
Python 2.5.1 (r251:54863, May  4 2007, 16:52:23) 
[GCC 4.1.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygame
>>> pygame.init()
(6, 0)
>>> pygame.ver
'1.8.0release'
>>> pygame.image.get_extended()
1
>>> surf = pygame.Surface((100,100))
>>> pygame.image.save(surf, 'surf.jpg')
>>> pygame.image.save(surf, 'this/folder/doesnt/exist/test.tga')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
pygame.error: Couldn't open this/folder/doesnt/exist/test.tga
>>> pygame.image.save(surf, 'this/folder/doesnt/exist/test.jpg')
Fatal Python error: (pygame parachute) Segmentation Fault
Aborted
----
A suitable example script, then, would be:
----
#!/usr/bin/env python

import pygame
pygame.init()
surf = pygame.Surface((100,100))
pygame.image.save(surf, 'this/folder/doesnt/exist/test.jpg')
print "You made it!"
----

I left most of these admin-type values alone. I don't expect myself to be able to judge how bad the developers think this problem is, and I don't know what 'P5' or 'P4' is. Anyway, I hope I was as thorough as possible.

== Devin Jeanpierre, 2008-05-26 00:13:36 -0700

Created attachment 11
Test case as shown in bug report

Attachments:
[[http://www.pygame.org/old_bug_attachments/11/pygametest.py| pygametest.py]]

== Thorbrian, 2008-05-26 12:23:02 -0700

fixed rev. 1248 - the crash was happening on any jpeg or png save error, actually, thanks for catching it



Comments

setup.py exits with zero exit code when failing (35)

Issue №35 opened by illume at 2011-08-22 09:39:54

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Sridhar Ratnakumar, 2009-07-24 17:50:35 -0700

> python setup.py install --root=i1

WARNING, No "Setup" File Exists, Running "config.py"
Using UNIX configuration...

Hunting dependencies...
sh: sdl-config: not found
WARNING: "sdl-config" failed!
sh: smpeg-config: not found
WARNING: "smpeg-config" failed!
Unable to run "sdl-config". Please make sure a development version of SDL is installed.
> echo $?
0
> 

***

I am automatically building the packages in PyPI for some reason; and relying on the exit code of setup.py to see if a build failed or not. Your package (pygame) is the only aberration I've come across. 

Try using "sys.exit(1)" or "raise SystemExit, 'Unable to run ....'"



Comments

# # illume commented at 2011-09-05 17:36:04

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


The config system should probably exit with an error code if it can not find the required dependencies. I'm not sure what affect this would have on various build systems, since it is quite a change. However, I think it probably should be a hard fail if the dependencies can not be found.

I think this would make it easier on people to notice that they have forgotten to install a dependency.


# # illume commented at 2016-05-08 05:54:56

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Exit with status 1 if sdl-config missing

sys.exit() with a message == print the message and exit with code 1.

Raising SystemExit also works, but it only gives code 1 if it has a message.

Closes # 35

MSYS detection fails if MSYS was not installed via installer (21)

Issue №21 opened by illume at 2011-08-22 09:39:41

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Paul "TBBle" Hampson, 2008-08-31 06:23:39 -0700

Created attachment 12
Patch to fix MSYS detection when MSYS was not installed by the installer

The MSYS detection code in msys.py, specifically find_msys_registry(), attempts to find the directory the MSYS installer's uninstall entry has recorded in the Windows Registry, raising a LookupError exception if no result was found which allows higher code to fall back to prompting the user.

However, the call to _winreg.OpenKey is outside the try/except block, so if the key does not exist the wrong exception is thrown, and setup.py aborts without ever offering the prompt.

The attached patch corrects this, by ensuring that the OpenKey is performed inside the outer try block, and the outer try block raises a LookupError on an exception. The inner try block is still necessary to ensure that the finally clause is run if we successfully OpenKeyed.

Attachments:
[[http://www.pygame.org/old_bug_attachments/12/msysdetect.patch| msysdetect.patch]]

== Lenard Lindstrom, 2008-08-31 20:45:18 -0700

Thanks for the report.

Fixed in SVN revision 1644



Comments

Memory leak in surflock.c (30)

Issue №30 opened by illume at 2011-08-22 09:39:50

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== , 2009-04-14 12:31:07 -0700

This issue is in the surflock.c, not surface.c. I diagnosed it in 1.8.1, but a quick look at subversion shows that the relevant code has not changed.

The PySurface_LockBy function is leaking a weakref.ref each time a surface is locked. The weak reference is created on line 82 of surflock.c, and then is appended to the list on line 90. PyList_Append does not steal the reference, and so the reference count remains incremented even when PySurface_LockBy returns, causing a memory leak.

The solution is to add Py_DECREF(ref) as line 91 of surflock.c, making the function read:

static int
PySurface_LockBy (PyObject* surfobj, PyObject* lockobj)
{
    PyObject *ref;
    PySurfaceObject* surf = (PySurfaceObject*) surfobj;

    if (!surf->locklist)
    {
        surf->locklist = PyList_New (0);
        if (!surf->locklist)
            return 0;
    }
    ref = PyWeakref_NewRef (lockobj, NULL);
    if (!ref)
        return 0;
    if (ref == Py_None)
    {
        Py_DECREF (ref);
        return 0;
    }
    PyList_Append (surf->locklist, ref);
    Py_DECREF(ref);
    
    if (surf->subsurface)
        PySurface_Prep (surfobj);
    if (SDL_LockSurface (surf->surf) == -1)
    {
        PyErr_SetString (PyExc_RuntimeError, "error locking surface");
        return 0;
    }
    return 1;
}

== illume, 2009-05-26 01:55:25 -0700

Thanks Tom!

Committed revision 2259.



Comments

# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

Panning reversed when mixer in 8-bit mode (9)

Issue №9 opened by illume at 2011-08-22 09:39:30

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Thorbrian, 2008-02-22 23:33:40 -0800

Created attachment 5
test case

originally from Will McGugan

see attached test case files (if you change sample_bits to 16, you can see the panning works as expected)

Attachments:
[[http://www.pygame.org/old_bug_attachments/5/bouncey.zip| bouncey.zip]]

== illume, 2008-03-05 14:08:52 -0800

Added a work around in subversion r1143.

I'm 99% sure this is a bug in SDL_mixer.

Need to report it to the SDL bug tracker.

== Thorbrian, 2008-03-16 22:39:06 -0700

has this been submitted to SDL_mixer?

== illume, 2008-05-02 16:18:56 -0700

The bug has been reported to SDL.

== Lenard Lindstrom, 2009-02-12 13:30:26 -0800

Still not fixed as of rev. 4211 (Mon Dec 8 00:27:32 2008 UTC).



Comments

# # illume commented at 2011-09-05 18:14:47

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


This is an sdl_mixer bug that has been reported. Closing.


# # illume commented at 2017-01-11 10:21:41

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: svn (automated comment)

pygame.base raises ImportError (47)

Issue №47 opened by illume at 2011-08-22 09:40:05

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== John, 2010-05-19 10:59:30 -0700

I'm reporting this on behalf of a friend of mine who is helping me bug test a game. He installed Python 3.1 and Pygame 1.9.1 on his Windows XP machine but any Pygame scripts will crash. He tried installing and reinstalling Pygame but to no avail.

Here's the error he gets:

File "C:\Python31\lib\site-packages\pygame\__init__.py", line 95, in <module>
from pygame.base import *

ImportError: DLL load failed: This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.



Comments

# # illume commented at 2011-08-23 13:58:38

Original comment by Anonymous:


Hi,

Same here!

I am using python 2.7 (from Enthought) on mac os x 10.7. While installation I did receive some of the warnings, such as

ld: warning: ignoring file build/temp.macosx-10.5-i386-2.7/src/mouse.o, file was built for i386 which is not the architecture being linked (x86_64)
ld: warning: ignoring file /Developer/SDKs/MacOSX10.5.sdk/Library/Frameworks//SDL.framework/SDL, missing required architecture x86_64 in file

simply because I am force building it for i386 arch configuration, which doesn't exist on Lion :(.

Any ways, after installation, importing pygame creates the following crash messages:

$ python
Enthought Python Distribution -- www.enthought.com
Version: 7.1-2 (64-bit)

Python 2.7.2 |EPD 7.1-2 (64-bit)| (default, Jul 27 2011, 14:50:45) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "packages", "demo" or "enthought" for more information.
>>> import pygame 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/EPD64.framework/Versions/7.1/lib/python2.7/site-packages/pygame/__init__.py", line 95, in <module>
    from pygame.base import *
ImportError: dlopen(/Library/Frameworks/EPD64.framework/Versions/7.1/lib/python2.7/site-packages/pygame/base.so, 2): Symbol not found: _SDL_EnableUNICODE
  Referenced from: /Library/Frameworks/EPD64.framework/Versions/7.1/lib/python2.7/site-packages/pygame/base.so
  Expected in: dynamic lookup


# # illume commented at 2011-08-23 16:32:00

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Hi,

I think your error is slightly different. Your issue is likely because you are using an SDL that does not support Lion. Only the latest hg SDL supports Lion. There are some more changes due to be merged into SDL tip sometime this week or next.

I put up a build for the apple python2.7 that comes with Lion here: http://rene.f0o.com/~rene/stuff/pygame-1.9.2pre-py2.7-macosx10.7.mpkg.zip

It probably won't help with your build of python though.

Maybe by next week SDL will be in better shape on Lion, and they might release new binaries. If not I'll put some together with what they have.


# # illume commented at 2011-08-25 06:16:53

Original comment by Anonymous:


Hi illime,

Thanks a lot :). The link to the pkg seems broken, though.


# # illume commented at 2011-09-05 17:02:47

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Hello,

there are some new OSX binaries listed on the pygame.org page.
http://pygame.org/download.shtml

There are also install instructions there if you use the homebrew package manager.

It would be good to know if any of them work for you?

cheers,


# # illume commented at 2013-09-08 14:22:35

Original comment by Elena Williams (Bitbucket: elequ, GitHub: elequ):


Hi there!

I just had experienced this issue and can confirm the following behavior:

My pip installation of pygame installation worked but didn't fully support SDL:

Test results:
Framework SDL found
Framework SDL_ttf not found
Framework SDL_image not found
Framework SDL_mixer not found

So I reinstalled SDL 1.2.15 and PyGame 1.9.1 from source, now SDL support was complete:

Hunting dependencies...
Framework SDL found
Framework SDL_ttf found
Framework SDL_image found
Framework SDL_mixer found

It was at this point I experienced the following error:

# !python

Python 2.7.3 (v2.7.3:70274d53c1dd, Apr  9 2012, 20:52:43) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
>>> import pygame
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Python/2.7/site-packages/pygame/__init__.py", line 95, in <module>
    from pygame.base import *
ImportError: dlopen(/Library/Python/2.7/site-packages/pygame/base.so, 2): Symbol not found: _SDL_EnableUNICODE
  Referenced from: /Library/Python/2.7/site-packages/pygame/base.so
  Expected in: flat namespace
 in /Library/Python/2.7/site-packages/pygame/base.so


I came across this post and installed the OSX binary posted above:
http://rene.f0o.com/~rene/stuff/pygame-1.9.2pre-py2.7-macosx10.7.mpkg.zip

It's now working correctly! Thank you!


# # illume commented at 2014-01-23 10:08:15

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Closing this issue because it's got a bunch of unrelated errors in here.

There are other issues opened already because of the various problems listed in here.

For "event" ststem need initialize "VIDEO" system. (33)

Issue №33 opened by illume at 2011-08-22 09:39:52

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Uriy Zhuravlev, 2009-05-30 09:16:49 -0700

For normal work with sound and mixer class i need use event system but in my system not have video.

Now i modify VIDEO_INIT_CHECK() macros in src/pygame.h for disable exception and my program good work.

I believe that this is not the correct logic of the pygame.

== Uriy Zhuravlev, 2009-05-30 12:53:37 -0700

Created attachment 23
Callback function

Need provide Mix_HookMusicFinished callback to pygame for not event work with pygame.mixer.

I post patch but him segfault. :(

Attachments:
[[http://www.pygame.org/old_bug_attachments/23/pygame_music| pygame_music]]



Comments

# # illume commented at 2011-09-05 18:13:05

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


You can set an environment variable as SDL_VIDEODRIVER=dummy which will make the system work if you don't have video on your system.

I'm not sure what the patch is, or if you need it any more. Sorry this bug took so long to answer. Please reopen bug if you are still interested in having the patch applied.

pygame.event returns incorrect unicode for euro sign (3)

Issue №3 opened by illume at 2011-08-22 09:39:24

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Robin Allen, 2008-01-17 01:57:02 -0800

import pygame, unicodedata

pygame.init()
pygame.display.set_mode((150, 150))

print "ESC to quit"
print "Euro sign should be", hex(ord(u'\N{EURO SIGN}'))

while True:
	evt = pygame.event.wait()
	if evt.type == pygame.KEYDOWN:
		if evt.key == pygame.K_ESCAPE:
			break
		elif evt.unicode:
			print "%s (%s)" % (hex(ord(evt.unicode)),
				unicodedata.name(evt.unicode, "NO NAME"))

--
If you run this script and type a Euro sign, you can see that pygame gives its unicode value as 0x80 (An unnamed Unicode 'control' character /sometimes/ rendered with a Euro sign) instead of 0x20AC (Unicode "EURO SIGN").

== illume, 2008-05-02 16:20:49 -0700

I don't have a euro sign on my keyboard to test this.

== jmm0, 2010-12-02 06:31:07 -0800

I tried the example code on my workstation. 0x20AC (Unicode "EURO SIGN") was printed to the console as expected when I pressed RightAlt + E.

OS: Windows XP Professional (32-bit)
Keyboard service: French (France)
Python: 2.4
pygame: 1.9.2pre-svn2952

== Herman Chau, 2010-12-20 04:08:06 -0800

I also tried running the script and it gave the correct output: 0x20AC (Unicode "EURO SIGN")

OS: Ubuntu 10.04
Python: 2.6.5
Pygame: 1.9.1

== Dávid Gábor Bodor, 2011-07-24 02:51:24 -0700

Tested on 1.9.1 and svn-3193, both produces the correct result.

The code for the euro sign is 0x20AC for me as expected.
I have a hungarian keyboard, the combination is AltGr-U.



Comments

# # illume commented at 2011-09-06 17:00:40

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Marking as resolved as no one else can reproduce this problem.

Please reopen the issue if the issue still exists. Also, if reopening please report information about OS version keyboard type, and as much other information you can think of.

thanks!

Port Pygame repository to Bitbucket/Mercurial (1)

Issue №1 opened by illume at 2011-08-07 18:05:46

Originally reported by: Lenard Lindstrom (Bitbucket: llindstrom, GitHub: llindstrom)


Posted to [email protected] by René Dudfield on Aug. 4, 2011:\
\
Subject: transition plan was Re: [pygame] contemplating move to bitbucket(and hg). what do you think?\
\
Hi,
\
I've started on a migration plan for bitbucket. If anyone has any feedback, please let me know :) \
\
They will be done in roughly the order written.\
\
\

bitbucket url is https://bitbucket.org/pygame

  ** registered this already.
  ** using our own hg.pygame.org domain is possible:
  http://confluence.atlassian.com/display/BITBUCKET/Using+your+Own+Bitbucket+Domain+Name

Adding contributors to the bitbucket repository.

  ** will post a message on the mail list for people who want to be
  added.

issues,

  ** No way to import bugzilla bugs into bitbucket issues?  Need to check if this has been done before?
  ** http://confluence.atlassian.com/display/BITBUCKET/Using+your+Bitbucket+Issue+Tracker
  ** there is an issues api
  http://confluence.atlassian.com/display/BITBUCKET/Issues

hg

  ** import all of the history with the hg convert plugin.
  *** http://mercurial.selenic.com/wiki/ConvertExtension
  ** Need author map, to convert pygame svn author usernames into
  bitbucket user names for people who care.
  *** email mailing list asking for bitbucket usernames of commiters.
  *** the format needed is: 'First Last <[email protected]>'
  *** will check an authormap file into svn.
  ** what to do with branches, and trunk?
  ** instead of a trunk the root should be the trunk.

wiki

  # #  uses 'creol' syntax.  Will need to convert pages from html into
  this format.
     *** there is a html2creol converter here:
     http://code.google.com/p/python-creole/
     *** will keep current pygame wiki up, with links to new pages until
  conversion is complete.
  # #  Check with bitbucket if they have plans to support .rst soon.
  # #  need to create mirror system to keep website up to date.
     *** on wiki change, download new data then convert from creol format into html.

build page(spectacularly adequate). Will need to be updated to

take changes from hg instead of svn.

old subversion.

  ** delete files in trunk, and put a we_have_moved.txt file in there.

ftp mirror system.

  ** mirror download files from the bitbucket download page to the pygame
  /ftp page.
  ** need to think how the html page will be structured. Do we just list
  all files on bitbucket?  I think we just list all of the files

on bitbucket
download page, and group them by OS.

update hacking page.

  ** instructions on hg, and submitting patches.  As well as writing
  docs.


Comments

# # illume commented at 2011-08-18 16:54:05

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


hg repository migrated.

Started work on bugzilla bug migration tool.


# # illume commented at 2011-08-18 16:57:42

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Making the tool here:
https://bitbucket.org/illume/bugzilla_bitbucket/


# # illume commented at 2011-08-26 10:38:59

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


The issues are migrated.

The following still need to be done:

  • download syncing to /ftp
  • wiki converted to creol and then synced to website
  • update hacking page, and other mentions of svn.
  • build page(spectacularly adequate) needs to be pointed to HG.

# # illume commented at 2012-07-08 07:33:00

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


The wiki has been converted a while ago.

  • download syncing to /ftp. Start bitbucket repo with download in, instead of using the bitbucket downloads feature... because it has no API.
  • bitbucket wiki needs syncing to website. pull from repo, convert to html, rewrite rules will keep current urls.
  • build page(spectacularly adequate) needs to be pointed to HG.

# # illume commented at 2012-07-08 07:58:39

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


The buildbot part of this has moved to isssue # 111

TODO:

  • download syncing to /ftp. Start bitbucket repo with download in, instead of using the bitbucket downloads feature... because it has no API.
  • bitbucket wiki needs syncing to website. pull from repo, convert to html, rewrite rules will keep current urls.

# # illume commented at 2013-01-03 13:04:48

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


'download syncing to /ftp' has been given an issue in # 152

website generation from wiki has been given an issue in # 153


# # illume commented at 2014-01-23 12:44:21

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Closing this. All of the tasks have either been done or have issues tracking them.

Add optional 'format' argument to pygame.image.save (48)

Issue №48 opened by illume at 2011-08-22 09:40:06

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Arnau Sanchez, 2010-05-19 11:22:25 -0700

Sometimes we need to store a surface image into a string instead of a filename. I tested with StringIO and it worked:

import StringIO
fd = StringIO.StringIO()
pygame.image.save(surface, fd)
print len(fd.getvalue()) 
#  1334

However, since we have no real filename, we cannot set the file format. That's why I propose to add a third optional argument that forces the function to use a given format:

pygame.image.save(Surface, filename, format="TGA"): return None


Related Docs: https://www.pygame.org/docs/ref/image.html# pygame.image.save


Comments

# # illume commented at 2011-09-05 17:04:24

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


This is a good idea.

I've marked this as something for pygame 1.9.2.

Thanks!


# # illume commented at 2017-01-11 10:21:45

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

Pygame mixer midi playback crash (5)

Issue №5 opened by illume at 2011-08-22 09:39:26

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Travis Rose, 2008-01-26 07:51:04 -0800

When playing a midi in "looped" mode,
Pygame's mixer crashes on Mac OS X
Either loops=-1 or loops > 0 causes this.


1   com.apple.audio.CoreAudio      	0x91476d9a IOA_Device::CallIOProcs(AudioTimeStamp const&, AudioTimeStamp const&, AudioTimeStamp const&) + 274
2   com.apple.audio.CoreAudio      	0x91476b21 HP_IOThread::PerformIO(AudioTimeStamp const&) + 1299
3   com.apple.audio.CoreAudio      	0x91474f49 HP_IOThread::WorkLoop() + 953
4   com.apple.audio.CoreAudio      	0x91474b8b HP_IOThread::ThreadEntry(HP_IOThread*) + 17
5   com.apple.audio.CoreAudio      	0x91469171 CAPThread::Entry(CAPThread*) + 93
6   libSystem.B.dylib              	0x90024227 _pthread_body + 84

== Thorbrian, 2008-01-26 19:18:55 -0800

Travis - can you please attach a test case? a midi file and python script?

== illume, 2008-02-04 21:33:46 -0800

Confirmed it crashes on osx.

wget http://209.197.86.65/19841988/rock/beatles/ISawHerStandingThere.mid
wget http://rene.f0o.com/~rene/stuff/midi.py

python midi.py ISawHerStandingThere.mid

== illume, 2008-05-02 16:27:37 -0700

This bug has been submitted to sdl.



Comments

# # illume commented at 2011-09-07 06:43:33

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Setting as wontfix, since it is an SDL bug, that has been reported.

Bad permissions on font (and icons) in 1.8.1 tarball (27)

Issue №27 opened by illume at 2011-08-22 09:39:47

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Adam Williamson, 2008-12-12 17:33:48 -0800

In the pygame 0.8.1 tarball, all files in lib/ have 700 permissions. The icon file freesansbold.ttf and the icon files pygame.ico and pygame_icon.* included.

When installing pygame system-wide, the restrictive 700 permissions on these files are kept, as they are just installed as data. Of course, they are now owned by root, not the user - so a regular user cannot access them. This causes pygame-based applications including at least childsplay, but probably more, to fail to run, because freesansbold.ttf cannot be opened. Changing the permissions on freesansbold.ttf to 644 resolves this problem.

See this Mandriva forum thread:

http://forum.mandriva.com/viewtopic.php?p=606600#606600

and this one from PCLOS:

http://hack.mypclinuxos.com/index.php?action=printpage;topic=606.0

both a result of this bug.

== James Paige, 2008-12-12 19:20:16 -0800

Created attachment 18
pygame-1.8.1release.tar.gz with corrected permissions, unix line endings, and .pyc files removed

I am guessing that some poor misguided windows-using soul just converted the zip file into a tarball without realizing the implications :)

I have fixed the permissions, fixed the line-ending style on all .py files, and removed all .pyc files

I'm not sure who has permissions to upload a new tarball to the main site.

Attachments:
[[http://www.pygame.org/old_bug_attachments/18/pygame-1.8.1release.tar.gz| pygame-1.8.1release.tar.gz]]

== Thorbrian, 2008-12-14 11:59:08 -0800

Rene, did you make the original tarball? Can you check out James' fixed version and upload it if it's good?

thanks!

== illume, 2009-05-25 15:16:14 -0700

hi,

the pygame 1.9 release will fix these issues.  

Executable bits on files have been addressed with a script made by Lenard and modified by me, and I have made a note to check line endings before release.

I think it happened because I used the sdist command on a windows machine from a non-fresh checkout.

Adding a note to the how_to_release_pygame.txt about it.

Will just leave the 1.8.1release how it is, and ask people to move to 1.9... which also fixes more bugs.

I really should have looked at this earlier... but the 1.9 release is only 2-3 weeks away now.

cu,



Comments

Memory leak in pygame.image.save (43)

Issue №43 opened by illume at 2011-08-22 09:40:02

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== , 2010-03-31 04:33:04 -0700

Created attachment 33
Program to test the memory leak. Comment line 32 and try again

I think I detected a memory leak with the pygame.image.save function, but I am a beginner so perhaps I do something wrong. Using python 2.6.2, pygame 1.9.1, windows XP.


I used Windows Task Manager to detect the leak.

Attachments:
[[http://www.pygame.org/old_bug_attachments/33/TestMemoryLeak.py| TestMemoryLeak.py]]

== Jonathan Berry, 2010-05-28 09:49:35 -0700

I ran into this too. I took a look at the code and noticed that saving PNGs loads the imageext module while saving BMPs does not. I switched to saving BMPs and my code no longer leaks memory. So the problem is somewhere in the PNG saving code. Have not tried JPG, but that might help narrow it down further.

== Marco Lettere, 2010-12-03 03:44:53 -0800

Jpeg is stable as BMP. 
PNG is causing memory leak also for me (AMD SMP 64 BIT - Ubuntu 10.04, pygame 1.9.1)

== Winston Ewert, 2011-02-14 12:01:50 -0800

Created attachment 38
patch to fix the memory leak

The write_png function was not deallocating the structures it created in the png library. This adds the call to make sure that both structures are deallocated.

The patch does not correctly handle a specific error case. I don't see how to handle it. (details in comment in patch). However, that is an unlikely case and the only problem remaining is the memory leak.

No test case added as I'm not sure how to write a test on a memory leak.

Attachments:
[[http://www.pygame.org/old_bug_attachments/38/png_leak.patch| png_leak.patch]]



Comments

# # illume commented at 2011-09-06 16:37:58

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


Fixes # 43. Memory leak in pygame.image.save with png files,
in the imageext.c write_png function.

Thanks Winston Ewert for the patch.
Thanks Jonathan Berry, and Marco Lettere for work on the bug.


# # illume commented at 2013-04-19 11:44:10

Original comment by Pehat (Bitbucket: Pehat, GitHub: Pehat):


Thank you for the fix, now it works properly.

Package 1.9 for Mac requires System Python, even if there. (42)

Issue №42 opened by illume at 2011-08-22 09:40:01

Originally reported by: René Dudfield (Bitbucket: illume, GitHub: illume)


== Alexandre Quessy, 2010-01-03 16:33:25 -0800

It is impossible to install pygame on my Mac OS X from the packages provided on the page http://pygame.org/download.shtml

I tried the three packages : 
 * pygame-1.9.1release-py2.6-macosx10.5.zip 10.3MB
 * pygame-1.9.1release-py2.5-macosx10.5.zip 10.3MB
 * pygame-1.9.1release-py2.4-macosx10.5.zip 10.3MB

And they all give me the following error : (sorry for the french)

 * Vous ne pouvez pas installer pygame 1.9.1release sur ce volume. pygame requires System Python 2.4 to install.
 * Vous ne pouvez pas installer pygame 1.9.1release sur ce volume. pygame requires System Python 2.5 to install.
 * Vous ne pouvez pas installer pygame 1.9.1release sur ce volume. pygame requires System Python 2.6 to install.

I use Mac OS 10.5.8 on a MacBook Pro with a 2.2 GHz Intel Core 2 Duo CPU, 2 Gb of RAM and 500 Gb of hard drive space. There is a Python that is installed with Mac OS X. 

I installed a few MacPorts Python packages though, and it might be the reason : 

python24 @2.4.6 (lang)
    An interpreted, object-oriented programming language
python25 @2.5.4 (lang)
    An interpreted, object-oriented programming language

But when I issue "which python" in a Terminal, it is the System Python that is listed, I think.

buzz:twisted aalex$ python -V
Python 2.5.1
buzz:twisted aalex$ which python
/usr/bin/python

== Alexandre Quessy, 2010-01-03 19:34:16 -0800

This is fixed once I have installed http://www.python.org/ftp/python/2.5/python-2.5-macosx.dmg

This should be documented.



Comments

# # illume commented at 2011-09-06 16:15:39

Original comment by René Dudfield (Bitbucket: illume, GitHub: illume):


This has been documented on the download page now.

It would be nice to fix it in the installer too... but I think the download 'solves' the issue mostly.


# # illume commented at 2017-01-11 10:21:46

Original comment by Thomas Kluyver (Bitbucket: takluyver, GitHub: takluyver):


Removing version: unspecified (automated comment)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.