Re: [SPAM: 3.500] Re: [pygame] This one baffles me
Yeah, if you want to convert just the tabs at the start of a line, you would need to do: print open(myfile.py).read().replace(\n+ *4, \t) or whichever line ending you have on your system... but actually I would do a 3 liner that is more helpful, IMO: f = open(myfile.py, rw) f.write(f.read.replace(\n + *4, \t)) f.close() I think rw is what you want there, but I haven't worked with it in a while, but basically that will just load your file, convert and then resave it, so you don't have to cp for the console... On Sun, May 17, 2009 at 6:41 PM, Greg Ewing greg.ew...@canterbury.ac.nzwrote: Casey Duncan wrote: Here's the moral-equivalent one-liner in Python: print open(myfile.py).read().replace( *4, \t) Note that this is not exactly the right way to expand tabs, since it doesn't take account of the position in the line at which the block of spaces starts. But it's okay if all you care about is leading indentation. -- Greg
Re: [SPAM: 3.500] Re: [pygame] This one baffles me
I think you forgot the newline: .replace(\n+ *4, \n\t)
Re: [SPAM: 3.500] Re: [pygame] This one baffles me
jug wrote:
I think you forgot the newline:
.replace(\n+ *4, \n\t)
No cigar... not even close..
from __future__ import with_statement
with open ('perforce_plugin.py', 'r+w') as fh:
fixed_tabs = fh.read().expandtabs(4)
fh.seek(0)
fh.write(fixed_tabs)
*expandtabs*(s, tabsize=8)
expandtabs
http://pydoc.org/1.6/string.html#-expandtabs(s [,tabsize]) - string
Return a copy of the string s with all tab characters replaced
by the appropriate number of spaces, depending on the current
column, and the tabsize (default 8).
Re: [SPAM: 3.500] Re: [pygame] This one baffles me
Wow, thanks
Ahem: http://yellow.bikeshed.com/
There's no need for everyone to jump in and start offering solutions
to a simple problem. There's lots of different ways to solve it.
People have different opinions on what is the best way. But
irregardless, I'm pretty sure the GP knows how to do it now.
-Tyler
On Mon, May 18, 2009 at 7:12 AM, Nicholas Dudfield
ndudfi...@gmail.com mailto:ndudfi...@gmail.com wrote:
jug wrote:
I think you forgot the newline:
.replace(\n+ *4, \n\t)
No cigar... not even close..
from __future__ import with_statement
with open ('perforce_plugin.py', 'r+w') as fh:
fixed_tabs = fh.read().expandtabs(4)
fh.seek(0)
fh.write(fixed_tabs)
*expandtabs*(s, tabsize=8)
expandtabs
http://pydoc.org/1.6/string.html#-expandtabs(s [,tabsize]) -
string
Return a copy of the string s with all tab characters replaced
by the appropriate number of spaces, depending on the current
column, and the tabsize (default 8).
--
Visit my blog at http://oddco.ca/zeroth/zblog
[pygame] Camera module change proposal
Hello all, With 1.9 coming out soon, I think it is best that we decide on a final API for the camera module to use going forward. The current module was designed largely for v4l2 on low performance fixed point CPUs, and the API reflects that. With OS X support coming this summer from Werner, and Windows support coming soon, we should decide on something that works well across all platforms. 1. Remove colorspace conversion from the camera module: Currently, the camera module can capture images as RGB, YUV, or HSV. There are a lot of conversion shortcuts going on under the hood to get the quickest path from raw pixel data to the desired colorspace. Unfortunately, this also multiplies the amount of code and work necessary to bring the camera module to other platforms. The use cases for this feature are also fairly limited, since anyone doing serious computer vision is better off using OpenCV. I propose having the camera module do the more relevant task of just capturing RGB images, and have a seperate colorspace conversion function, either the transform or the color module, which takes any RGB surface and outputs an HSV or YUV surface. 2. Camera controls: I'm not sure what to do here. V4l2 controls are very useful to have, but there doesn't seem to be a Windows or OS X equivalent as far as I can tell. Any ideas on either? Nirav
[pygame] Pygame and mp3 files
Hi, Since switching to Debian Linux to develop Pygame for Python 3 I've found the mixer_music_test.py unit test fails with a memory access violation. Something about the house_lo.mp3 file included in the examples, maybe the 11025 Hz sample rate, causes smpeg to misbehave. smpeg will happily play other mp3 files, but not this one. The problem I am running into is that mp3 is a proprietary format. None of the tools readily available to me will write an mp3 file. And I am not inclined to custom build tools with mp3 support just to chase down this problem. So this brings me to the point of this post, to propose deprecating mp3 support in Pygame starting with Python 1.9.0. ogg-vorbis support is widely available, and FLAC support should become more wide spread (the Windows build already has it). This is not to suggest mp3 support should be immediately cut off. But with a new ffmpeg based movie module in the works there is little other reason to keep smpeg as a dependency. Without an mp3 requirement smpeg can be turfed once and for all, since the existing movie module was never reliable anyway. Of course mp3 support will not completely go away. For systems where SDL and other dependencies are provided as separate packages smpeg can always be included. But for Windows, were custom built dependencies are used, it would be omitted. Any thoughts. Lenard
Re: [pygame] Pygame and mp3 files
I'm pretty sure you can enable mp3 support for Debian, by adding a new repository, or by using audacity. Audacity will ask if you want to download an mp3 plugin when you try to open or create an mp3 file. But I do agree with your proposed plan. It sounds good to me, plus, it helps encourage the use of open-formats. -Tyler On Mon, May 18, 2009 at 1:56 PM, Lenard Lindstrom le...@telus.net wrote: Hi, Since switching to Debian Linux to develop Pygame for Python 3 I've found the mixer_music_test.py unit test fails with a memory access violation. Something about the house_lo.mp3 file included in the examples, maybe the 11025 Hz sample rate, causes smpeg to misbehave. smpeg will happily play other mp3 files, but not this one. The problem I am running into is that mp3 is a proprietary format. None of the tools readily available to me will write an mp3 file. And I am not inclined to custom build tools with mp3 support just to chase down this problem. So this brings me to the point of this post, to propose deprecating mp3 support in Pygame starting with Python 1.9.0. ogg-vorbis support is widely available, and FLAC support should become more wide spread (the Windows build already has it). This is not to suggest mp3 support should be immediately cut off. But with a new ffmpeg based movie module in the works there is little other reason to keep smpeg as a dependency. Without an mp3 requirement smpeg can be turfed once and for all, since the existing movie module was never reliable anyway. Of course mp3 support will not completely go away. For systems where SDL and other dependencies are provided as separate packages smpeg can always be included. But for Windows, were custom built dependencies are used, it would be omitted. Any thoughts. Lenard -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Camera module change proposal
Hello Nirav, For #1, I can say that YUV colorspace is much faster than RGB to upload to the graphic card when using OpenGL. If for now it is only RGB that is implemented, it would surely be nice to have the possibilty to use YUV directly in a near future. For #2, on Mac OS X, there is at least the Quicktime Dialog that can offer a lot of fine controls on the image source and quality. It surely should be implemented in the first place. Regards, a 2009/5/18 Nirav Patel o...@spongezone.net: Hello all, With 1.9 coming out soon, I think it is best that we decide on a final API for the camera module to use going forward. The current module was designed largely for v4l2 on low performance fixed point CPUs, and the API reflects that. With OS X support coming this summer from Werner, and Windows support coming soon, we should decide on something that works well across all platforms. 1. Remove colorspace conversion from the camera module: Currently, the camera module can capture images as RGB, YUV, or HSV. There are a lot of conversion shortcuts going on under the hood to get the quickest path from raw pixel data to the desired colorspace. Unfortunately, this also multiplies the amount of code and work necessary to bring the camera module to other platforms. The use cases for this feature are also fairly limited, since anyone doing serious computer vision is better off using OpenCV. I propose having the camera module do the more relevant task of just capturing RGB images, and have a seperate colorspace conversion function, either the transform or the color module, which takes any RGB surface and outputs an HSV or YUV surface. 2. Camera controls: I'm not sure what to do here. V4l2 controls are very useful to have, but there doesn't seem to be a Windows or OS X equivalent as far as I can tell. Any ideas on either? Nirav -- Alexandre Quessy http://alexandre.quessy.net/
Re: [pygame] Camera module change proposal
On Tue, May 19, 2009 at 5:26 AM, Nirav Patel o...@spongezone.net wrote: Hello all, With 1.9 coming out soon, I think it is best that we decide on a final API for the camera module to use going forward. The current module was designed largely for v4l2 on low performance fixed point CPUs, and the API reflects that. With OS X support coming this summer from Werner, and Windows support coming soon, we should decide on something that works well across all platforms. We can't decide on a final API at this point. Better to wait until we find out what each one can do. Marking it final before getting into the implementation won't work. It's definitely time to discuss the API, just not marking it final until we need to. The camera module is going to be marked experimental, and we can change it post 1.9 - like we agreed. It's way to late in the 1.9 release process to change anything drastically in 1.9 now. 1. Remove colorspace conversion from the camera module: Currently, the camera module can capture images as RGB, YUV, or HSV. There are a lot of conversion shortcuts going on under the hood to get the quickest path from raw pixel data to the desired colorspace. Unfortunately, this also multiplies the amount of code and work necessary to bring the camera module to other platforms. The use cases for this feature are also fairly limited, since anyone doing serious computer vision is better off using OpenCV. I propose having the camera module do the more relevant task of just capturing RGB images, and have a seperate colorspace conversion function, either the transform or the color module, which takes any RGB surface and outputs an HSV or YUV surface. The idea of making as small amount of work as possible is a good one. Native formats + RGB + YUV from the camera object would be grand. some points: - people to get out the data as quickly as possible who need to (like if on low power machines, olpc, mobile phones etc). - zero extra coding for implementer if they are lazy, all the need to implement at minimum is RGB. - if the implementer wants to spend extra time making sure YUV is a fast path, they can. - yuv is important for Movie, and Overlay (two other important use cases). Having a colorspace conversion function in another module is fine (not for 1.9 though). However requiring it to be separate means the implementer can not output YUV etc in the fast path. If it is in the camera module, then if the implementor does not want to they can get out RGB, then convert it to YUV. They also have the option to try and get YUV out using a fast path. eg. this psedo code Camera class shows, how by keeping the details in the Camera class it's possible to get yuv in the fast path if implemented, and if not use the conversion function from RGB. class Camera(object): def get_yuv(self) if self.can_get_yuv: return self._yuv() else: rgb = self.get_rgb() return pygame.color.convert_rbg_to_yuv(rgb) The native formats should come simply as a buffer, and also information about that buffer. Details can be standardised as needed for these other types. However, the various RGB/yuv ones should be standardised. 2. Camera controls: I'm not sure what to do here. V4l2 controls are very useful to have, but there doesn't seem to be a Windows or OS X equivalent as far as I can tell. The general idea of camera controls(settings, properties, attributes etc) is available on every camera API. It should probably be generalised - rather than just the specific ones used in v4l2. camera = Camera() camera.flipx = 1 camera.fps = 10 camera.width = 320 camera.height = 200 Not sure exactly which controls will work Xplatorm at this stage... or if on every platform settings can be changed after the camera is started, or only before starting the camera. This is something that needs more research. Any ideas on either? Nirav
Re: [pygame] Pygame and mp3 files
hi, This test is failing because Debian doesn't have the sdlmixer/smpeg patch which fixes that bug. Best to add a skip for that test on non-windows+mac. I don't think we should depreciate mp3, but rather depreciate smpeg :) cu, On Tue, May 19, 2009 at 6:56 AM, Lenard Lindstrom le...@telus.net wrote: Hi, Since switching to Debian Linux to develop Pygame for Python 3 I've found the mixer_music_test.py unit test fails with a memory access violation. Something about the house_lo.mp3 file included in the examples, maybe the 11025 Hz sample rate, causes smpeg to misbehave. smpeg will happily play other mp3 files, but not this one. The problem I am running into is that mp3 is a proprietary format. None of the tools readily available to me will write an mp3 file. And I am not inclined to custom build tools with mp3 support just to chase down this problem. So this brings me to the point of this post, to propose deprecating mp3 support in Pygame starting with Python 1.9.0. ogg-vorbis support is widely available, and FLAC support should become more wide spread (the Windows build already has it). This is not to suggest mp3 support should be immediately cut off. But with a new ffmpeg based movie module in the works there is little other reason to keep smpeg as a dependency. Without an mp3 requirement smpeg can be turfed once and for all, since the existing movie module was never reliable anyway. Of course mp3 support will not completely go away. For systems where SDL and other dependencies are provided as separate packages smpeg can always be included. But for Windows, were custom built dependencies are used, it would be omitted. Any thoughts. Lenard
Re: [SPAM: 3.500] Re: [pygame] This one baffles me
On Tue, May 19, 2009 at 12:29 AM, Tyler Laing trinio...@gmail.com wrote: Ahem: http://blue.bikeshed.com/ There's no need for everyone to jump in and start offering solutions to a simple problem. There's lots of different ways to solve it. People have different opinions on what is the best way. But irregardless, I'm pretty sure the GP knows how to do it now. -Tyler ... except if the offered solutions are wrong, or there is a better way that people might be interested in, or people just want to have a discussion in a place where they can talk about whatever they want to. The replace(..., \t) solutions insert tabs, not replace tabs with spaces. So they're not good. Should write the result to a temporary file, then do a move from the temporary file into the new file. This way if there is a bug in your code half way through writing it won't wipe out the original... Also move is an atomic operation, whereas writing to the file you just read from can cause all sorts of problems. Say something tries to read your file halfway through your write, then they will get half a file back... whereas if you write to a temporary file then move it, every other program reading your file will never get a corrupt file. cu,
Re: [pygame] Pygame and mp3 files
On Tue, May 19, 2009 at 7:38 AM, René Dudfield ren...@gmail.com wrote: hi, This test is failing because Debian doesn't have the sdlmixer/smpeg patch which fixes that bug. Best to add a skip for that test on non-windows+mac. I don't think we should depreciate mp3, but rather depreciate smpeg :) cu, To add to that... also strongly recommend not using mp3 in the docs. cu,
Re: [SPAM: 3.500] Re: [pygame] This one baffles me
Both good points. I stand corrected. Its not like anyone /has/ to listen to me... just that we reached 8 different solutions by my count, with them starting to use more obscure syntax and functions... Just wanted to point out that it was starting to get a bit ridiculous, thats all. :) -Tyler On Mon, May 18, 2009 at 2:52 PM, René Dudfield ren...@gmail.com wrote: On Tue, May 19, 2009 at 12:29 AM, Tyler Laing trinio...@gmail.com wrote: Ahem: http://blue.bikeshed.com/ There's no need for everyone to jump in and start offering solutions to a simple problem. There's lots of different ways to solve it. People have different opinions on what is the best way. But irregardless, I'm pretty sure the GP knows how to do it now. -Tyler ... except if the offered solutions are wrong, or there is a better way that people might be interested in, or people just want to have a discussion in a place where they can talk about whatever they want to. The replace(..., \t) solutions insert tabs, not replace tabs with spaces. So they're not good. Should write the result to a temporary file, then do a move from the temporary file into the new file. This way if there is a bug in your code half way through writing it won't wipe out the original... Also move is an atomic operation, whereas writing to the file you just read from can cause all sorts of problems. Say something tries to read your file halfway through your write, then they will get half a file back... whereas if you write to a temporary file then move it, every other program reading your file will never get a corrupt file. cu, -- Visit my blog at http://oddco.ca/zeroth/zblog
[pygame] Working with Surfaces
Hello all, I've got a bit of a brainteaser for you, maybe, and hopefully not. Right now, through judicious use of ffplay code, I've got a large portion of the code written for a first draft version of the movie module. I changed the code where appropriate for our needs. Of course, that doesn't mean its been tested, or has even compiled yet. ;) However, I'm wondering which way I should go: Whether I should write to a pygame surface(say one passed on initialization), via the PySurface C methods, or to extract the rect and surface from the PySurface struct, and write to those instead. Which way would be safer/better/whatever? -Tyler Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Camera module change proposal
On Mon, May 18, 2009 at 5:34 PM, René Dudfield ren...@gmail.com wrote: We can't decide on a final API at this point. Better to wait until we find out what each one can do. Marking it final before getting into the implementation won't work. It's definitely time to discuss the API, just not marking it final until we need to. The camera module is going to be marked experimental, and we can change it post 1.9 - like we agreed. It's way to late in the 1.9 release process to change anything drastically in 1.9 now. Alright, we can hold off until later. - yuv is important for Movie, and Overlay (two other important use cases). The YUV being output from the camera module is packed YUV, not the YUYV, YUV422, etc used for video or the Overlay module. It is really only useful for computer vision purposes. The get_raw() function in the camera module can however output data useful for Movie or Overlay. Having a colorspace conversion function in another module is fine (not for 1.9 though). However requiring it to be separate means the implementer can not output YUV etc in the fast path. If it is in the camera module, then if the implementor does not want to they can get out RGB, then convert it to YUV. They also have the option to try and get YUV out using a fast path. eg. this psedo code Camera class shows, how by keeping the details in the Camera class it's possible to get yuv in the fast path if implemented, and if not use the conversion function from RGB. class Camera(object): def get_yuv(self) if self.can_get_yuv: return self._yuv() else: rgb = self.get_rgb() return pygame.color.convert_rbg_to_yuv(rgb) This is basically how we are doing it now. The shorter path we are using now is initializing the camera with the pixelformat closest to the desired output. Eg: If you want YUV, it'll try to initialize with YUYV, or RGB565 for RGB. Once it's initialized, you would have to close and reopen it to switch between YUV and RGB to get a short path. Nirav
Re: [pygame] Working with Surfaces
hello, it's generally good to keep out python code from the main logic of your functions, if you can. Then try and keep the python wrapping function to interacting with python. That is keep the SDL parts and the python parts as separate as possible. The python wrapper part will use a call like so... surf = PySurface_AsSurface(surfobj); to get the SDL_Surface* surf surface, which you can then pass to your function. Since the life time of the surface is done with python, through reference counting. Each time you access the surface you should probably first increment a reference count, and then modify it, then decrement the reference count. Otherwise you might want to store a reference at initialisation time, then it should be fairly safe to access the surface. However, the display surface can disappear, so perhaps passing in a surface each time might be better. I hope maybe that helps answer your question... ps. be good to start a branch in svn to dump your code as you go :) Then we can all look at your code specifically. On Tue, May 19, 2009 at 8:02 AM, Tyler Laing trinio...@gmail.com wrote: Hello all, I've got a bit of a brainteaser for you, maybe, and hopefully not. Right now, through judicious use of ffplay code, I've got a large portion of the code written for a first draft version of the movie module. I changed the code where appropriate for our needs. Of course, that doesn't mean its been tested, or has even compiled yet. ;) However, I'm wondering which way I should go: Whether I should write to a pygame surface(say one passed on initialization), via the PySurface C methods, or to extract the rect and surface from the PySurface struct, and write to those instead. Which way would be safer/better/whatever? -Tyler Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Working with Surfaces
Okay, so if I understand you correctly, you say I should extract the SDL stuff from the object and use that instead of a Python object? I can do that. And... I do know how to use svn, but I've never made a branch in svn. How do I do that? -Tyler On Mon, May 18, 2009 at 3:18 PM, René Dudfield ren...@gmail.com wrote: hello, it's generally good to keep out python code from the main logic of your functions, if you can. Then try and keep the python wrapping function to interacting with python. That is keep the SDL parts and the python parts as separate as possible. The python wrapper part will use a call like so... surf = PySurface_AsSurface(surfobj); to get the SDL_Surface* surf surface, which you can then pass to your function. Since the life time of the surface is done with python, through reference counting. Each time you access the surface you should probably first increment a reference count, and then modify it, then decrement the reference count. Otherwise you might want to store a reference at initialisation time, then it should be fairly safe to access the surface. However, the display surface can disappear, so perhaps passing in a surface each time might be better. I hope maybe that helps answer your question... ps. be good to start a branch in svn to dump your code as you go :) Then we can all look at your code specifically. On Tue, May 19, 2009 at 8:02 AM, Tyler Laing trinio...@gmail.com wrote: Hello all, I've got a bit of a brainteaser for you, maybe, and hopefully not. Right now, through judicious use of ffplay code, I've got a large portion of the code written for a first draft version of the movie module. I changed the code where appropriate for our needs. Of course, that doesn't mean its been tested, or has even compiled yet. ;) However, I'm wondering which way I should go: Whether I should write to a pygame surface(say one passed on initialization), via the PySurface C methods, or to extract the rect and surface from the PySurface struct, and write to those instead. Which way would be safer/better/whatever? -Tyler Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Working with Surfaces
hi, svn copy svn://seul.org/svn/pygame/trunk svn://seul.org/svn/pygame/branches/tylerthemovie the svn book is pretty cool for obscure svn functions... more details on creating branches here: http://svnbook.red-bean.com/en/1.1/ch04s02.html On Tue, May 19, 2009 at 8:22 AM, Tyler Laing trinio...@gmail.com wrote: Okay, so if I understand you correctly, you say I should extract the SDL stuff from the object and use that instead of a Python object? I can do that. And... I do know how to use svn, but I've never made a branch in svn. How do I do that? -Tyler On Mon, May 18, 2009 at 3:18 PM, René Dudfield ren...@gmail.com wrote: hello, it's generally good to keep out python code from the main logic of your functions, if you can. Then try and keep the python wrapping function to interacting with python. That is keep the SDL parts and the python parts as separate as possible. The python wrapper part will use a call like so... surf = PySurface_AsSurface(surfobj); to get the SDL_Surface* surf surface, which you can then pass to your function. Since the life time of the surface is done with python, through reference counting. Each time you access the surface you should probably first increment a reference count, and then modify it, then decrement the reference count. Otherwise you might want to store a reference at initialisation time, then it should be fairly safe to access the surface. However, the display surface can disappear, so perhaps passing in a surface each time might be better. I hope maybe that helps answer your question... ps. be good to start a branch in svn to dump your code as you go :) Then we can all look at your code specifically. On Tue, May 19, 2009 at 8:02 AM, Tyler Laing trinio...@gmail.com wrote: Hello all, I've got a bit of a brainteaser for you, maybe, and hopefully not. Right now, through judicious use of ffplay code, I've got a large portion of the code written for a first draft version of the movie module. I changed the code where appropriate for our needs. Of course, that doesn't mean its been tested, or has even compiled yet. ;) However, I'm wondering which way I should go: Whether I should write to a pygame surface(say one passed on initialization), via the PySurface C methods, or to extract the rect and surface from the PySurface struct, and write to those instead. Which way would be safer/better/whatever? -Tyler Visit my blog at http://oddco.ca/zeroth/zblog -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Working with Surfaces
On Tue, May 19, 2009 at 8:40 AM, René Dudfield ren...@gmail.com wrote: hi, svn copy svn://seul.org/svn/pygame/trunk svn://seul.org/svn/pygame/branches/tylerthemovie ^ this is supposed to be on one line
Re: [pygame] Working with Surfaces
There we go, Branch is made, and it is updated with all the code I've done today Thanks :) -Tyler On Mon, May 18, 2009 at 3:40 PM, René Dudfield ren...@gmail.com wrote: On Tue, May 19, 2009 at 8:40 AM, René Dudfield ren...@gmail.com wrote: hi, svn copy svn://seul.org/svn/pygame/trunk svn://seul.org/svn/pygame/branches/tylerthemovie ^ this is supposed to be on one line -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [SPAM: 3.500] Re: [pygame] This one baffles me
RB[0] wrote: Yeah, if you want to convert just the tabs at the start of a line, you would need to do: print open(myfile.py).read().replace(\n+ *4, \t) No, that only replaces the first group of 4 spaces on each line, and removes the newlines as well. The obvious way to do this properly is to loop over the lines and use the expandtabs() string method. -- Greg
Re: [pygame] Pygame and mp3 files
Hi Tyler, Audacity uses libmad. On Windows that library is now linked to msvcr80.dll, a proprietary C runtime. I don't know what Audacity does on Linux, but I don't feel like building libmad myself. Lenard Tyler Laing wrote: I'm pretty sure you can enable mp3 support for Debian, by adding a new repository, or by using audacity. Audacity will ask if you want to download an mp3 plugin when you try to open or create an mp3 file. But I do agree with your proposed plan. It sounds good to me, plus, it helps encourage the use of open-formats. -Tyler On Mon, May 18, 2009 at 1:56 PM, Lenard Lindstrom le...@telus.net mailto:le...@telus.net wrote: Hi, Since switching to Debian Linux to develop Pygame for Python 3 I've found the mixer_music_test.py unit test fails with a memory access violation. Something about the house_lo.mp3 file included in the examples, maybe the 11025 Hz sample rate, causes smpeg to misbehave. smpeg will happily play other mp3 files, but not this one. The problem I am running into is that mp3 is a proprietary format. None of the tools readily available to me will write an mp3 file. And I am not inclined to custom build tools with mp3 support just to chase down this problem. So this brings me to the point of this post, to propose deprecating mp3 support in Pygame starting with Python 1.9.0. ogg-vorbis support is widely available, and FLAC support should become more wide spread (the Windows build already has it). This is not to suggest mp3 support should be immediately cut off. But with a new ffmpeg based movie module in the works there is little other reason to keep smpeg as a dependency. Without an mp3 requirement smpeg can be turfed once and for all, since the existing movie module was never reliable anyway. Of course mp3 support will not completely go away. For systems where SDL and other dependencies are provided as separate packages smpeg can always be included. But for Windows, were custom built dependencies are used, it would be omitted. Any thoughts. Lenard -- Visit my blog at http://oddco.ca/zeroth/zblog
Re: [pygame] Pygame and mp3 files
Hi René, I used the latest smpeg from SVN and it still crashes. I suspect the problem is not limited to Debian, but Debian's free() catches it. Deprecating smpeg deprecates mp3. The replacement is libmad, a GPL library. An alternative to disabling the test is for someone outside the Greater USA to create a new house_lo.mp3 with different options to see if it works. I agree about a warning in the documents. Lenard René Dudfield wrote: On Tue, May 19, 2009 at 7:38 AM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: hi, This test is failing because Debian doesn't have the sdlmixer/smpeg patch which fixes that bug. Best to add a skip for that test on non-windows+mac. I don't think we should depreciate mp3, but rather depreciate smpeg :) cu, To add to that... also strongly recommend not using mp3 in the docs. cu,
Re: [pygame] file mods and svn props for executables
Hi René, Try this: python -m pygame.docs By the way, we all need to take more care in considering Python 3 compatibility. I just discovered that an executable package in Python 3 needs a __main__.py module. Lenard Lenard Lindstrom wrote: Oh wait, I already removed go.py from examples. It wasn't needed. But I can make pygame.examples list available examples. And I will still update the docs. Lenard Lenard Lindstrom wrote: That should also work with examples. I will give it a try and update the docs. Lenard René Dudfield wrote: hi... I made a tiny little change to test/__init__.py which just imports pygame.tests.go if __name__ == __main__ Seems like a fairly clean way to do it -- keeping that code separate in the go.py seems nice. So these work now: $ python -m pygame.tests --help $ python -m pygame.tests $ etc.
Re: [pygame] Pygame and mp3 files
ah ok. Depreciate sounds good to me. I think just skip the test, and let's forget about it... smpeg really is so bad it shouldn't be used :) cu, On Tue, May 19, 2009 at 11:02 AM, Lenard Lindstrom le...@telus.net wrote: Hi René, I used the latest smpeg from SVN and it still crashes. I suspect the problem is not limited to Debian, but Debian's free() catches it. Deprecating smpeg deprecates mp3. The replacement is libmad, a GPL library. An alternative to disabling the test is for someone outside the Greater USA to create a new house_lo.mp3 with different options to see if it works. I agree about a warning in the documents. Lenard René Dudfield wrote: On Tue, May 19, 2009 at 7:38 AM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: hi, This test is failing because Debian doesn't have the sdlmixer/smpeg patch which fixes that bug. Best to add a skip for that test on non-windows+mac. I don't think we should depreciate mp3, but rather depreciate smpeg :) cu, To add to that... also strongly recommend not using mp3 in the docs. cu,
Re: [pygame] file mods and svn props for executables
Nice one! (it brings up a browser with the docs in it, for those interested) I'll try to keep testing with py3k as I go :) I think we can we add some tests for the python -m pygame.examples etc? Probably not necessary... but maybe a good thing to add at some point... cu, On Tue, May 19, 2009 at 11:34 AM, Lenard Lindstrom le...@telus.net wrote: Hi René, Try this: python -m pygame.docs By the way, we all need to take more care in considering Python 3 compatibility. I just discovered that an executable package in Python 3 needs a __main__.py module. Lenard Lenard Lindstrom wrote: Oh wait, I already removed go.py from examples. It wasn't needed. But I can make pygame.examples list available examples. And I will still update the docs. Lenard Lenard Lindstrom wrote: That should also work with examples. I will give it a try and update the docs. Lenard René Dudfield wrote: hi... I made a tiny little change to test/__init__.py which just imports pygame.tests.go if __name__ == __main__ Seems like a fairly clean way to do it -- keeping that code separate in the go.py seems nice. So these work now: $ python -m pygame.tests --help $ python -m pygame.tests $ etc.
Re: [SPAM: 3.500] Re: [pygame] This one baffles me
Greg Ewing wrote: RB[0] wrote: Yeah, if you want to convert just the tabs at the start of a line, you would need to do: print open(myfile.py).read().replace(\n+ *4, \t) No, that only replaces the first group of 4 spaces on each line, and removes the newlines as well. The obvious way to do this properly is to loop over the lines and use the expandtabs() string method. Oh, and write a test first
Re: [pygame] Pygame and mp3 files
Ok, just test .wav and .ogg for now. I am adding a warning to the music docs now. Lenard René Dudfield wrote: ah ok. Depreciate sounds good to me. I think just skip the test, and let's forget about it... smpeg really is so bad it shouldn't be used :) cu, On Tue, May 19, 2009 at 11:02 AM, Lenard Lindstrom le...@telus.net wrote: Hi René, I used the latest smpeg from SVN and it still crashes. I suspect the problem is not limited to Debian, but Debian's free() catches it. Deprecating smpeg deprecates mp3. The replacement is libmad, a GPL library. An alternative to disabling the test is for someone outside the Greater USA to create a new house_lo.mp3 with different options to see if it works. I agree about a warning in the documents. Lenard René Dudfield wrote: On Tue, May 19, 2009 at 7:38 AM, René Dudfield ren...@gmail.com mailto:ren...@gmail.com wrote: hi, This test is failing because Debian doesn't have the sdlmixer/smpeg patch which fixes that bug. Best to add a skip for that test on non-windows+mac. I don't think we should depreciate mp3, but rather depreciate smpeg :) cu, To add to that... also strongly recommend not using mp3 in the docs. cu, -- Lenard Lindstrom le...@telus.net
