ScidVsPC/Mac

[JuLieN]

Also - the "engine timeout" feature is quite handy for making sure the thing always finishes.

Yes but it won't really solve the problem, because some games just freeze in the middle of the action, for no reason. It seems to happen randomly and with different engines. I first thought that some engines were unstable, but they can't all be... Especially engines like Amundsen or Arasan (and Arasan is not one of my builds).

Another precision: I checked the "show clocks" option, and when those "freezes" happen, the clocks are frozen too. And ScidVsMac's CPU load goes back to <1% (and I could witness that Amundsen, for instance was still pondering during that time, as its CPU load was at 100%... so the engine wasn't crashed while waiting for its opponent's move).

[stevenaaus]

Anyway, thanks for the feedback. I guess this program isn't suited for huge tournaments.

Yes but it won't really solve the problem, because some games just freeze in the middle of the action, for no reason. It seems to happen randomly and with different engines. I first thought that some engines were unstable, but they can't all be... Especially engines like Amundsen or Arasan (and Arasan is not one of my builds).

3- When a game has ended it takes often a lot of time (sometimes more than 30s) to start the next game...

Scid vs PC constantly kills and recreates processes playing tournaments. This is not ideal, and perhaps a serious limitation that would take considerable effort to change.
This will definitely stress your operating system and it's implementation of tcl/tk. Sadly i have to say OSX is not as technically solid (regards process handling) as Windows and Linux, and it's Tcl/Tk is definitely weaker.

Another precision: I checked the "show clocks" option, and when those "freezes" happen, the clocks are frozen too. And ScidVsMac's CPU load goes back to <1% (and I could witness that Amundsen, for instance was still pondering during that time, as its CPU load was at 100%... so the engine wasn't crashed while waiting for its opponent's move)

.

Hmmm - Scid vs. PC already comes with it's own version of Tcl/Tk because of tcl issues. Perhaps there are still issues remaining ?
It is important that *if* you compile your own tkscid, that it is linked to the embedded Tcl/Tk libraries using "make mac_rename"

If you havent compiled your own tkscid (which is probably the case) , then possibly this is a process scheduling or I/O issue of some sort.
There is some serious stuff going on
(For copmarison, on my Linux/C2Q 9400/2 meg ram, I just ran 100 games in an incomplete 20 engine 2 round 6 second per game tournament, while browsing the web with 10 pages open in firefox. The thing seemed to run ok, though most games were decided by time loses.)

Oh, a few other requests, that I don't think are implemented yet:
1- tournament files, so one could stop a tournament and continue it again later by loading it
2- the ability to add/remove some engines during a tournament (that one will be tricky!)
3- later, when you have time, why not add a broadcasting service compatible with TSCV? (complex too...)

Haha - this program is already a very solid database app, damn handy fics client and other things too..... But I don't think Scid vs. PC's tournament will ever get these features.

[hgm]

Thanks H.G., I'll take a look at that. But ScidVsMac has no swiss system, sadly. Maybe Xboard has?

How did you guess?

But actually, there could be a problem there, which I have to check. WinBoard, and thus XBoard, implement Swiss through an external pairing engine: it sends a string of game results to that engine, and a game number of the next round, and the pairing engine then replies with who has to play who in that game (as player numbers).

I wrote a simple version of such an engine, (like most GUIs, it provides only an approximation to the very complex official FIDE rules for Swiss) and distribute it with WinBoard, but I am not sure if I posted the sources anywhere, and whether they were ever compiled for Linux or Mac. So it could be that the current Mac distribution for XBoard doesn't contain it, meaning that Swiss is disabled. I will check it out.

For a heavy-duty tournament manager, being able to start and stop tournaments is a must. The odds for a 96-day uninterrupted run are not very good... In XBoard I used the tournament file as the as the central concept, around which everything revolves. (With a very nice and straightforward scheme for concurrency as a consequence.)

