Re: interactive game demo for gnuplot

[Juhász P. <pet...@gm...>]

On Sun, 2013-08-25 at 15:44 -0500, Daniel J Sebald wrote:
> On 08/25/2013 03:14 PM, sfeam (Ethan Merritt) wrote:
> > 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.
> 
> That may be the case.  I just updated to the latest code to test out 
> this game, but there are some things that don't look right.
> 
> The first thing noticeable on my system is that the input at the command 
> line in the shell window isn't working properly.  The introductory text 
> is typed on the screen, then gnuplot stops.  After typing return, I then 
> see the rest of the text appear that draws the "gnuplot>" line.  Typing 
> return again will shift the window contents upward but then again 
> gnuplot halts and I must again type return to get "gnuplot>" to appear. 
>   Summarizing, it's as though the Enter key must be typed twice to have 
> the same effect as a single Enter key being pressed.
> 

I think this is because the new gnuplot executable is incompatible with
the old gnuplot_x11 driver, you have to re-install the latter as well.

Peter