Specifically you are hitting:
http://groups.google.com/group/reviewboard/msg/13225461e83d7743
The BOM mark at the start of the file. Thanks for making the file
available so this could be confirmed. If this is a new file the diff
will include the BOM.
The error above usually occurs when there is an assumption that there is
a a Unicode string, and file diff contents should be bytes (i.e. it
shouldn't go through ANY string/unicode processing).
Can you post the error, the complete traceback? Along with the version
you are using.
You mention you've customized postreview (pretty common, my company does
too) but it is possible that your new code has the Unicode assumption in
it rather than the original RBtools. It is worth your while doing a
quick test with a virgin version of the latest RBTools (that traceback
would be the most helpful to people on the list).
Chris
The trace back does not appear to show that line of code. There appears
to be a concatenation of unicode and (2.x) str (bytes) type.
This may well be "fixed" by trying python 2.6 (or even 2.5) as you
suggested. You'd need to debug this through to see where the Unicode
string is coming from, 2.7 is the cross over version for 2.x and 3 and
it does try to deal with Unicode types when possible. Of course json
data is supposed to be utf8 encoded so this maybe where this is failing
down.
I've left the traceback below for reference.
Whilst this impacted a Windows user (Windows Python defaults to 7 bit
US-ASCII encoding) with a utf8 encoded (diff) file. This could easily
impact any user on any platform where the encoding for the file is not
valid for the (default) Python site string encoding. For example this is
likely to impact users of Python 2.7 if:
* diff contains a single latin1 character (e.g. copyright symbol, an
"e" with an accent, etc.) and the site encoding is not latin1.
This would impact all Unix/Linux platforms where the Python
installation tends to default to utf8
It looks like the Python 3.x byte/string difference that is in 2.7 will
need to be looked at. Possibly via an encoding flag to postreview.
I'm snowed under at the moment otherwise I'd look at this myself :-(
I have a number of Windows users (with non ascii diffs) so I'm at risk
for this problem BUT this isn't an issue for me as I supply them with an
exe generated with Python 2.4 and py2exe. Craig This may be your best
option.
Chris