In a current project of mine, I’m experiencing a crash on game-startup in the distributable build under Windows.
The log-file shows the following:
Known pipe types:
(all display modules loaded.)
Traceback (most recent call last):
File "__main__", line 1163, in <module>
File "__main__", line 337, in __init__
File "encodings.cp1252", line 23, in decode
UnicodeDecodeError: 'charmap' codec can't decode byte 0x9d in position 2640: character maps to <undefined>
This crash doesn’t seem to appear under Linux, in either the distributable build for that platform or in the development environment. (I’m developing under Linux, not Windows.)
Of course, as Linux is my primary operating system, it’s possible that I have something installed there which I lack under Windows–but if so, I don’t know what.
I have checked, and the font that I’m using in the project appears to be present in the build. (Although I am using the default font in one place…)
Does anyone know what might be going wrong, and/or how I might fix this and get the Windows build running…?
I think the problem is in the encoding of the file and it does not match the mode that you use when opening.
Perhaps you don’t use this parameter explicitly, most likely this is the problem.
So you think that it might be a file-reading issue…?
Hmm… That could be: I am reading a text-file at start-up. I’m doing so via Panda’s “direct.stdpy.file” module, and am passing the “rt” flags.
However, the text-file was made in Linux–perhaps under Windows the file-loading is tripping over some Linux-specific encoding…?
In fact, I’ve just tried a line-end conversion tool in Linux (“toms”), and it seems to think that the file in question is binary–despite the fact that I can open said file in a text-editor with no trouble, and the “file” command identifies it as a text-file! o_0
I’m going to try something in Windows–I’ll be back shortly to report my findings, I intend…
def open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True):
"""This function emulates the built-in Python open() function, additionally
providing support for Panda's virtual file system. It takes the same
arguments as Python's built-in open() function.
Sorry, I meant the encoding mode.
Ah, that would be the parameter named “encoding” in the code that you posted above, yes? I hadn’t thought of that…
What is the default encoding…?
Over on the Python Docs, it indicates that the default is “utf-8”, and a call to the “file” command reports my file as being “UTF-8 Unicode text, with very long lines”. So, if Panda’s default matches the Python default, then it looks like the file should be fine…
As to my attempt to try something in Windows:
Okay, so I booted into Windows, opened the relevant file, and tried manually fixing the line-endings and re-saving it. This didn’t help, alas–the program still crashes on startup, with much the same text in the log-file.
However, looking more closely, I do think that I’ve confirmed that it is this file that’s causing the problem: It identifies line 337 as the source of the problem, and it is on that line that I read the file (directly after opening it on line 336).
Specifically, here is my code:
fileObj = open("license.txt", "rt")
except IOError as e:
Line 337 is the call to “setText”, which contains a call to “fileObj.read()”.
I don’t know, but the point is.
- Find out the actual encoding of the file.
- Specify it when opening the file.
Fair, I suppose.
Well, thank you for your help!
Well, I’ve tried it and…
You are quite right! Explicitly specifying the encoding did the job!
For any others with similar issues, here then is the altered line that worked for me: (Modify to suit your specific case, of course.)
fileObj = open("license.txt", "rt", encoding = "utf-8")
(Note the “encoding” parameter".)