This change is needed to skip a nasty behaviour: if the string triggered
a decoding error, it will trigger one *AGAIN* if the string is printed
to console. By writing directly to sys.stderr we skip the
locale/conversion issues and get the troublesome string directly in a
file where it is stored as a raw sequence of octets.
This encoder is used to handle input from HH conversion, which needs to
end up as UTF-8 in the database. Switch the open-coded routine from
Database.py to this common routine so all encodings now take place in
the same file.
It seems that running encoder.encode() on a latin1/latin9 string results
in, yes a bloody UnicodeDecodeError. Decode error on .encode()...
Really. This way the modification from non-unicode string to real
unicode appears to work better.
The strings (names) as stored in database should always be UTF-8;
whatever the display locale is, we then need to convert from the storage
encoding to session encoding. When making database queries with players
names in them, the names must be reconverted to UTF-8.
If the system (display) locale is UTF-8, there is no need to encode to
either direction. In fact, running the .encode() routine appears to
mangle a valid UTF-8 string to a worse condition, effectively breaking
it.
Issues Pokerstars when playing heads-up on ring games,
being both on button and small blind now supported
!!if not solved the winnings of the (button, small blind) is stored as rake!!
Post both small and big blind when re-entering ring games solved
The names are stored in UTF-8, so simply converting the name from UTF-8
to Configuration.LOCALE_ENCODING before putting the string in tooltip is
enough. Neat.
The names are stored in UTF-8, so simply converting the name from UTF-8
to Configuration.LOCALE_ENCODING before putting the string in tooltip is
enough. Neat.
The names are stored in UTF-8, so simply converting the name from UTF-8
to Configuration.LOCALE_ENCODING before putting the string in tooltip is
enough. Neat.
All conversions from Grigorij
street0_3BChance
street0_3BDone
street0_4BChance
street0_4BDone
stealAttemptChance
stealAttempted
foldBbToStealChance
foldBbToStealChance
foldSbToStealChance
foldedSbToSteal
foldedBbToSteal
3Bet, 4Bet in Stud does appear to work.
Unable to test steal in Stud games, all example hands in micros do not have a chance (I believe)
All conversions from Grigorij
street0_3BChance
street0_3BDone
street0_4BChance
street0_4BDone
stealAttemptChance
stealAttempted
foldBbToStealChance
foldBbToStealChance
foldSbToStealChance
foldedSbToSteal
foldedBbToSteal
3Bet, 4Bet in Stud does appear to work.
Unable to test steal in Stud games, all example hands in micros do not have a chance (I believe)
The names should be always in UTF-8 encoding. At least for PostgreSQL
the encdoding of the database comes from the time of running 'initdb'
(which is different from 'createdb') and if the encoding was selected or
set to something else at that time, the following error will occur:
File ".../pyfpdb/Database.py", line 1630, in <lambda>
self.pcache = LambdaDict(lambda key:self.insertPlayer(key, siteid))
File ".../pyfpdb/Database.py", line 1661, in insertPlayer
c.execute (q, (site_id, _name))
File "/usr/lib/python2.5/encodings/iso8859_15.py", line 12, in encode
return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode character u'\u2122' in
position 10: character maps to <undefined>
This happens because 'name' is a regular string as opposed to a valid
unicode object. By forcing the string to unicode and encoding it in
UTF-8 the error goes away. In my case the database encoding was
ISO-8859-15 (latin9) but any other "wrong" encoding would trigger the
same problem.
This is a relatively common problem in python.
