GNUChess hint mode does not show final hints

[GoogleCodeExporter]

What steps will reproduce the problem?
1.  Setup GNUChess as analyzer and enable hint mode & restart.
2.  Play game against PyChess engine at easy level.
3.  Once you are in a position with a forced mate (Mate in X moves) you
will no longer see the green hint arrows.

What is the expected output? What do you see instead?

     A green arrow to show the next move in the forced mate.  Instead I see
nothing.

Does it happen every time?

     Yes

What version of the product are you using?

     SVN r1568

Did you use an installed version of PyChess or did you run in from a
tarball/svn?

     SVN

Please provide any additional information below.

    I think the bug is self explanatory.  Please let me know if you need
any help!  Thanks for all your good work!

Please attach the latest pychess logfile. It's in a hidden folder, under
your homedirectory, named ".pychess/"

Thanks for everything!!!  Keep up the good work!!!

Sincerely,
John

Original issue reported on code.google.com by zollo.j...@gmail.com on 18 Jan 2010 at 7:33

Attachments:

• 2010-01-18_02-24-59.log
• 2010-01-18_02-26-41.log

[GoogleCodeExporter]

Just found out this also happens with crafty.

Original comment by zollo.j...@gmail.com on 18 Jan 2010 at 7:37

Attachments:

• 2010-01-18_02-34-39.log
• 2010-01-18_02-34-48.log

[GoogleCodeExporter]

I think I figured something out:

Analysis (hint mode) works fine with several UCI engines:  Fruit, Glaurung, 
Toga II,
and Stockfish.

Hint mode has a problem with forced mates with the xboard chess engines:  
GNUChess
and Crafty.

Maybe that's why that little green arrow disappears when mate is near with 
GNUChess
and Crafty and not with those others!!!

PS  Thank you so much for adding Stockfish support.  Stockfish rules!  Yea 
PyChess! 
Yea PyChess team!  Yea everyone!!!

Original comment by zollo.j...@gmail.com on 18 Jan 2010 at 8:21

[GoogleCodeExporter]

Hi Zollo, thank you for the report!
I've looked into the problem, and it seams to be twofold:
 * There was a problem in the parsing of analysis near mate,
 * And sometimes the engines simply didn't say anything.

I think I've fixed the first one, but please update to trunk and see if 
anything has 
changed.
For the second problem we could save a previous analysis and truncate the 
played 
moves, to have something to give. We wouldn't be able to read the score then 
though.

Original comment by lobais on 18 Jan 2010 at 10:35

[GoogleCodeExporter]

Thank you Thomas.  You are a dear friend and a life saver.  I will look into the
update soon.  I promise.

Sincerely,
John D. Zollo

Original comment by zollo.j...@gmail.com on 18 Jan 2010 at 8:05

[GoogleCodeExporter]

Trunk seems to be broken.  I make one move against either the PyChess engine or
GNUChess and the program does nothing.  I don't know what the problem is.  (I'm 
also
using Python 2.5 if that makes a difference.)

Please let me know if you need anything!

Sincerely,
-John

Original comment by zollo.j...@gmail.com on 18 Jan 2010 at 8:11

[GoogleCodeExporter]

1573 looked ok.  1574 couldn't start game without crashing.  And then 1575 could
start without crash, but now has the new bug.  So it looks like this new bug 
appeared
in 1575.

-John

Original comment by zollo.j...@gmail.com on 18 Jan 2010 at 8:21

[GoogleCodeExporter]

Sorry, my tests on r1573 seem to show Hint mode still has an issue when near 
mate
with an xboard engine.  I'll wait for the next stable trunk release and try 
again.

Thanks for all your help everyone!!! (And by everyone I mean you Thomas ;-)  )

Thanks!
Sincerely,
John

Original comment by zollo.j...@gmail.com on 18 Jan 2010 at 8:32

[GoogleCodeExporter]

Hi John,
I\ve fixed the immediate problems in r1577, but like you, I can still reproduce 
the 
analysis problems.

