Re: interactive game demo for gnuplot

[Daniel J S. <dan...@ie...>]

On 08/25/2013 04:15 PM, Juhász Péter wrote:
> 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.

That part of gnuplot doesn't have anything to do with gnuplot_x11 (same 
odd behavior), but good point.

As for the demo, updating gnuplot_x11 via the install makes things 
worse.  xixit.plt doesn't create any type of plot (gnuplot_x11 doesn't 
appear).  But I'm not sure this is because there are a lot of tabs in 
the xixit.plt code that makes it difficult to cut and paste into the 
command line having tab-completion on.

Huh, after running some demos, gnuplot now behaves like normal at the 
shell command line...but it still has the super fast redrawing.

Dan