Maybe my cStringIO has been transparently replaced by StringIO for some reason. I would think that cStringIO would be available on this platform but perhaps not.
On Mon, Nov 23, 2009 at 7:03 PM, Lenard Lindstrom <le...@telus.net> wrote: > Strange. cStringIO works for me. I have localized the problem to the first > call to the file like object's tell method. But since this is the first > method called, it might not be limited to it. > > Lenard Lindstrom > > Bryce Schroeder wrote: >> >> cStringIO seems to have the same problem for me. >> It is already using open with 'rb'. >> Thanks for all your help, I will await the next version / patch I guess. >> >> On Mon, Nov 23, 2009 at 5:24 PM, Lenard Lindstrom <le...@telus.net> wrote: >> >>> >>> Hi Bryce, >>> >>> Try using cStringIO instead. And make sure to open the file 'rb' (this >>> won't >>> matter on Linux, but will on Windows). I reproduced your problem with a >>> modified pygame.examples.fonty, and yes, it appears to be a bug. StringIO >>> instances should work. >>> >>> Lenard Lindstrom >>> >>> Bryce Schroeder wrote: >>> >>>> >>>> This code reproduces the problem. It is also as an attachment. >>>> >>>> My system: >>>> uname -a: >>>> Linux thales 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC >>>> 2009 x86_64 GNU/Linux >>>> >>>> >>>> -------file: tester.py -------------- >>>> import pygame, StringIO, sys >>>> pygame.font.init() >>>> if len(sys.argv) != 2: >>>> print >> sys.stderr, "Usage: python tester.py font.ttf" >>>> sys.exit(1) >>>> >>>> font = pygame.font.Font(sys.argv[1], 12) >>>> print "Loaded the font as a file:", font >>>> >>>> test = open(sys.argv[1]).read() >>>> stio = StringIO.StringIO(test) >>>> font2 = pygame.font.Font(stio, 12) >>>> print "Loaded the font as a StringIO:", font2 >>>> ------------------------------------------------- >>>> >>>> On Mon, Nov 23, 2009 at 2:27 PM, Bryce Schroeder >>>> <bryce.schroe...@gmail.com> wrote: >>>> >>>> >>>>> >>>>> Okay: >>>>> I wrote the string (self.parts['font']) out to a temporary file and >>>>> diff'd it against the original file, and they are identical. >>>>> Pygame successfully loads the font from the temporary file, and the >>>>> font works normally. However I would definitely like to >>>>> find a less kludgish solution to the problem. >>>>> >>>>> The particular font does not appear to matter, or at least, a wide >>>>> variety of truetype fonts are affected - I can't load Junius Unicode >>>>> or Free Serif from a StringIO either, but I can load them from files. >>>>> >>>>> It worked about six to eight months ago. Sorry I can't be more >>>>> specific - I sort of mothballed the project for a while. >>>>> >>>>> Sorry I didn't provide a "demonstration program" I will try to keep >>>>> that in mind in the future. >>>>> >>>>> - Bryce >>>>> >>>>> >>>>> On Mon, Nov 23, 2009 at 2:05 PM, Brian Fisher >>>>> <br...@hamsterrepublic.com> >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>> Pygame should be supporting a file-like object no problem, so this >>>>>> seems >>>>>> like it could be a bug. >>>>>> >>>>>> Can you be more specific on when in the past it worked, and what >>>>>> happened >>>>>> between then and when it segfaults now? >>>>>> >>>>>> Also, it's not clear from your problem description whether the problem >>>>>> is >>>>>> that pygame crashes when loading from a file-like object, or if pygame >>>>>> crashes on a specific set of font data. >>>>>> >>>>>> So I would suggest doing a sanity check here by writing the >>>>>> self.parts['font'] string to a temp file, and trying to load from >>>>>> that, >>>>>> as a >>>>>> way of being able to determine if the crash is caused by the file-like >>>>>> object reading, or by some problem with the contents of the file-like >>>>>> object. >>>>>> >>>>>> So something like: >>>>>> ------------ >>>>>> class Font(Resource): >>>>>> .... >>>>>> def pygame_font(self,size): >>>>>> file(temp_file_name, "w").write(self.parts['font']) >>>>>> return pygame.font.Font(temp_file_name, size) >>>>>> os.unlink(temp_file_name) >>>>>> ------------ >>>>>> If that still crashes, then pygame has trouble with that font content, >>>>>> and >>>>>> then the question would be to figure out what about that font content >>>>>> is >>>>>> causing problems. If that doesn't crash, then the problem would be >>>>>> with >>>>>> accessing the content as a file-like object. >>>>>> >>>>>> >>>>>> ... finally, as general advice to all people posting problems - if you >>>>>> can >>>>>> send a completely self-contained reproducible case, then you are much >>>>>> more >>>>>> likely to get good help and results faster. As an example in this >>>>>> case, >>>>>> providing the contents of the self.parts['font'] string in an attached >>>>>> file >>>>>> with a simple script that tries to load from a StringIO using that >>>>>> file's >>>>>> contents, would make this easily reproducible and testable by fellow >>>>>> mailing >>>>>> listers - but without knowing what the contents of the string in >>>>>> question >>>>>> are, it may actually be practically impossible for anyone else to test >>>>>> themselves. >>>>>> >>>>>> >>>>>> On Mon, Nov 23, 2009 at 12:38 PM, Bryce Schroeder >>>>>> <bryce.schroe...@gmail.com> wrote: >>>>>> >>>>>> >>>>>>> >>>>>>> (My apologies if this is a double-post. I didn't get a copy of the >>>>>>> message or see it in the archive, so I'm trying again.) >>>>>>> >>>>>>> I have a pygame program that worked in the past on both Linux and >>>>>>> Windows, but now results in a segfault, at least on Linux. (I can't >>>>>>> test it on Windows.) >>>>>>> The segfault occurs in this code: >>>>>>> >>>>>>> class Font(Resource): >>>>>>> .... >>>>>>> def pygame_font(self,size): >>>>>>> return pygame.font.Font(StringIO.StringIO(self.parts['font']), >>>>>>> size) # Segfaults here >>>>>>> >>>>>>> >>>>>>> self.parts['font'] is a string containing a truetype font loaded from >>>>>>> a file. I have checked that the string contains the file like it is >>>>>>> supposed too. Any suggestions? >>>>>>> >>>>>>> >>>>>> >>>>>> >>> >>> > >