Re: [Bug-gnubg] GNUBG prev game and session list problems

[Philippe Michel]

On Fri, Apr 12, 2019 at 11:29:21AM +0200, Wolf Dieter Wall wrote:

> i am running gnubg with -t for the command line and i cannot understand how
> list session and prev game work, or how they should work.
> 
> I have two session attached but it seems that
> - list session produces no output on money sessions

list session is not implemented (see the CommandListMatch() function in 
play.c...

> - prev game 1 does not work after a game in the session ended

A workaround might be to use the "set automatic game off" at the 
beginning of your session (but see below for other shortcomings). With 
that you will stay in the just completed game until you issue a "next 
game" command.

> - list game works as long as the game is in progress. afterwards status
> changes to "game over" and nothing more happens with the list game command.

It seems many of these commands have overly strict conditions on when 
they can be issued. For "list game", for instance, it is 
CommandListGame() in play.c and starts with the following check:

    if (ms.gs != GAME_PLAYING) {
        outputl(_("No game in progress (type `new game' to start one)."));  
        return;
    }

The game state can be GAME_NONE, GAME_PLAYING, GAME_OVER, GAME_RESIGNED 
or GAME_DROP and it looks like the game could be listed from all of them, 
except possibly the first one (and even then displaying an empty moves 
list would hardly be wrong).

I don't know why it was done this way. Maybe there were crashes when 
accessing uninitialized data structures at the wrong time and the 
developers at the time went extra careful ? These are parts of the code 
that have been barely touched for 10 years or more.

I'm afraid these commands to go through the moves list from the CLI have 
never been used much. Maybe they looked like a good idea at the time but 
were somehow overriden by the GUI for the interactive side and by the 
Python interface for the advanced scripting side.

Offhand, it looks like it would still be useful and not too difficult to 
review the code for unwarranted "No game in progress, return" patterns 
and fix them. The commands to switch from one game to another might be 
trickier.