Crafty For iPod

[Sean Evans]

Would anyone be interested in Crafty on the Apple iPod Touch 2?

Seems like an easy Port for Dr. Hyatt

Cordially,

Sean

[bob]

Would anyone be interested in Crafty on the Apple iPod Touch 2?

Seems like an easy Port for Dr. Hyatt

Cordially,

Sean

The engine part is easy enough, I think I have the old DS version around somewhere and could update the eval and search to current code. But the GUI is an issue...

[sje]

Tord's Glaurung for the iPod Touch (both models) has a fine GUI written in Objective C/C++ and provides a UCI for the underlying engine. Or so I believe from a limited examination of the source.

But Crafty uses Xboard, not UCI. Maybe it's time for a UCI Crafty.

[Tord Romstad]

Tord's Glaurung for the iPod Touch (both models) has a fine GUI written in Objective C/C++ and provides a UCI for the underlying engine. Or so I believe from a limited examination of the source.

Yes, it uses something very similar to UCI, except that the engine and the GUI are contained in a single executable file, and don't use pipes for communication. The GUI writes UCI-like commands to a queue data structure, and the engine reads commands from this queue rather than from the standard input.

It is easy to port other UCI engines to the GUI, but an Xboard engine would take a lot of work.

Tord

[glorfindel]

But Crafty uses Xboard, not UCI. Maybe it's time for a UCI Crafty.

There will probably never be such a time.

[sje]

But Crafty uses Xboard, not UCI. Maybe it's time for a UCI Crafty.

There will probably never be such a time.

Why not? Although UCI has some problems, it's cleaner and less demanding overall than the xboard protocol.

Symbolic has different command processors for UCI, xboard, and console (interactive). The default is "console", but this can be overridden by a command line option. The three command namespaces are entirely separate.

Each command processor is implemented as a class, and the three command processor classes share the same base classes so there's a minimum of duplicated code. Each is also implemented as a thread that's driven by an event munching run loop. A separate thread object of the WatchTask class handles input polling, input text processing, and signals by sending the appropriate events to the command processor thread. (The WatchTask thread also handles nested command file input and all text output.)

At start-up time, the selected command processor instantiates an object of the MetaSearch class. This object is the interface to the search and takes care of all move selection work thus keeping a lot of code out of the command processors.

It would be relatively easy to add a new command processor class should a new protocol be developed and deployed.

[bob]

But Crafty uses Xboard, not UCI. Maybe it's time for a UCI Crafty.

There will probably never be such a time.

Why not? Although UCI has some problems, it's cleaner and less demanding overall than the xboard protocol.

It usurps a lot of the decision-making that should reside in the engine. How to allocate time. What to ponder. how to ponder. When to ponder. What to do if the root position is a book position or a egtb position. Etc... Yes, it has some nice features such as the ability to couple engine controls to the GUI so that options are point-and-click settable. That could be added to xboard, leaving a better chess-playing protocol with the advantage of easy option setting added in...

Symbolic has different command processors for UCI, xboard, and console (interactive). The default is "console", but this can be overridden by a command line option. The three command namespaces are entirely separate.

Each command processor is implemented as a class, and the three command processor classes share the same base classes so there's a minimum of duplicated code. Each is also implemented as a thread that's driven by an event munching run loop. A separate thread object of the WatchTask class handles input polling, input text processing, and signals by sending the appropriate events to the command processor thread. (The WatchTask thread also handles nested command file input and all text output.)

At start-up time, the selected command processor instantiates an object of the MetaSearch class. This object is the interface to the search and takes care of all move selection work thus keeping a lot of code out of the command processors.

It would be relatively easy to add a new command processor class should a new protocol be developed and deployed.

[sje]

It usurps a lot of the decision-making that should reside in the engine. How to allocate time. What to ponder. how to ponder. When to ponder. What to do if the root position is a book position or a egtb position. Etc... Yes, it has some nice features such as the ability to couple engine controls to the GUI so that options are point-and-click settable. That could be added to xboard, leaving a better chess-playing protocol with the advantage of easy option setting added in...

Although UCI operation can be abused, the engine does not have to follow all of the directives coming out of the GUI, and this includes the plethora of options on the UCI "go" command. The engine can pretty much do as it pleases and can tell the GUI to stuff it.

I would not advocate adding anything to the Xboard protocol without first removing a lot of the old GnuChess kruft accumulation.

[bob]

It usurps a lot of the decision-making that should reside in the engine. How to allocate time. What to ponder. how to ponder. When to ponder. What to do if the root position is a book position or a egtb position. Etc... Yes, it has some nice features such as the ability to couple engine controls to the GUI so that options are point-and-click settable. That could be added to xboard, leaving a better chess-playing protocol with the advantage of easy option setting added in...

Although UCI operation can be abused, the engine does not have to follow all of the directives coming out of the GUI, and this includes the plethora of options on the UCI "go" command. The engine can pretty much do as it pleases and can tell the GUI to stuff it.

I would not advocate adding anything to the Xboard protocol without first removing a lot of the old GnuChess kruft accumulation.

Simple question:

What kind of a protocol is a protocol one does not have to follow?

Answer: A CRAPPY protocol. I think I'll leave out the port number in the next UDP frame I transmit. What will happen?

[Steve Maughan]

Bob,

With respect, I think Steven is pointing out that most of your objections are not real objections and can be overcome if you had the inclination. Come on - let's face it UCI is *THE* chess computer protocol - Winboard is dead. *ALL* of the top engines support UCI. I don't think anyone accepts the claim that UCI reduces Crafty's playing strength as a reason not to implement it.

Anyway I really hope you implement UCI for Crafty - if only for the users .

Best regards,

Steve