OpenChess

I am working to create a simple program that interfaces to UCI engines. Currently I am doing this in Python but it seems that it isn't working with all UCI engines. That has me wondering if I would be better off doing this in C or some other language.

Does anyone have experience using python to control UCI engines and if so, are you using the subprocess commands to do so? I just want to make sure I am on the right path or if I am beating my head against the wall.

Thanks in advance for any comments.

You may be reinventing the wheel: check out PyChess (http://pychess.org) which is a fairly polished Gnome + Python Chess GUI. As for other languages, I've been able to get .NET (C#) to play nicely with native code UCI and WinBoard engines on both 32 and 64-bit flavors of Windows (WinXP & Win7). Although there is some fiddling required to switch back and forth between managed and unmanaged code, the overhead appears to be minimal, and .NET makes Windows GUI-building significantly faster than with MFC or WTL. The parallel processing libraries for .NET 4.5 have some real promise, but I haven't explored them too deeply.

Cheers!
Humble Programmer
,,,^..^,,,

From the PyChess page:

OSX & Windows

While there has been progress on porting PyChess to Windows, there are not currently any stable releases.

The main issue is the way PyChess communicates with engines, which is built tightly around the unix process model. If feel like helping out, you are heartly welcommed to check You & PyChess, and specifically contact Leonardo Gregianin.

Thanks for the suggestions guys. I also found another program that seems to be using python here: http://lucaschess.host22.com/index.htm

I will check it and PyChess for ideas on how to interface with the engine using python.

lrmall01 wrote:Thanks for the suggestions guys. I also found another program that seems to be using python here: http://lucaschess.host22.com/index.htm

I will check it and PyChess for ideas on how to interface with the engine using python.

My primary issue with these high level language GUI's is that they tend to be slow. Even a fraction of a second delay degrades the user interface experience. I started to write a GUI in a high level language and found that converting the output of the engine to SAN notation to get attractive PV reporting had delays that were easily noticeable by users. It seems like all the user interfaces have this issue, such as Arena which I like very much. Maybe the language is not always to blame but something in the design. Some modern software is based on layers and layers of protocol which could be part of the problem too. it could be images that loaded from disk instead of being built in to the program as a data structure, I don't really know.

I'm not crazy about xboard, but it is snappy - it has the feel I like and that is probably because it is coded in C.

Allow me to advance a rather heretical theory: the speed of the GUI doesn't matter. Like you, I wrestled with performance issues in a high-level GUI, and after rewriting a PGN parser for about the umpteenth time, I realized that I was investing a lot of effort for very little output. The user wants a snappy, responsive GUI: multi-threading, lazy evaluation, caching, whatever it takes: keeping that GUI thread processing messages so that it feels zippy. Very high on my priority list. However, this does not mean I have to publish every little tidbit of data from the engine! By their very nature, engines spew thousands of data points--often at sub-millisecond intervals--much of which can be ignored. Updating the PV 14 times in 2 seconds does the user absolutely no good whatsoever, because unless Mr. Spock is sitting in front of your GUI, who can read that fast? Is anyone going to have hysterics if your GUI summarizes what is happening, rather than blindly blasting data everywhere? I have found that pondering "How can I present this to the user in a concise and meaningful fashion?" is much more effective than "How fast can I shovel this information at the user?".

As a programmer, I tend to think in "diagnostic mode" where every message back and forth between the GUI and the Engine is significant, and I want every detail. Terrific: use a log file. When building the GUI, I have to discipline myself to think in "analysis mode" which deals with more discrete things like "change" and "trends". If the PV has changed 14 times in 2 seconds, I may not care what the different PVs were, but the fact that they changed that quickly is interesting. Instead of trying to display them all, how about displaying the most recent one, along with a linear graph akin to a seismic recorder that shows the variance; this can be easily generated by the GUI, and easily ingested by the user. If the line if flat, the engine considers the position stable and predictable, if the line is all over the place, the engine is encountering "horizon events" that mean the position is going to get tactically complex soon.

Just a thought.

HumbleProgrammer wrote:Allow me to advance a rather heretical theory: the speed of the GUI doesn't matter. Like you, I wrestled with performance issues in a high-level GUI, and after rewriting a PGN parser for about the umpteenth time, I realized that I was investing a lot of effort for very little output. The user wants a snappy, responsive GUI: multi-threading, lazy evaluation, caching, whatever it takes: keeping that GUI thread processing messages so that it feels zippy. Very high on my priority list. However, this does not mean I have to publish every little tidbit of data from the engine! By their very nature, engines spew thousands of data points--often at sub-millisecond intervals--much of which can be ignored. Updating the PV 14 times in 2 seconds does the user absolutely no good whatsoever, because unless Mr. Spock is sitting in front of your GUI, who can read that fast? Is anyone going to have hysterics if your GUI summarizes what is happening, rather than blindly blasting data everywhere? I have found that pondering "How can I present this to the user in a concise and meaningful fashion?" is much more effective than "How fast can I shovel this information at the user?".

As a programmer, I tend to think in "diagnostic mode" where every message back and forth between the GUI and the Engine is significant, and I want every detail. Terrific: use a log file. When building the GUI, I have to discipline myself to think in "analysis mode" which deals with more discrete things like "change" and "trends". If the PV has changed 14 times in 2 seconds, I may not care what the different PVs were, but the fact that they changed that quickly is interesting. Instead of trying to display them all, how about displaying the most recent one, along with a linear graph akin to a seismic recorder that shows the variance; this can be easily generated by the GUI, and easily ingested by the user. If the line if flat, the engine considers the position stable and predictable, if the line is all over the place, the engine is encountering "horizon events" that mean the position is going to get tactically complex soon.

Just a thought.

The performance of the GUI in principle shouldn't matter if it's beyond the threshold of human perception. I think traditional hollywood moves have used a frame rate of 24 FPS and the upper limit of human perception seems to be around 60 FPS.

That is for the eye. But what about response time? If I push a button how much of a delay is too much? I believe it becomes at least slightly annoying if there is any perceptable delay. Try typing on a keyboard that has a delay and you will learn the meaning of annoying and distracting.

Probably most high level languages and GUI toolkits are perfectly adequate and do not cause undue delay. But if there is any at all and it's perceptable it does indeed change the user experience. To be the very best experience you want crisp and responsive and we can tell the difference. Do the slower high level languages provide this? I am not sure but my guess is that do fine as long as there is no load.

It's an altogether difference thing if substantial processing needs to be included. With a chess GUI, there is actually a significant amount of processing going on when an engine sends a long PV and a GUI converts it to SAN notation to make it look super nice on the display which is what you expect from a high quality GUI. If you have to solve this by throwing out some of the data coming in, it is already sounding like a burden that has to be worked around and probably a limiting factor.

Probably you don't want to hear this is you are a python, ruby or tcl lover (and I am for all these languages.) Who wants to have to build a GUI in C++ if they don't have to? But I am pretty sure it really does make a difference. It will not prevent the creation of a high quality GUI but there is a perceptual difference. There is a chess database GUI written in TCL that is very professionally done so perhaps you could check it out to see what I mean. Set it up to play a game with some engine and see if there is a difference there that you can notice and if so if the difference is likely to be something that would bother anyone. If not, they you are probably fine.