Re: [Bug-gnubg] Anomolous looking code in eval.c

[Jim Segrave]

On Tue 16 Jul 2002 (12:02 -0400), Gary Wong wrote:
> On Tue, Jul 16, 2002 at 05:19:11PM +0200, Jim Segrave wrote:
> > On Mon 15 Jul 2002 (18:37 +0000), Joern Thyssen wrote:
> > > I've tried to implement something similar to a tutor-mode, but had some
> > > trouble with the GTK interface. While the program is analysing the human
> > > player's moves, GTK is "frozen", but remembers your mouse clicks, and goes
> > > totally bananas after finishing the analysis if you've clicked around
> > > while waiting for the analysis to finish.
> > 
> > Thanks - that should be helpful. The remembered mouse-click issue is
> > just the sort of thing I needed to hear about. I guess I'd better read
> > up on the gtk documentation to see if there's some way to tell it to
> > drop unprocessed events or something.
> 
> Unfortunately this area is full of subtleties.  The best place to see
> the deep magic is in the function HandleXAction() in gtkgame.c, but
> there are some unavoidable repercussions in many other parts of the
> program.  The essential idea is that when gnubg is idle, it is
> responsive to both TTY and GUI activity.  When it is busy, it
> generally ignores TTY activity (which will be buffered), and handles
> some GUI activity (e.g. it handles display updates, but ignores most
> user input).  Keyboard interrupts and the GUI "stop" button are always
> active: keyboard interrupts are dealt with by installing a signal
> handler for SIGINT, and the "stop" button is designated as the GTK
> grab widget.  The interrupt/stop handlers are very simple, because
> they can be executed more-or-less asynchronously, so we have to
> guarantee that they are safe.
> 
> If all goes well, this design should ensure that we avoid any unwanted
> reentrancy caused by user input while other processing is in progress.
> The assertion on fComputing in NextTurn() in play.c should catch the
> worst case reentrancies if there is a mistake somewhere.
> 
> It is possible that the auto-analysis problems could be fixed with
> something as simple as ensuring that the "stop" button has the grab in
> autoAnalyseMove(), but as always, the devil is in the details.  I'll
> look into the problem this week.

Hmm - I've been browsing through the gtk/gdk documentation and I've
had a look at HandleXAction and the signal handlers, but I'm not sure
I'm all that much wiser.

In particular, I haven't really found any documentation for ftk on
what gtk_grab_add() and gtk_grab_remove() actually do in terms of gtk
event processing of mouse and keyboard inputs.

I have noticed that when some windows are up - Eval, Hint, Statistics,
then evrything is pretty much OK - mouse clicks anywhere outside the
window are ignored, not saved, readline input is buffered and acts
only after the window closes. 

So one horrible hack would be to create an invisible (either very
small or unboardered and transparent) window which has no close button,
as a way of locking things. (I did say horrible hack, didn't I?).

I'm also curious why the realind callback handler is sometimes
removed, instead of setting it to a handler which simply discards
input lines. If you start an anlaysis in a gtk game and type Enter in
the text window, you get a core dump with a
readline_callback_read_char() called with no handler! followed by a
core dump. It strikes me that in the places where the
rl_callback_handler_remove () is called, it should be followed by
installing a handler that will silently consume input or otherwise
survive.

The following patch seems to fix that problem:

--- gnubg.c.orig        Sun Jun 30 17:15:50 2002
+++ gnubg.c     Thu Jul 18 18:41:24 2002
@@ -127,6 +127,7 @@
 
 #if HAVE_LIBREADLINE
 int fReadline = TRUE;
+void HandleInputIgnore( char *sz );
 #endif
 
 #if !defined(SIGIO) && defined(SIGPOLL)
@@ -4196,6 +4197,7 @@
 static void ProcessInput( char *sz, int fFree ) {
     
     rl_callback_handler_remove();
+       rl_callback_handler_install (FormatPrompt(), HandleInputIgnore);
     fReadingCommand = FALSE;
     
     if( !sz ) {
@@ -4239,6 +4241,12 @@
     ProcessInput( sz, TRUE );
 }
 
+extern void HandleInputIgnore( char *sz ) {
+
+  printf ("%s\n", _("Busy - command ignored"));
+}
+
+
 static char *szInput;
 static int fInputAgain;
 
@@ -4255,6 +4263,7 @@
     szInput = sz;
 
     rl_callback_handler_remove();
+       rl_callback_handler_install( FormatPrompt(), HandleInputIgnore);
 }
 #endif
 
@@ -4442,9 +4451,10 @@
                rl_point = nOldPoint;
                rl_redisplay();
                fReadingCommand = TRUE;
-           } else
+           } else {
                rl_callback_handler_remove();   
-           
+           rl_callback_handler_install( FormatPrompt(), HandleInputIgnore);
+               }
            fReadingOther = FALSE;
            
            return szInput;




-- 
Jim Segrave           address@hidden