However, when I look in my log, it seams like the problem is solely due to the 
engines not emitting anything, or writing something which is absolutely 
nonsense! 
Look at these two lines:
01:44:18 ('Gnuchess', '01:01:0.237') Debug: 2. -Mat 1 0 2263     Qd1 Qb4#
01:44:18 ('Python', '01:01:0.267') Debug: move b5#
It should be noted, that at the time, there were no queens at the table.

I don't see how we can do much against these kind of errors, but if you have 
good 
lines in your log, that aren't being parsed and used by PyChess, please upload 
them 
here.

Thanks for your time improving PyChess ; )
Cheers,
Thomas

Original comment by lobais on 19 Jan 2010 at 12:53

[GoogleCodeExporter]

Thomas,

Hmmm... maybe there weren't any queens on the board, but maybe gnuchess found a
mating solutions that involved promoting a pawn and choosing a Queen as the 
promotion
piece, so... maybe the Qd1 Qb4# didn't make any sense with the pieces CURRENTLY 
on
the board, maybe there was a mating pattern where there was two queens.  I'll 
try to
look into it if I have any time.  I'm very curious as to what's going on as I 
hope
you are too.

I'll let you know what I find.

Thank you Thomas.

Sincerely,
John

Original comment by zollo.j...@gmail.com on 19 Jan 2010 at 2:54

[GoogleCodeExporter]

Thomas,

   Still more problems.  I think the only time the "hint" mode (the analyzer) gets
messed up is when a pawn gets promoted.  Is there something to do with that?  
Maybe
PyChess doesn't understand GNUChess as an analyzer when it tried to promote -- 
maybe
it's just a matter of syntax -- maybe we don't understand what GNUChess is 
sending us
when analyzing -- I DON'T KNOW.  
    Either way I still have the bug and now crashes.  I'll let you know if I find any
more info.

Thanks!
-John

Original comment by zollo.j...@gmail.com on 20 Jan 2010 at 3:48

[GoogleCodeExporter]

Hi John,

I'm worried about the crashes. You say they appeared in a newer revision? Where 
and 
when do they appear?
Do you know, that you can go to View->Log while playing to get a nicer formated 
log, 
only for gnuchess? This way it should be easier to see, what, if anything, 
gnuchess 
is sending when the problems appear.

Thanks again for you time and patience,

Thomas

Original comment by lobais on 20 Jan 2010 at 4:36

[GoogleCodeExporter]

Thomas,

     You are right.  A big problem is when in a "forced" situation GNUChess does not
give any output on moves.  I'm looking into this -- maybe this is just an issue 
with
GNUChess we have to deal with.  I'll let you know if I find anything. 

Thanks!

Sincerely,
john

Original comment by zollo.j...@gmail.com on 20 Jan 2010 at 9:09

[GoogleCodeExporter]

Thomas,

    It just looks like GNUChess may not fully support analysis.  I'm just going to
use another engine in the meantime.  Unless you have a better idea.

-John

Original comment by zollo.j...@gmail.com on 20 Jan 2010 at 9:30

[GoogleCodeExporter]

I found another related bug. PyChess is not giving me the best move that 
GNUChess
analysis recommends.  Here's the log:

16:55:22 ('Gnuchess', '16:01:17.067') Debug: 39. d1e2
16:55:22 ('Gnuchess', '16:01:17.067') Debug: Root = 293, Phase = 7 
16:55:22 ('Gnuchess', '16:01:17.067') Debug: Time = 5.00, Max = 20.00, Left = 
0.00,
Moves = 0
16:55:22 ('Gnuchess', '16:01:17.067') Debug: Ply   Time     Eval      Nodes  
Principal-Variation
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 1+ 1769 0 1     d8=Q+
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 1. 1042 0 124   e6 Kg7 d8=Q
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 2+ 1134 0 316   e6
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 2. 1134 0 1040  e6
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 3+ 1769 0 1129  d8=Q+
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 3. 1134 0 2080  e6 Kh7 d8=Q Kg6
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 4+ 1769 0 2081  d8=Q+
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 4. 1197 0 9676  Kf4 Kg7 d8=Q Kf7 h4
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 5+ 1769 0 9677  d8=Q+
16:55:22 ('Gnuchess', '16:01:17.067') Debug: 5. Mat6 0 22175     d8=Q+
16:55:23 ('Gnuchess', '16:01:17.067') Debug: 6. Mat5 1 363457    d8=Q+
16:55:27 ('Gnuchess', '16:01:17.067') Debug: 7. Mat5 4 1832489   d8=Q+ Kh7
16:55:27 ('Gnuchess', '16:01:17.067') Debug: 8. Mat5 4 1841062   d8=Q+ Kh7
16:55:27 ('Gnuchess', '16:01:17.067') Debug: 9. Mat5 4 1857182   d8=Q+ Kh7