But I agree that it makes no sense to try to turn SCID into a heavy-duty tournament manager, just as it would make no sense to turn XBoard in a heavy-duty database manager. (I want it to support the most basic database functionality, however, because for most of the variants SCID is no alternative, and in fact there isn't any alternative at all.)

[JuLieN]

But I agree that it makes no sense to try to turn SCID into a heavy-duty tournament manager, just as it would make no sense to turn XBoard in a heavy-duty database manager. (I want it to support the most basic database functionality, however, because for most of the variants SCID is no alternative, and in fact there isn't any alternative at all.)

Indeed. Although why wouldn't you guys join forces and make a SCIDBoard? I have the feeling that both programs have quite some overlap and that you duplicate each others' efforts...

[hgm]

Well, there sure is a lot of overlap in the things SCID and XBoard do. Like displaying the Chess board, parsing PGN files, etc. But all that stuff already exists for both.

The internal workings of SCID and XBoard are completely different, and not easily combined. The front-end is based on a completely different widget set, (Tcl/Tk for SCID, Xaw/X11 for XBoard), so we could not use each other's front-end code even if we wanted to do exactly the same thing.

For the back-end I could not use SCID's database code, because that is all written to use SCID's native database format, which is limited to Chess. So it could not handle Gothic Chess or Xiangqi, making it unacceptable for XBoard, while extending it so that it could handle these, would decrease the efficiency for Chess (e.g. by doubling all file sizes) in a way that is unacceptable to SCID.

So I think that at the stage of development both programs are now, it would be very difficult to combine them or share code, and even more diffiicukt to benefit from that in any way. But the original reason for putting the Swiss pairing functionality in a separate, independent program was an attempt to make it better sharable by different GUIs. E.g. if SCID wanted to implement Swiss, it could use the pairing engine, and wouldn't have to bother about making the pairing itself. And that improving the pairing engine, would improve the quality of Swiss on all GUIs using it. But I think the idea is still-born: GUI programmers would rather die than use an existing external component.

[IGarcia]

Haha - this program is already a very solid database app, damn handy fics client and other things too..... But I don't think Scid vs. PC's tournament will ever get these features.

You bet.. is the best. And agree that some things maybe has to be left to other progrmas/aplications. Since a wish list tread was opened by Julien, I will dump here some annotations I was making from the 4.7 release. There are so many features in Scid. Never stop impressing, and of course, more I use, more comments

Here they are:

UCI: Some engines do not send pv token last. Because this is not possible to see the information sent by engine after pv. (happened with Gaviota, now changed by Miguel) But is better the GUI be ready for this.

Crosstable:
- add per player result +-=
- total at bottom, indicate is B/W won count

EPD:
- Analysis: ask witch engine for analysis, Currently starts the one first listed in config.

Tournaments:
- allow save more info to pgn for on each move: eval, depth, used time, remaining clock, hash tbhits
- allow to load initial positions from pgn, epd or scid dbase. Aldo allow play each initial position twice, alternating colors, or not.
- The window becomes too tall when you add engines, to the point the clocks will not be visible. Or to the point the start button is not visible. This happens in my laptop, with a 1366x768.


Table bases:
- After loading a random position, or a selected one (usually mutual zugzwang) have an option to swich side to move, this way is easy faster to play the position with other side to move. Now its possible by edit-> setup board->selecting white/black move

Thats all, and of course you do whatever you like possible. Always appreciating the efforts done by free software programmers!

Ignacio.

[stevenaaus]

Well - that's unusual. Process crafty-234 never got killed
I had 23 of the things running at 20% cpu each this morning !

I'll definitely have to look at that

[stevenaaus]

I've implemented a hard kill on every engine (Unix only, after all other things are closed) because they occasionally (and in crafty-234's case - always) seem to fail to exit.

For the moment, i've enforced ponder off too - though i'll shortly add a pondering option. Xboard ponder was on. UCI was unspecified.

Another thing i've seen. The stress of the cpu can play havoc with the gameinfo autoscroll frame... so best practice is probably to hide this widget for tournaments.

[hgm]

Non-exiting engines is a grave problem, even more so on Windows than on Linux. I haven't found a satisfactory solution on Windows yet, where Unix-type signals don't exist, and TerminateProcess sometimes doesn't seem to work for unknown reasons.

[stevenaaus]

Indeed. Although why wouldn't you guys join forces and make a SCIDBoard? I have the feeling that both programs have quite some overlap and that you duplicate each others' efforts...

Now that is crazy talk

The tourney widget will now pack smaller. If > 10 engines selected, only the first 10 are changeable.

Code: Select all

# Only pack so many
if {$i < 10} { 

Pondering shouldn't be too hard. ....... Except i can't figure out the UCI protocol properly.

Code: Select all

Engine 1 says "bestmove MOVEA ponder MOVEB"
send MOVEA to Engine 2
Engine 2 plays MOVEB
send "ponderhit" to Engine 1

But then it grinds to a halt
I can't figure out how to continue there-after or when to issue "go ponder". Does this replace the "go" command, or do i have to issue a whole set of "go" AND "go ponder" for one move ? Ponderhit *is* used in the serious game feature , and i'll have to examine it closer i guess though it is implement with "position fen" here instead of "position startboard moves".
EDIT - found something helpful here