Re: C file pointers and file loading

hi,

Or maybe we should build python with the correct runtime?  ;)

What changes did you have in mind Lenard?  I'm not quite sure how
you'd handle this...

pygame.image.load(open("some_image", "rb"))

I guess you'd implement a sdl file object by wrapping the python
object - rather than just taking the file pointer from the python
object.  I guess that wouldn't be as efficient, because then you'd
need to use the python API to read it, but it would probably be ok.

I think this might work fine for the files... I'm not sure if there
would be any other problems mixing runtimes?  There might be other
problems with this, but I guess we won't find out until we try.
Previously mixing runtimes mainly had issues with files that I could
see.

It sure would make it easier to use the supplied SDL and python rather
than compiling our own.

cheers,

On Thu, May 1, 2008 at 6:58 AM, Brian Fisher
<brian@...> wrote:
> why wouldn't we continue to do what is done now, and build SDL ourselves
> with the correct runtime?
>

Re: C file pointers and file loading

I am open to someone building SDL with Visual Studio 2008. It was done 
with VC 2003. But there are twelve separate libraries in the 
dependencies. It was tricky enough getting them to build with the Unix 
like Msys.

Lenard

Brian Fisher wrote:
> why wouldn't we continue to do what is done now, and build SDL 
> ourselves with the correct runtime?
>
> On Wed, Apr 30, 2008 at 10:51 AM, Lenard Lindstrom <len-l@... 
> <mailto:len-l@...>> wrote:
>
>     When pygame.image.load is given a Python file object it passes the
>     C FILE pointer on to SDL by calling SDL_RWFromFP in
>     get_standard_rwop in rwobject.c. While this has worked so far on
>     Windows it may soon be the case that SDL will not use the same C
>     run-time as Python. I tried using an SDL linked to msvcrt with a
>     Python linked to msvcr71 and predictably the interpreter crashed
>     when loading an image from an open file. Since great care has been
>     taken in Pygame to separate SDL memory management from Python's it
>     should also be done for file access. I don't suggest implementing
>     the changes to rwobject.c immediately, but if it is necessary I
>     can will do them.
>

Re: C file pointers and file loading

It requires nothing so drastic as treating a Python file as a generic 
file-like object. The extension modules should share the same run-time 
as Python so it is just a matter of moving the freads and fwrites to 
Pygame. I have basically transplanted SDL_RWFromFP to rwobject.c. All 
that is left is handling image saves in imageext.c. These changes will 
only be applied to pygame/branches/Python_2_6. If they make sense then 
they can be merged with the trunk later.

Lenard

René Dudfield wrote:
> hi,
>
> Or maybe we should build python with the correct runtime?  ;)
>
> What changes did you have in mind Lenard?  I'm not quite sure how
> you'd handle this...
>
> pygame.image.load(open("some_image", "rb"))
>
> I guess you'd implement a sdl file object by wrapping the python
> object - rather than just taking the file pointer from the python
> object.  I guess that wouldn't be as efficient, because then you'd
> need to use the python API to read it, but it would probably be ok.
>
>
>
> I think this might work fine for the files... I'm not sure if there
> would be any other problems mixing runtimes?  There might be other
> problems with this, but I guess we won't find out until we try.

Re: C file pointers and file loading

Re: C file pointers and file loading

Brian Fisher wrote:
> On Wed, Apr 30, 2008 at 4:22 PM, René Dudfield <renesd@... 
> <mailto:renesd@...>> wrote:
>
>
>     Or maybe we should build python with the correct runtime?  ;) 
>
>  
>
>     It sure would make it easier to use the supplied SDL and python rather
>     than compiling our own.
>
>
> Practically speaking, there is no such thing as a "supplied SDL" on 
> windows. In particular SDL is never installed to a shared location on 
> windows, and is highly unlikely to ever work that way in the future, 
> so pygame will always need to bring an SDL build to a place where it 
> can load it from on Windows. And that's the reason why it would make 
> perfect sense to build our own SDL, with the right (i.e. matching) 
> runtime.
>
> ...there are prebuilt SDL's for VC6 and VC2005, and being able to use 
> prebuilts from libsdl.org <http://libsdl.org> would be nice cause then 
> more people could build pygame on windows easier, and also possibly 
> test with other SDL versions - however there may end up being a VC2008 
> prebuilt sdl too.
>
> ... but dang, why oh why is python picking just the crappy Visual 
> Studio releases to build with...
>
>
> ... I don't disagree that not having a runtime matching problem would 
> be nice, but I do think it's a problem with an existing solution.
Linking against msvcr90.dll is not the problem. Building with the 
configure/make tools using msvcr90.dll is. I posted on comp.lang.python 
and got a reply. It has given me an idea. It isn't exactly pretty, but 
it may do what we want.

--

-- 
Lenard Lindstrom
<len-l@...>

Re: C file pointers and file loading