PyChess should have the green arrow over the pawn to promote to a mate (in what 
looks
like 5).  Instead, the green arrow is recommending Kf4, which is an INCREDIBLY
inferior move.  It looks like the code doesn't accept "d8=Q+" as an acceptable 
move.
 Thomas, am I right?

Thanks!
-John

Original comment by zollo.j...@gmail.com on 20 Jan 2010 at 10:01

[GoogleCodeExporter]

If GnuChess doesn't send analysis in forced situations, we can just generate 
the 
hints ourselves. Actually we already do that for the inverse analyzer, when it 
can 
capture the enemy king. Most cecp engines don't like that :P

The last situation you found does indeed look like a bug. Do you be any chance 
have a 
pgn or fen of the board, so we can try and figure out why it isn't accepted?
Otherwise we might be able to recreate it from the log.

Thanks,
Thomas

Original comment by lobais on 21 Jan 2010 at 8:23

• Changed state: Accepted

[GoogleCodeExporter]

Yeah, I can make a pgn I think.  Gimmie a little bit.

-John

Original comment by zollo.j...@gmail.com on 21 Jan 2010 at 1:14

[GoogleCodeExporter]

I have a pgn and FEN, I tested the PGN and it reporoduces the problem.  (I 
think the
FEN does too).  

Good luck!
-John

Original comment by zollo.j...@gmail.com on 21 Jan 2010 at 1:33

Attachments:

• GNUChessBugPGN.pgn
• GNUChessBugFEN.fen

[GoogleCodeExporter]

Thanks so much for the additional info, I think I nailed it! PyChess really was 
parsing a8=Q+ incorrectly as a8=, Q+. This would only happen if there was a 
postfix to 
the Q, like + or #.
I don't know if this fixes this entire issue, but please try it out :)
I'm also converting all your testcases into unittests, so we hopefully never 
have to 
face the same problems again.

Original comment by lobais on 22 Jan 2010 at 11:56

• Changed state: Started

[GoogleCodeExporter]

Yea!

Original comment by zollo.j...@gmail.com on 22 Jan 2010 at 8:40

[GoogleCodeExporter]

r1579 seems to be very buggy!

Original comment by zollo.j...@gmail.com on 22 Jan 2010 at 8:49

[GoogleCodeExporter]

I'm getting crashes in r 1579 after playing a move or so, all like this one:

Traceback (most recent call last):
  File "/home/gatto/code/svn/pychess/lib/pychess/Players/CECPEngine.py", line 602, in parseLines
    self.__parseLine(line)
  File "/home/gatto/code/svn/pychess/lib/pychess/Players/CECPEngine.py", line 673, in __parseLine
    moves = listToMoves (self.board, mvstrs, type=None, validate=True, ignoreErrors=False)
  File "/home/gatto/code/svn/pychess/lib/pychess/Utils/Move.py", line 92, in listToMoves
    lmove.listToMoves(board.board, mstrs, type, validate, ignoreErrors)]
  File "/home/gatto/code/svn/pychess/lib/pychess/Utils/lutils/lmove.py", line 107, in listToMoves
    move = parseAny (board, mstr)
  File "/home/gatto/code/svn/pychess/lib/pychess/Utils/lutils/lmove.py", line 51, in parseAny
    return parseSAN (board, algnot)
  File "/home/gatto/code/svn/pychess/lib/pychess/Utils/lutils/lmove.py", line 296, in parseSAN
    san, "the end cord (%s) is incorrect" % notat[-2:], board.asFen())
ParsingError: ('10', 'the end cord (1O) is incorrect', 
'r2q1rk1/ppp2pp1/2npBn1p/4p3/4P3/2NPbN2/PPP2PPP/R2Q1RK1 w - - 0 10')

