remove boardUpdate signal and emit game-updates from FICSGame

[GoogleCodeExporter]

I was observing a FICS game and had about 37 game tabs open when I got the 
ParsingError below. I forgot to take a screenshot, but the board did show a 
queen on a8 checking the king in its final position, so the FEN in the parsing 
error doesn't seem to be correct.

Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 811, in __bootstrap_inner
    self.run()
  File "/home/gatto/code/hg/pychess/lib/pychess/Utils/GameModel.py", line 571, in run
    self.boards[-2])
  File "/home/gatto/code/hg/pychess/lib/pychess/Players/ICPlayer.py", line 154, in makeMove
    move = parseSAN (board1, sanmove)
  File "/home/gatto/code/hg/pychess/lib/pychess/Utils/Move.py", line 112, in parseSAN
    return Move (lmove.parseSAN (board.board, san))
  File "/home/gatto/code/hg/pychess/lib/pychess/Utils/lutils/lmove.py", line 375, in parseSAN
    raise ParsingError, (san, errstring, board.asFen())
ParsingError: ('Qa8+', u'no Queen is able to move to a8', 
'1K6/8/6p1/k4p1p/4pP1P/2p1P1P1/8/8 w - - 0 51')

Original issue reported on code.google.com by mattgatto on 13 Jun 2014 at 1:00

[GoogleCodeExporter]

The FEN in the parsing error not just "doesn't seem to be correct", but is 
definitely from another game.

Original comment by gbtami on 14 Jun 2014 at 6:06

[GoogleCodeExporter]

Wow, really weird. Should I post the full log?

Original comment by mattgatto on 14 Jun 2014 at 6:20

[GoogleCodeExporter]

Yes, please. Maybe we can figure out what was the other game.

Original comment by gbtami on 14 Jun 2014 at 6:59

[GoogleCodeExporter]

Original comment by mattgatto on 14 Jun 2014 at 7:05

Attachments:

• 2014-06-12_15-52-20.log.bz2

[GoogleCodeExporter]

Seems there was another junglescrabble vs. Kombo lightning rated game with same 
322 game number, started at 16:46:48. One hour before the game emitting parsing 
error. It contains the FEN shown in parsing error.

Original comment by gbtami on 14 Jun 2014 at 8:29

[GoogleCodeExporter]

Good catch. I guess we need to filter out board updates based on more than 
player names and game number in ICPlayer.__boardUpdate, or just disconnect 
ICPlayer's from "boardUpdate" signals after the game ends rather than when the 
widget is deleted. The former would be better though, because that way it'll be 
easier to add in functionality in the future for game widgets to be able to 
resume games after adjournment when the player logs back in. One possibility 
would be to add a game start time timestamp FICSGame attribute and use that in 
FICSGame.__hash__.

Original comment by mattgatto on 20 Jun 2014 at 4:33

[GoogleCodeExporter]

Unfortunately FICS doesn't send any timestamp info on board updates, so we will 
never know which FICSGame got the board update if they have same players and 
gameno. I added a "current" flag to the ICPlayer instead, indicating which is 
the latest using the same players and gameno.

Original comment by gbtami on 20 Sep 2014 at 10:55

[GoogleCodeExporter]

This issue was closed by revision ca892a01333e.

Original comment by gbtami on 20 Sep 2014 at 10:56

• Changed state: Fixed

[GoogleCodeExporter]

Why do we need FICS to send us timestamp info when we could just use our own 
timestamp?

Original comment by mattgatto on 24 Sep 2014 at 7:12

[GoogleCodeExporter]

If we have start time timestamp FICSGame attribute and a message is coming from 
FICS we never know which game it belongs to if there are several ones with same 
gameno+wplayer+bplayer in our FICSGames.

Original comment by gbtami on 24 Sep 2014 at 7:26

[GoogleCodeExporter]

Couldn't we just assume that the latest board-update corresponds to the
FICSGame with the newest timestamp?

Original comment by mattgatto on 24 Sep 2014 at 8:04

[GoogleCodeExporter]

For games were playing at least.

Original comment by mattgatto on 24 Sep 2014 at 8:06

[GoogleCodeExporter]

Sorry, I forgot this is happened in an observed game.

Original comment by mattgatto on 24 Sep 2014 at 8:07

[GoogleCodeExporter]

Ideally, ICPlayer shouldn't have to figure out whether the board-update applies 
to its game, and will only receive board-updates that apply to its game. The 
controller, FICSGames, BoardManager, or whatever should figure this out, 
possibly by retrieving the applicable game from FICSGames based on the current 
FICSGame gameno+wplayer+bplayer hash and doing game.update(update) which would 
emit the update only to listeners on that game.

Original comment by mattgatto on 24 Sep 2014 at 8:25

[GoogleCodeExporter]

Original comment by mattgatto on 24 Sep 2014 at 8:36

• Changed title: remove boardUpdate signal and emit game-updates from FICSGame
• Changed state: Reopened
• Added labels: Type-Task
• Removed labels: Type-Defect

[GoogleCodeExporter]

Matt, feel free to fix my fix, please!

Original comment by gbtami on 24 Sep 2014 at 8:37

[GoogleCodeExporter]

Original comment by mattgatto on 27 Sep 2014 at 12:37

• Changed state: Started