Re: interactive game demo for gnuplot

[sfeam (E. Merritt) <eam...@gm...>]

On Sunday, 25 August 2013, Juhász Péter wrote:
> On Sun, 2013-08-25 at 10:29 -0700, sfeam (Ethan Merritt) wrote:
> > On Sunday, 25 August 2013, Juhász Péter wrote:
> > > On Thu, 2013-08-22 at 13:39 +0200, Petr Mikulik wrote:
> > > > > Struck by sudden inspiration (and also motivated by the feel that the
> > > > > "new" control flow capabilities are not advertised enough in the
> > > > > existing demos), I wrote a small game demo, in pure gnuplot. I donate it
> > > > > for the demo suite.
> > > > 
> > > > Really cool!
> > 
> > The other excellent feature of such demos is that they exercise parts
> > of the program that don't otherwise get a lot of coverage in testing.
> > The failure of "nibbles" on qt or wxt provided a convenient diagnostic
> > tool for identifying and repairing a fundamental limitation on our
> > mousing implementation.  So this week's gnuplot is that much better
> > than last weeks, and all because of nibbles :-)    
> > (which now, by the way, works fine on both qt and wxt). 
> > 
> > 	Ethan
> > 
> 
> ... and just to underline the validity this statement, I've checked the
> second (Xixit) demo with the latest CVS version, and found that
> yesterday's change has the unwanted side effect that the shortest
> possible pause interval is now 1/20 second, which effectively breaks the
> game.

Really?   With which terminal?
The 20 per second polling only kicks in if the requested pause
is greater than 1/20 second. It should not affect shorter pauses.

~~~~~~
    if (term->waitforinput)             /* If the terminal supports it */
        while (sleep_time > 0.05) {     /* we poll 20 times a second */
            usleep(50000-1000);         /* Sleep for 49 msec */
            check_for_mouse_events();   /* This sleeps for another 1 msec */
            sleep_time -= 0.05;
        }
    usleep((useconds_t)(sleep_time * 1e6));
    check_for_mouse_events();
~~~~~~

I did put an explicit 1 msec timeout in the individual terminal routines
term->waitforintput().  I am not sure that this is a good idea, but the
only scenario that I can see it affecting is a loop that would otherwise
be limited purely  by computation speed.   This timeout can be 
removed easily enough - I will experiment.

However, running xixit here reveals a totally different problem.
I get this after a couple of minutes when I run using the x11 terminal:

  gnuplot> load '/home/merritt/cvs/contrib/xixit.plt'
  _XF86BigfontQueryFont: could not attach shm segment
  XIO:  fatal IO error 12 (Cannot allocate memory) on X server ":0.0"
      after 502085 requests (502084 known processed) with 1 events remaining.

That probably indicates either a failure to release memory somewhere
in gnuplot_x11, or an event loop that isn't keeping up with the demo.
I.e. it loops too quickly rather than too slowly.

> I don't know if pause intervals shorter than that have a real use case,
> but perhaps this solution is not as solid as first thought.

I'm more worried that the 1/20 second limit you are seeing comes
from something totally unintended.  That would mean that checking
for mouse events in a computational loop, which was intended to
be essentially free, may have a noticeable cost.

	Ethan


> Peter
> 
>