Original comment by mattgatto on 23 Jan 2010 at 1:49

[GoogleCodeExporter]

Here's a different one. I should add that both of these crashes were playing 5 
0 against the PyChess 
engine with crafty as an analyzer and no inverted analyzer.

Traceback (most recent call last):
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Players/CECPEngine.py", line 607, in parseLines
    self.__parseLine(line)
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Players/CECPEngine.py", line 680, in 
__parseLine
    moves = listToMoves (self.board, mvstrs, type=None, validate=True, ignoreErrors=False)
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Utils/Move.py", line 94, in listToMoves
    lmove.listToMoves(board.board, mstrs, type, validate, ignoreErrors)]
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Utils/lutils/lmove.py", line 107, in listToMoves
    BoardView._set_hover(): set self._hover = f2
move = parseAny (board, mstr)
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Utils/lutils/lmove.py", line 51, in parseAny
    return parseSAN (board, algnot)
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Utils/lutils/lmove.py", line 339, in parseSAN
    raise ParsingError, (san, errstring, board.asFen())
pychess.Utils.lutils.lmove.ParsingError: ('Nf6', u'no Knight is able to move to 
f6', 
'rnbqkb1r/pppppppp/5n2/8/8/5N2/PPPPPPPP/RNBQKB1R w KQkq - 2 2')

Original comment by mattgatto on 23 Jan 2010 at 2:06

[GoogleCodeExporter]

The problem is due to the regexp on line 85 of pgn.py:
movre = re.compile(r"([a-h0-8xOoKQRBN+#=-]{2,7})[\?!]*\s*")

In CECPEngine.py on line 677, with 
moves == "3. ... Nc6 4. e3 e5 5. exd4 exd4 6. c3 Bc5 7. Bc4 Nge7 8. cxd4 Nxd4 
9. Nbxd4 Bxd4 10. Nxd4 
Qxd4"
after this line is executed:
                mvstrs = movere.findall(moves)
mvstrs == ['Nc6', 'e3', 'e5', 'exd4', 'exd4', 'c3', 'Bc5', 'Bc4', 'Nge7', 
'cxd4', 'Nxd4', 'Nbxd4', 'Bxd4', '10', 
'Nxd4', 'Qxd4']

Original comment by mattgatto on 23 Jan 2010 at 2:53

[GoogleCodeExporter]

Here is a much more detailed regex: (not tested)
([KQRBN]?[a-h0-8]{0,2}x?[a-h][0-8]=?[KQRBN]?|[0Oo\-]{3,5})[+#][\?!]*\s*
Another solution would be to change the \s* back to \s+ and then manually add a 
space
to the end of the strings before they are 'findall'ed.

Original comment by lobais on 23 Jan 2010 at 3:03

[GoogleCodeExporter]

I like the new one better since it's more fine grained. Stupid regexps :). It 
seems like most of the recent fixes 
in the last week or two have been because of them. I will test it out.

Original comment by mattgatto on 23 Jan 2010 at 3:12

[GoogleCodeExporter]

Wow.  Thanks you two!  I need to learn Python!

Original comment by zollo.j...@gmail.com on 23 Jan 2010 at 4:19

[GoogleCodeExporter]

The "[+#]" needs an "?". So it should be:
"([KQRBN]?[a-h0-8]{0,2}x?[a-h][0-8]=?[KQRBN]?|[0Oo\-]{3,5})[+#]?[\?!]*\s*"

Original comment by mattgatto on 23 Jan 2010 at 4:25

[GoogleCodeExporter]

The crash in comment 22 is happens when crafty sends a line of analysis to 
__parseline() before it has 
received the new move. An example: In CECPEngine.__parseLine():

self.board ==
Board: Black KQkq -
r . b q k b n r 
p p . p . p p p 
. . n . . . . . 
. N . . p . . . 
. . . . . . . . 
. . N . . . . . 
P P P . P P P P 
R . B Q K B . R 

and
line = "13     44     278 4602450  5. N1c3 a6 6. Nd6+ Bxd6 7. Qxd6 Qe7 8. Qxe7+ 
Ngxe7 9. Bg5 f6 10. 
Bd2 d5 11. O-O-O Bf5 12. Be3"

Original comment by mattgatto on 23 Jan 2010 at 5:32

[GoogleCodeExporter]

Resulting in:
Traceback (most recent call last):
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Players/CECPEngine.py", line 602, in parseLines
    self.__parseLine(line)
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Players/CECPEngine.py", line 673, in 
__parseLine
    moves = listToMoves (self.board, mvstrs, type=None, validate=True, ignoreErrors=False)
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Utils/Move.py", line 94, in listToMoves
    lmove.listToMoves(board.board, mstrs, type, validate, ignoreErrors)]
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Utils/lutils/lmove.py", line 107, in listToMoves
    move = parseAny (board, mstr)
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Utils/lutils/lmove.py", line 51, in parseAny
    return parseSAN (board, algnot)
  File "/home/gatto/code/svn/pychess-bugfix/lib/pychess/Utils/lutils/lmove.py", line 339, in parseSAN
    raise ParsingError, (san, errstring, board.asFen())
