Re: [Gnushogi-devel] gnushogi xboard support

[Yann Dirson]

On Wed, Oct 23, 2013 at 10:45:11AM +0200, address@hidden wrote:
> Op Di, 22 oktober, 2013 11:27 pm schreef Yann Dirson:
> >
> > A couple of .xbo files / profiles / whatever as we previously
> > discussed, to avoid usage of a shogi theme to "bleed" onto subsequent
> > non-shogi games, could be a good addition to the list.
> >
> Perhaps I should port the WinBoard View->Themes dialog to XBoard after
> all. This should be very little work, as all the back-end support is
> already in place, and the front-end is basically a cloned version of the
> Load Engine dialog, using the -themeNames list in stead of the
> -firstChessProgramNames list. This could go into 4.8 as well, then.
> 
> But I am not sure how to best do the configuration. For WinBoard the
> installer creates menu items in a new menu group for starting WinBoard in
> various modes, and a lot of .xop (which stands for 'XBoard options', btw,
> a mime type that did not seem to be in use yet) files in the folder of the
> winboard.exe.

Damned, I spelled it XBoardOptions, instead of XboardOPtions :)

> Windows people either use the system Start menu, or go to
> the install folder to click the .xop files there. Unfortunately neither of
> these methods seems very suitable for XBoard. I understand some Linux
> distros have deprecated the system menu, meaning that they will ignore the
> .desktop files we supply when installing XBoard.

Oh ?  Did not hear about that.  Not every desktop environment is
configured to use them, but AFAIK all major ones do (don't know much
about Unity, though, but is that a major one yet :)

But .desktop files are just useful for the desktop anyway, and as you say...

> And you cannot expect
> people to first go to /usr/share/games/xboard to click installed .xop
> files there. As for command-line argument shortcuts, like "xboard
> @minishogi", XBoard would look in the current directory for the
> minishogi.ini file with options. If people would have to type "xboard
> @/usr/share/games/xboard/minishogi" it would sort of lose its convenience.
> I use the convention now that settings files that do not have an extension
> specified will get .ini appended (a very Windows-like thing)

Small shell scripts, eg. xboard-chess, xboard-shogi etc could cover
the commandline needs, and be made available through .desktop files as
well.

> Perhaps I should change that for XBoard, into that they get
> "/usr/share/games/xboard/configs/" prefixed as well. Or force people to
> type "./foo" if they mean foo.ini in the current directory, and otherwise
> look for foo.ini in $(datadir)/configs/.

I'd say using a default search path, which may include several dirs
including ".", when there is no "/" in the name, and if there is one
just look for a relative path, would be OK.

> Then we could install settings
> files shogi.ini etc. there, and people could invoke them by simply typing
> "xboard @shogi". (The shogi.ini file there would contain a line "-variant
> shogi", as well as "-fcp gnushogi" and "-scp gnushogi", to change the
> default engine, which they can always be overruled by typing "xboard
> @shogi -fcp bonanza", provided they take care to specify the engine after
> the settings file. The supplied shogi.ini would also redirect the file for
> saving and loading settings, so that shogi settings would not leak to
> other games.

Could be good as well - even better would be providing bash/zsh
completion scripts to propose those settings.

> That doesn't sound so bad. We could supply settings files shogi, xiangqi,
> and chu, which each would specify their own save file (~/.xboard_chu_rc
> etc.) to prevent leakage between them. Simpler settings files (just
> containing the minor, volatile tweeks needed to play. e.g. mini-Shogi)
> could be included for inclusion with installed engines, or on the command
> line ("xboard @shogi @mini -fcp shokidoki" or "xboard @chu @sho -fcp
> hachu", where @chu and @shogi would take care of display theme and specify
> which settings file to save on, while @mini and @sho would take care of
> volatile board-size overrides, .fen file with initial setup etc.)

Hm, while "@shogi @mini" is shomething that some people could get used
to, you'd have to expect the "@mini @shogi" mistake to be a common
one, and "@chu @sho" is not very intuitive either.  What about causing
minishogi.ini to start with @shogi, and similar for sho ?  Btw, I'm
not sure using just "sho" and "chu" for names is a good idea, few
people will understand before looking, that they are shogi variants.

> > OYAOH, the minishogi patches can probably be merged anyway, since they
> > don't have any impact on the code outside of ifdefs.  We could include them
> > for convenience, that would just make packaging easier, while giving a
> > "heads up" to other people and pushing out the fixes ; 1.5
> > could then include both xboard protocol and a properly integrated minishogi
> > using the "variant" command.
> 
> Well, it would be indeed great if GNU Shogi could be switched between
> Shogi and mini-Shogi at run time. I don't know if this would be feasible,
> though.

Nothing's impossible, and I guess that one is not so hard.  Basically
lots of global constants to move under the umbrella of a single
struct, to be exchanged at will to change the variant.

* availability of lance and knight are easy to turn dynamic, kinda
  replace some ifndefs with if (game->has_knight); those [NO_PIECES]
  arrays will need some thought, but once for all; once for loops on
  piecetype index too; a number of #ifdef that are just here because
  those pieces were suppressed for simplicity, will just vanish

* board-size changes are easy too, some hardcoded strings could even
  be generated, some silly ones like direc and max_steps *should have*
  been generated in the beginning; many static arrays to calloc
  instead

things that may be tricky depending on how they are used:

* ispvalue

* hm, why did I remove the FIXME comment in LinkPreventCheckDrops ? ...


> Did you know there also is a 6x6 mini version compatible with
> regular Shogi (Judkins Shogi)?

I have read about Judkins Shogi on wikipedia, but forgot since then.
Yes, looks pretty straightforward to add now, but I'd prefer to wait
until runtime selection is there :)

> > Note I just pushed a new patch, about this ElapsedTime/polling issues,
> > for comment.  To win32 branch just because it does not commute to master
> > without conflict, and will be rewritten anyway.
> >
> This does seem closer to the original FIONREAD stuff. I guess I should
> have put the WIN32 polling there in the first place, except that I
> originally had no idea that Elapsed time would already do the polling I
> needed to get out of ponder. I am kind of used to engines not immediately
> responding to 'quit', when they are thinking. XBoard sends a SIGKILL a
> configurable delay after 'quit', which handsomely takes care of that
> problem. :-) It seems that GNU Shogi mainly has this because it has a
> 'both' mode where it plays itself, and would thus always be thinking.

In fact, before 4a9acd2e the FIONREAD version was also used for
xshogi, despite the hidden curses dependency there.  This probably
explains why I could not reproduce any tight loop when checking after
74ba6a1c6, and still I got hit yesterday by this issue.  Will push a
real fix ASAP.

> In XBoard protocol interrupting thinking (as opposed to pondering or
> analysis) could be useful for receiving "force" and "?" (move now)
> commands. GNU Shogi does not have a "move now", I think, but in the future
> we might want to make one.

"quit" is important too.  With well-behaved engines should there
should never be a need for kill() :)