how to make a chess interface

[lucasart]

Thank you Ilari. I'll experiment around your code. Perhaps I should forget the GUI idea for the moment, and try to do a very primitive CLI, similar to cutechess-cli (but really dumb and simple). This should give me already plenty of difficulty, understanding how all this forking and threading works... I've never used any of that before, and when I see how complicated a GUI actually is, I feel like such a noob, it's discouraging

[tvrzsky]

Thank you Ilari. I'll experiment around your code. Perhaps I should forget the GUI idea for the moment, and try to do a very primitive CLI, similar to cutechess-cli (but really dumb and simple). This should give me already plenty of difficulty, understanding how all this forking and threading works... I've never used any of that before, and when I see how complicated a GUI actually is, I feel like such a noob, it's discouraging

Well, I did exactly that recently after having some unpleasant experiencies with cutechess-cli. For some unknown reason it crashed frequently in my test setup. Being not able to cure this I just decided to write my own tournament manager. It works now although not all is implemented yet. I am afraid the main drawback from your point of view could be that it is Windows only code. The main reason is different concept of multitasking in Windows and Unix: threads vs. forking (frankly this idea is really strange for me). So unless you use some OS independent threading library you has to handle both cases separately.
What I am doing in my program using Windows threads is:
1) I have one main thread which basically does nothing - it waits for "messages" (I don't know the right term for this) from input stream or worker threads and launches those by request
2) second thread is just listening to standard input and sending requests to main thread
3) then after creating instance of MATCH class for each used CPU core there are 3 new threads launched: one for controlling this "submatch" and two other just for listening for output from the engines.
So for example after starting match on 4 cores there are 14 running threads if I count it right. To get it work was not trivial for me because I am not programmer, only hobbyist and never have done it before, but it works now like a charm and was generally good experience and exercise for me.
Overhead is very small, mainly coming from parsing of engine output. For some well behaving engines it could be somewhere in the range of 0.1-0.2% of total CPU time used by all engines. And it includes writing all of the communication to the debugging file with timestamps of course like in cutechess-cli and creating output PGN file. It seems quite effective to me. BTW biggest pain was to find the best strategy how to parse the output of some engines with buffering issues - overhead in those cases was dramatically raised sometimes to 5-8%.
I have also one feature which could be quite usefull I think - my manager can change number of running threads (i. e. concurency number in cutechess-cli) during the match.
Filip

[tvrzsky]

I want to add that another highly useful thing, especially during the development phase, is to have a separate watchdog process (quite simple to write) which kills eventually all running engines after the crash of the parent tournament manager process. Maybe having cutechess-cli this I wouldn't mind to create my own one but killing all of those engines in Taskmanager was so annoying

[tvrzsky]

Sorry for my spamming here but another idea which I have in mind is to write some little server for remote controlling of tournaments. I am only in the phase of initial trials so far beacuse networking and using of sockets is totally new concept for me. However laziness is big driving force of progress and my dream is to by just one keyboard hit start it ALL - compiling, testing etc. and then after a few hours only have one look at some table and see - OK, this was worth of x Elo or this does not work

[tpetzke]

If you're kind of flexible in the programming language I would recommend Free Pascal (Lazarus). This is a single installation package and gives you portable code for all kinds of platforms.

http://www.lazarus.freepascal.org/

It's open source so you probably would like it.

And it is especially good for rapid prototyping. You can build your notepad sample app in less than 5 minutes. (just the time you need to drag a TMemo component onto the main window form.)

I built my own chess engine GUI with it and it wasn't that hard. When I started to use Visual Studio for coding my iCE engine I was amazed about the low level API stuff I have to deal with just to for instance create a thread. In Lazarus all you have to do is to create a TThread object

MyThread := TMyThread.Create(False);

and the compiler translates that into whatever magic is required in the platform you build the stuff for. Pretty cool.

The only downside for me is that I find it hard to switch between Pascal and C syntax rapidly.

Thomas...

[ilari]