pychess.Utils.lutils.lmove.ParsingError: ('N1c3', u'no Knight is able to move 
to c3', 
'r1bqkbnr/pp1p1ppp/2n5/1N2p3/8/2N5/PPP1PPPP/R1BQKB1R b KQkq - 3 5')

Original comment by mattgatto on 23 Jan 2010 at 5:33

[GoogleCodeExporter]

Matt: So the crafty engine sends a line, which is now obsolete? That is indeed 
a 
problem. Most likely it has come up, because I changed the move-parsing to be 
more 
verbose (and thus not suppress errors).
The only solution, that comes to my mind, is to put the parse-call in a 
try/except 
and send the error to log. This will make it a bit easier to find missed parses 
later.
Well, the other option is to utilize the cecp ping/pong protocol to keep sync 
between 
python and crafty, but it is hopelessly unstable across engines, and would 
require a 
large rewrite of code ;)

Zollo: Surely you should learn python :D We'd love to have you on the team. I 
can 
recommend the 'Dive Into Python' book, which is also available online: 
http://diveintopython.org/toc/index.html
Feel free to ask any questions along ;)

Original comment by lobais on 23 Jan 2010 at 10:28

[GoogleCodeExporter]

Thomas: Exactly, yes. The attached patch (although not very elegant, which is 
why I didn' t commit it) for 
example checks the ply of the incoming line of analysis (if there is move 
numbers) and discards lines that 
aren't relevant to the current board (by comparing plys).

Original comment by mattgatto on 24 Jan 2010 at 6:35

Attachments:

• pychess-discardoldcraftyanalysislines.patch

[GoogleCodeExporter]

Matt: Do you have to feed the gamemodel to the engine? Any object that receives 
a
gamemodel can f it up. Thus the engines normally only receive board objects, 
which
can't be changed. I believe the board objects have a ply attribute.
But besides that, I'm afraid we can't rely on move numbers in analysis lines. 
If you
read http://home.hccnet.nl/h.g.muller/engine-intf.html#12 it says nothing about
something like that.

Original comment by lobais on 24 Jan 2010 at 9:36

[GoogleCodeExporter]

The simplest solution would be:

try:
    moves = listToMoves (self.board, mvstrs, type=None, validate=True,
ignoreErrors=False)
except ParsingError, e:
    log.debug("Recieved ParsingError on analysis: %s"%e, repr(self))
    return

Which is very simmilar to what we had before (ignoreErrors=True)

Original comment by lobais on 24 Jan 2010 at 9:44

[GoogleCodeExporter]

Yeah, I agree that your solution is better.

Original comment by mattgatto on 24 Jan 2010 at 10:27

[GoogleCodeExporter]

I've commited the fix.

John: I've also made a change to the log, which should fix the 'unable to 
expand' 
problem.

Original comment by lobais on 24 Jan 2010 at 5:31

[GoogleCodeExporter]

Matt, Thomas,

     Thanks for all the help guys!!!  I've tested the latest revision -- the analysis
bug is fixed!!!  Thomas, the log bug also looks fixed -- I hope it's ok!!!   
Thanks
so much for all the help fixing the bug.  I know it's not the most important 
one,
but, to me, it felt important.  Thanks for everything.

Thomas, I will definitely check out the "Dive into Python" book.  Thanks!!!

Thanks for everything everyone!!!

Sincerely,
John

Original comment by zollo.j...@gmail.com on 25 Jan 2010 at 7:25

[GoogleCodeExporter]

I've been working on a workaround for crafty since it doesn't send updated 
analysis lines when playing 
through a line that it solved for mate previously.... which is hella retarded.

The patch is not perfect though (and it's impossible to get perfect, I think) 
since, if the opposite player 
makes a move that invalidates one of the "saved" moves from the previous 
analysis, there's nothing 
you can do really, short of restarting the analyzer or reloading the position 
into crafty (which I tried 
coding, unsuccessfully).

For example, load the attached PGN, and play white against PyChess in 5 0 using 
crafty as the 
analyzer. Crafty solves for mate, expecting Black to play Bb3. So when it plays 
Bc4+, the saved 
analysis move for the current ply, Rxc2, is an invalid move, and pychess simply 
won't display a hint.

Yarcanox on IRC said something about pychess not using the "new" xboard command 
when he thinks 
it should. Or maybe we should just file a bug with the crafty maintainers.

Original comment by mattgatto on 27 Jan 2010 at 8:43

• Added labels: Type-Defect

Attachments:

• [Matthew Gatto vs. PyChess 0.10beta2 - craftydoesnotsendanalysislines-5.pgn](https://storage.googleapis.com/google-code-attachments/pychess/issue-515/comment-37/Matthew Gatto vs. PyChess 0.10beta2 - craftydoesnotsendanalysislines-5.pgn)

[GoogleCodeExporter]

Original comment by mattgatto on 27 Jan 2010 at 8:44

Attachments:

• pychess-craftydoesntsendanalysisaftermate.patch

[GoogleCodeExporter]

To be more clear about what I said in the third paragraph of my last comment, 
even WITH this patch 
applied, the behavior for that case will still occur, and there's nothing you 
can do about it if crafty doesn't 
send a new hint once your opponent has made a move out of the mating analysis 
line crafty last sent 
you, when it doesn't send you a new updated analysis line to reflect the 
current board!

This is what makes me think were not initializing crafty correctly... either 
that or Dr. Hyatt was smoking 
crack when he designed crafty's mating analysis behavior.

Original comment by mattgatto on 27 Jan 2010 at 10:51

[GoogleCodeExporter]

Did this Yarcanox tell you something about another way to initialize crafty?
I like the idea of Dr. Hyatt smoking crack..

Original comment by lobais on 27 Jan 2010 at 11:00

[GoogleCodeExporter]

I saw you talking to him in uhh... Danish I guess (sorry but I'm American :) 
... on IRC a little while 
back. He won't file bugs about it because he has privacy issues with Google's 
data tracking but he's 
the one writing the chess engine. Anyhow I don't know if it's related or not, 
I'm still confused about alot 
of the aspects of the xboard protocol. Here's what he said:

<Yarcanox> mgatto: what about the "new" bug? has thomas_sch reported or fixed 
it?
<mgatto> "new"?
 you mean the one you were talking about on here with gbtami?
<Yarcanox> yea and with thomas_sch
<Yarcanox> mgatto: http://pastebin.com/d42af4270
<Yarcanox> "go" makes no sense here without using "new" first to 
initialize/start a new game
 the protocol isn't 100% clear but I'd strongly assume that you really should send "new" before 
attempting to have the engine move or make a move yourself to start a game 
properly
 and my engine relies on it
 (results in response "16:28:30 Ildtiadar Warning: Error (command not legal now): go")

Original comment by mattgatto on 27 Jan 2010 at 11:16

[GoogleCodeExporter]

Bad news Matt, I added a "new" to CECPEngine.py just after "book off" (I
double-checked it went through in the log) -- no luck.  It had no affect on the 
lack
of hints when mate is found.  You can double check it yourself.  Open 
CECPEngine.py
and after the following line:

                print >> self.engine, "book off"
add:
                print >> self.engine, "new"
It makes no difference.  I'll keep looking for a solution too.

Maybe you are right, maybe Dr. Hyatt is smoking crack!  ;-)

-John

Original comment by zollo.j...@gmail.com on 28 Jan 2010 at 12:25

[GoogleCodeExporter]

MATT!!!  GOOD NEWS!!! I FIGURED IT OUT!!!  It turns out by default Crafty hides 
some
of its output if there aren't enough nodes.  Let me explain:

I was looking through the crafty documentation at 
     http://www.cis.uab.edu/hyatt/craftydoc.html  
( I also downloaded the crafty source and looked through option.c, though that 
wasn't
necessary.)  On that documentation web page, I just pasted, is a command called
"noise".  Apparently Crafty will hide moves by default so that the screen 
doesn't
become swamped.  This may be an issue when interacting with crafty directly as a
user, but, in my opinion, wouldn't have a major impact when being processed by a
chess front-end like Xboard or more specifically, our lovely, PyChess.

If you use the command "noise 0" (that's a zero) with crafty, it will disable 
all
hiding and show all the moves.  I added this command to CECPEngine.py and voila 
-- it
worked.  Hint mode now shows the mate for crafty.  Here's how I did it:

Find the following line in CECPEngine.py:
                print >> self.engine, "book off"
add the following line BEFORE (I think this works best) the previous line:
                print >> self.engine, "noise 0"

What you will end up with is this (for the if statement):
if parts[:4] == ["0","0","0","0"]:
                # Crafty doesn't analyze until it is out of book
                print >> self.engine, "noise 0"
                print >> self.engine, "book off"
                return

(I'm sorry I had to paste this in here -- I really don't know how to make a 
proper
patch yet!  Sorry :(  

Try this out and see if it worked for you.  It worked for me!

Thanks!

-John

Original comment by zollo.j...@gmail.com on 28 Jan 2010 at 1:47

[GoogleCodeExporter]

noise 0 is completely unfiltered and creates quite a bit of output in the 
endgame (as
the documentation states).  Maybe we can tune the noise number in between where 
it
will pick up a simple mate and where the output is too much.  Maybe we could 
also
leave it totally unfiltered and deal with a large amount of output. Either way. 
Lemme know.

sincerely,
-John

Original comment by zollo.j...@gmail.com on 28 Jan 2010 at 1:58

[GoogleCodeExporter]

Actually, you probably want to put "noise 0" after "book off" -- PyChess gets
confused otherwise -- you'll see what I mean.  (just try it!)

-John

Original comment by zollo.j...@gmail.com on 29 Jan 2010 at 5:00

[GoogleCodeExporter]

Awesome! Thanks for helping with this. Your find is exactly what I was hoping 
would be possible and 
greatly simplified fixing this. I don't think the extra output is a big deal. I 
commited a fix in revision 1599.

Original comment by mattgatto on 29 Jan 2010 at 5:22

• Changed state: Fixed

[GoogleCodeExporter]

Cool, I hoped the output wouldn't be that big of a deal either.  Btw, I tried
adjusting the volue of "noise", but any number I would use wouldn't reduce the 
number
of lines outputted that much and end up hiding the simple mates.  I believe 0 
is the
best value for noise.  (A simple mate can be solved in several hundred lines -- 
most
normal positions involve tens of thousands of lines [if not more].)

Thanks for everything Matt.  I'm glad I could help out in a simple way.  I may 
not
know Python well, but i can read a manual!  ;-)

Thanks for everything!

Sincerely,
-john

Original comment by zollo.j...@gmail.com on 29 Jan 2010 at 6:54

[GoogleCodeExporter]

Great work guys!
You have earned the title of extraordinary PyChess bug squadders :D

Original comment by lobais on 29 Jan 2010 at 2:43

[GoogleCodeExporter]

Wow.  Thank you!  Do we get a badge or somethin?

Thanks!
-john

Original comment by zollo.j...@gmail.com on 30 Jan 2010 at 3:44

[GoogleCodeExporter]

When we get the logo line finished (see that bug) I can send you a tshirt ;)

Original comment by lobais on 30 Jan 2010 at 4:55