Lenard Lindstrom wrote:
> Brian Fisher wrote:
>> On Wed, Apr 30, 2008 at 4:22 PM, René Dudfield <renesd@... 
>> <mailto:renesd@...>> wrote:
>>
>>
>>     Or maybe we should build python with the correct runtime?  ;)
>>  
>>
>>     It sure would make it easier to use the supplied SDL and python 
>> rather
>>     than compiling our own.
>>
>>
>> Practically speaking, there is no such thing as a "supplied SDL" on 
>> windows. In particular SDL is never installed to a shared location on 
>> windows, and is highly unlikely to ever work that way in the future, 
>> so pygame will always need to bring an SDL build to a place where it 
>> can load it from on Windows. And that's the reason why it would make 
>> perfect sense to build our own SDL, with the right (i.e. matching) 
>> runtime.
>>
>> ...there are prebuilt SDL's for VC6 and VC2005, and being able to use 
>> prebuilts from libsdl.org <http://libsdl.org> would be nice cause 
>> then more people could build pygame on windows easier, and also 
>> possibly test with other SDL versions - however there may end up 
>> being a VC2008 prebuilt sdl too.
>>
>> ... but dang, why oh why is python picking just the crappy Visual 
>> Studio releases to build with...
>>
>>
>> ... I don't disagree that not having a runtime matching problem would 
>> be nice, but I do think it's a problem with an existing solution.
> Linking against msvcr90.dll is not the problem. Building with the 
> configure/make tools using msvcr90.dll is. I posted on 
> comp.lang.python and got a reply. It has given me an idea. It isn't 
> exactly pretty, but it may do what we want.
>
I have built an SDL.dll that looks for msvcr90.dll . It can be found, 
along with a test program at:

http://www3.telus.net/len_l/pygame/

md5sum:

f5b71d9934d35c35a24b668ad8023146 *VC-2008-Run-Time-test.zip

It has no manifest though. I have notified the Python developers at 
comp.lang.python. It is now their problem.

--

-- 
Lenard Lindstrom
<len-l@...>

win9x testers wanted. Re: C file pointers and file loading

hi,

it appears the msvcr90.dll does not work on win9x.

Is anyone able to test the python alpha release on their win9x machine?
http://python.org/download/releases/2.6/

The new python2.6 alpha links to msvcr90.dll rather than msvcr71.dll
so we are trying to see if python2.6 alpha works on win9x.  To
hopefully try and convince the python developers to switch back to
msvcr71.dll - if this is the case.

So are you able to install the python2.6 alpha, and try and run it?

cheers,

Re: win9x testers wanted. Re: C file pointers and file loading

I know from personal experience it doesn't. Python 2.6 won't even 
install. The whole side-by-side assembly mechanism (manifests) that 
Visual Studio 2008 depends is only backported to Windows 2000.

Lenard

René Dudfield wrote:
> hi,
>
> it appears the msvcr90.dll does not work on win9x.
>
> Is anyone able to test the python alpha release on their win9x machine?
> http://python.org/download/releases/2.6/
>
> The new python2.6 alpha links to msvcr90.dll rather than msvcr71.dll
> so we are trying to see if python2.6 alpha works on win9x.  To
> hopefully try and convince the python developers to switch back to
> msvcr71.dll - if this is the case.
>
>
>
> So are you able to install the python2.6 alpha, and try and run it?
>
>
>
>   

RE: win9x testers wanted. Re: C file pointers and file loading

> -----Original Message-----
> From: owner-pygame-users@...
[mailto:owner-pygame-users@...] On
> Behalf Of René Dudfield
> Sent: Thursday, May 01, 2008 12:20 AM
> To: pygame-users@...
> Subject: win9x testers wanted. Re: [pygame] C file pointers and file
> loading
> 
> hi,
> 
> it appears the msvcr90.dll does not work on win9x.
> 
> Is anyone able to test the python alpha release on their win9x machine?
> http://python.org/download/releases/2.6/
> 
> The new python2.6 alpha links to msvcr90.dll rather than msvcr71.dll
> so we are trying to see if python2.6 alpha works on win9x.  To
> hopefully try and convince the python developers to switch back to
> msvcr71.dll - if this is the case.
> 
> 
> 
> So are you able to install the python2.6 alpha, and try and run it?
> 
> 
> 
> cheers,

It is worth noting that win9x is one of the platforms specifically
unsupported by python 2.6:
http://www.python.org/dev/peps/pep-0011/

It looks like this is planned deprecation.

---------
John Krukoff
helot@...

Maybe a bug in pygame.draw.circle?

Hi, we found a posible bug in "pygame.draw.circle" function using
pygame1.8 (we don't try with
other versions).

When we set a circle border, the "pygame.draw.circle" function puts
some little pixels
like noise. This is a screenshot of the posible bug:

    http://www.losersjuegos.com.ar/incoming/descargas/20080501/circle_border.png

and this is a sample code:

--- %< ---
import pygame

WHITE = (255, 255, 255)
position = 100, 100
screen = pygame.display.set_mode((320, 240))

pygame.draw.circle(screen, WHITE, position, 50, 20)
pygame.display.flip()
pygame.time.wait(1000)
--- %< ---

note that when remove the 50 value of border, the circle will draw fine:

    http://www.losersjuegos.com.ar/incoming/descargas/20080501/circle_fill.png

Thanks!

--

-- 
Hugo Ruscitti
www.losersjuegos.com.ar