Well, I did exactly that recently after having some unpleasant experiencies with cutechess-cli. For some unknown reason it crashed frequently in my test setup.

I'd like to hear more about those crashes and try to find a solution to them. Are we talking about the latest version of cutechess-cli (0.5.1)? Did you compile it yourself or are you using the "official" binary package for Windows? Does it crash at some random point in the match, after a certain number of games, at startup, at exit/cleanup? What settings or command line parameters are you using (time control, concurrency, number of games, etc.)? And does the choice of chess engines affect the crashing probability?

I'm aware of a couple of bugs in the latest released version. One is related to the killTimer() warning that's sometimes printed by the Windows version when a match is complete. As far as I know this bug isn't fatal. Another is a memory leak that I only found a few days ago. The memory leak would only occur if you don't save the games (ie. use the "-pgnout" option). But it could be a problem if you tried to run hundreds of thousands of games without saving them in a PGN file.

[hgm]

Sorry for my spamming here but another idea which I have in mind is to write some little server for remote controlling of tournaments.

I am not sure what you mean by 'remote controlling of tournaments', but note that running engines on remote machines can usually be done by simply using ssh as the 'engine' on the localmachine, with the proper argument to connect to the remote machine and run the engine there.

In WinBoard you have the choice to install engines on a particular remote machine, or to assign a remote host to a certain WinBoard instance, so that it runs all engines for games it plays automatically on that host. Other WinBoard instances then could play the games assigned to them on another remote machine.

BTW, note that WinBoard also allows you to change the concurrency during the match/tourney, by starting or stopping one or more instances.

[tvrzsky]

Well, I did exactly that recently after having some unpleasant experiencies with cutechess-cli. For some unknown reason it crashed frequently in my test setup.

I'd like to hear more about those crashes and try to find a solution to them. Are we talking about the latest version of cutechess-cli (0.5.1)? Did you compile it yourself or are you using the "official" binary package for Windows? Does it crash at some random point in the match, after a certain number of games, at startup, at exit/cleanup? What settings or command line parameters are you using (time control, concurrency, number of games, etc.)? And does the choice of chess engines affect the crashing probability?

I'm aware of a couple of bugs in the latest released version. One is related to the killTimer() warning that's sometimes printed by the Windows version when a match is complete. As far as I know this bug isn't fatal. Another is a memory leak that I only found a few days ago. The memory leak would only occur if you don't save the games (ie. use the "-pgnout" option). But it could be a problem if you tried to run hundreds of thousands of games without saving them in a PGN file.

Hi Ilari,
I am sorry for not reporting this in time. It is more than half year ago now when I stopped testing with cutechess but from what remains in my memory and on my harddisk I can say:
1) all cutechess-cli versions I had tried were official Windows binary packages. Problems arose last year in autumn, so I think it was version 0.4.2 and then I downloaded 0.5.1 where the problem certainly remained
2) process allways crashed at the same place in QtCore4.dll library, unfortunately I do not remember neither offset nor error number. Cutechess reports me "Using Qt version 4.7.4" now. I even downloaded another binary of QtCore4.dll to be sure that it is not corrupted but with no succes.
3) something tells me that there were some messages related to this killTimer() thing, is it possible? Anyway the crash always ocurred at the start of new match, hard to say when exactly because my setup was Perl script with infinite loop starting cutechess via pipe for batch of 6 matches, 424 games every match, opening positions from PGN file, output to PGN file always on as well as output to debugging file. Concurrency 4 running on Intel i5-2500K quadcore, OS Windows 7 64bit, time controls in range of tens milliseconds per move, always the same set and sequence of opponents of my engine for each 424 games part: Critter_1.0_64bit, t20090922_x64, toga141se-1cpu, spark-0.4-win64-mp, komodo3-64 and Strelka5. Usually the crash came at the start of Strelka part, sometimes Komodo and very rarely starting another match. Crash came after displaying "Started game 1 Started game ..... Started game 4" in whatever order and then bang. Sometimes the script was running all day without crash (i. e. playing maybe 25000 games continually) but more frequently it crashed every third, fourth (or something like that) run. So maybe every 20th start of cutechess on average, but no obvious patterns. Adding time delays between matches did not help. Similar script and setup now works well with my manager.
Can it somehow help you?
In any case I want to thank you for this awesome tool although I was kind of unlucky with it. But it gave me inspiration to write my own little one and tried to mimic it and if possible little bit improve on it somewhere.
Filip

