On-line engine blitz tourney February

[hgm]

A full-blown server is an extremely complex piece of software, perhaps 10 times more complex than a GUI. FICS takes not only care of mediating games, but also of a user administration, game database, inter-user messaging, broadcasting games to observers, e-mailing...

Of course for a monthly tournament we could leave out a lot of that. E.g. people can record their own games, user verification could be based on paswords e-mailed to the server operator, people could chat through an unrelated chat server...

[Joost Buijs]

Of course it's compicated, and basically a lot of work. If I remember well the first version of the Lasker server was written in just a couple of weeks, so it's certainly doable.

The current version (v2.2.3) of the Lasker/Capablanca server is very buggy, it uses dynamic memory allocation everywhere without checking whether the allocation failed or not, it uses fscanf() and sscanf() throughout without checking the size of the destination buffers, several uninitialized local variables, some memory leaks, and the serialization/marshalling code is completely broken too.

I could be that the database got corrupted somewhere, to check this I have to write a piece of software to scan the whole database for validity. I really don't know if it's worth the effort to fix all these things for just one tournament per month.

[mar]

A full-blown server is an extremely complex piece of software, perhaps 10 times more complex than a GUI. FICS takes not only care of mediating games, but also of a user administration, game database, inter-user messaging, broadcasting games to observers, e-mailing...

really though?

in terms of lines of code, comparing the capablanca server to cutechess gives 26k sloc for Lasker and 55k for cutechess,
while C is typically more verbose than C++ in this regard
also since cutechess is built on top Qt, that doesn't even include the low level GUI part

[hgm]

I can do an engine in 200 lines, and I would be disappointed if I could not do a GUI in 2000 lines.

[flok]

I can do an engine in 200 lines, and I would be disappointed if I could not do a GUI in 2000 lines.

Preferably new code is written in a style readable by others as well

[mar]

I can do an engine in 200 lines, and I would be disappointed if I could not do a GUI in 2000 lines.

why not simply admit that your guess was off, there's no shame in that and it's much less work
you don't have to prove anything to anyone, that was not my point

of course there are many ways to cheat, from grabbing existing tournament managers and board renderers and gluing something crude,
obfuscating and fitting lots of code on humongous lines to simply spawning existing GUI process or downloading source
and spawning make or even redefining what is still considered a GUI
the complexity still has to exist somewhere

[hgm]

theme=MV firstRank=1 files=8
ranks=8
Pawn::::a2-h2
Knight:N:::b1,g1
Bishop::::c1,f1
Rook::::a1,h1
Queen::::d1
King::KisO2::e1

Well, the 'Interactive Diagram' above runs from a script that in its most recent version (not the one used here) counts 4683 lines. And that includes code for a GUI as well as an engine. (And I can add that it does not only support orthodox Chess, but can just as easily be configured fr thousands of other variants, sometimes with very strange rules.) I don't know if using the browser infrastructure for graphical display counts as cheating, but GUIs are typically using similar support in the form of libraries of some widget set and drawing routines. Of course in a discussion about rewriting something the size of the needed libraries (and anything else you don't actually have to code) is not really relevant.

And I am not talking about unnaturally long lines; not even micro-Max (~150 lines) has that; it in fact hardly has more than a single expression statement on each line. This to make commenting easy. There is no need to cheat in any way.

Number of lines probably says more about coding style than about program complexity. I have worked both on WinBoard and on Lasker extensively, and the latter struck me as way more complex.

[hgm]

I can do an engine in 200 lines, and I would be disappointed if I could not do a GUI in 2000 lines.

Preferably new code is written in a style readable by others as well

I am not sure the Lasker code satisfies that requirement...

[Joost Buijs]

There are several problems in mamer too, in some locations it uses pointers that might be zero.

For instance when trying to remove a player that is not in the tourney:

Code: Select all

int Tourney::RemovePlayer(char *name) {
  TourneyPlayers *tp = NULL, *p=NULL;
  Player *opp=NULL;
  int roundsRemaining=0;

  tp = GetPlayer(name);
  printf("forfeiting %s\n", tp->name);
  if(tp == NULL) return -1; // Player not in THIS tourney

It tries to dereference 'p->name' even when (p == NULL), and there are several other locations with this type of nonsense. I will try to fix the most obvious things, but I'm afraid that it is not possible to fix all of these.

mamer is C++, but it is more like a 30 year old C program converted to C++ without using the possibilities C++ offers. Maybe we will try another tourney over 2 or 3 weeks, if the server still keeps crashing we will call it quits.

Another problem is that 'chessd' and 'mamer' both use sprintf() with the input string being the same as the output string in several places.

Code: Select all

		if (c->IsCommand(comm))
		{
			commandsFound++;
			if ((int)(strlen(output) + strlen(c->GetCommandName())) < (MAX_LINE_SIZE - 1))
				sprintf(output, "%s %s", output, c->GetCommandName());
		}

This might work, but it also could fail, at least this is not common practice.