[tvrzsky]

Sorry for my spamming here but another idea which I have in mind is to write some little server for remote controlling of tournaments.

I am not sure what you mean by 'remote controlling of tournaments', but note that running engines on remote machines can usually be done by simply using ssh as the 'engine' on the localmachine, with the proper argument to connect to the remote machine and run the engine there.

In WinBoard you have the choice to install engines on a particular remote machine, or to assign a remote host to a certain WinBoard instance, so that it runs all engines for games it plays automatically on that host. Other WinBoard instances then could play the games assigned to them on another remote machine.

BTW, note that WinBoard also allows you to change the concurrency during the match/tourney, by starting or stopping one or more instances.

Thanks for the notion, I am well aware of the fact that it is reinventing of the wheel basically . What I want is to have a client on my laptop where I am coding and compiling which would start process of testing the engine on my quadcore or whatever machine and display statistics about it using bayeselo or something and which allows for control of the testing - changing concurrency, starting and quitting matches and so. Perhaps I could be able to do all that using existing tools and bunch of scripts for controlling them. But it appeared to me more interesting and maybe even easier to create my own server for this.
BTW how copes WinBoard with very short time controls in range of tens milliseconds per move in those circumstances? Do I understand well that WinBoard is running locally and only engines run on remote host so all the communication goes through the network?

[ilari]

Hi Ilari,
I am sorry for not reporting this in time. It is more than half year ago now when I stopped testing with cutechess but from what remains in my memory and on my harddisk I can say:
1) all cutechess-cli versions I had tried were official Windows binary packages. Problems arose last year in autumn, so I think it was version 0.4.2 and then I downloaded 0.5.1 where the problem certainly remained
2) process allways crashed at the same place in QtCore4.dll library, unfortunately I do not remember neither offset nor error number. Cutechess reports me "Using Qt version 4.7.4" now. I even downloaded another binary of QtCore4.dll to be sure that it is not corrupted but with no succes.
3) something tells me that there were some messages related to this killTimer() thing, is it possible? Anyway the crash always ocurred at the start of new match, hard to say when exactly because my setup was Perl script with infinite loop starting cutechess via pipe for batch of 6 matches, 424 games every match, opening positions from PGN file, output to PGN file always on as well as output to debugging file. Concurrency 4 running on Intel i5-2500K quadcore, OS Windows 7 64bit, time controls in range of tens milliseconds per move, always the same set and sequence of opponents of my engine for each 424 games part: Critter_1.0_64bit, t20090922_x64, toga141se-1cpu, spark-0.4-win64-mp, komodo3-64 and Strelka5. Usually the crash came at the start of Strelka part, sometimes Komodo and very rarely starting another match. Crash came after displaying "Started game 1 Started game ..... Started game 4" in whatever order and then bang. Sometimes the script was running all day without crash (i. e. playing maybe 25000 games continually) but more frequently it crashed every third, fourth (or something like that) run. So maybe every 20th start of cutechess on average, but no obvious patterns. Adding time delays between matches did not help. Similar script and setup now works well with my manager.
Can it somehow help you?
In any case I want to thank you for this awesome tool although I was kind of unlucky with it. But it gave me inspiration to write my own little one and tried to mimic it and if possible little bit improve on it somewhere.
Filip

Yes, that helps. It's actually a relief that the crash always happened at the start of a match, because it means that the crash can probably be reproduced without waiting for hours. If it happens only every 20th time or so, it most likely means that there's a thread synchronization problem when the game threads are created and launched. This bug would probably be very easy to locate and fix if I could see a debugger backtrace (of a debug version of cutechess-cli) of the crash.