Menu
▾
▴
gnuplot-beta
|
From: Juhász P. <pet...@gm...> - 2013-08-21 15:39:56
Attachments:
nibbles.plt
|
Dear gnuplot list members, 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. I haven't committed it to cvs straight away because for some reason it does not work with the wxt terminal. It works with x11, I haven't tested others. Have fun! Peter Juhasz |
|
From: Ethan A M. <sf...@us...> - 2013-08-21 17:48:47
|
On Wednesday, August 21, 2013 08:39:45 am Juhász Péter wrote: > Dear gnuplot list members, > > 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. > > I haven't committed it to cvs straight away because for some reason it > does not work with the wxt terminal. It works with x11, I haven't tested > others. It doesn't work for Qt either. In both cases it seems that eventa sent through the reverse communication pipe (from the display thread to the main thread) are being buffered rather than being processed synchronously. I tried adding a m_socket->flush() command in Qt, but that didn't help. I suppose the problem in wxt has something to do with the select() at line 3579 of wxt_gui.cpp. This must be a standard problem, but I'm not familiar enough with either wxWidgets or Qt to know the standard answer. Ethan > > Have fun! > > Peter Juhasz > > |
|
From: Petr M. <mi...@ph...> - 2013-08-22 11:39:14
|
> 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! Just few ideas - add demo for bind commands: faster slower shape of snake's body - rectangle (snake) or circle (caterpillar) set obj 1000+iter circle at ix-0.5, iy+0.5 size 0.5,0.5 fc rgb "black" fs solid Looking forward to Tetris in gnuplot! Petr |
|
From: Juhász P. <pet...@gm...> - 2013-08-25 10:39:28
Attachments:
xixit.plt
|
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! > > Just few ideas - add demo for bind commands: > faster > slower > shape of snake's body - rectangle (snake) or circle (caterpillar) > set obj 1000+iter circle at ix-0.5, iy+0.5 size 0.5,0.5 fc rgb > "black" fs solid > > > Looking forward to Tetris in gnuplot! > > Petr I couldn't resist the challenge... It's not "real" Tetris but a variant called Xixit that I used to play a lot on my 486. (I decided against Tetris because I had doubts about the legal status of a reimplementation.) I also have doubts whether it should be included in the demo suite: the game logic is sufficiently complex that it begins to strain the limits of gnuplot. Well, theoretically, we have conditional execution, variables and eval in gnuplot, so it can do anything, but the point is whether it is sensible to do so - and if someone said this example is not sensible, I'd have to agree. That said, it's playable and actually quite addictive. Have fun, Peter Juhasz |
|
From: <pl...@pi...> - 2013-08-25 20:46:14
|
On 08/25/13 12:39, 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! >> >> Just few ideas - add demo for bind commands: >> faster >> slower >> shape of snake's body - rectangle (snake) or circle (caterpillar) >> set obj 1000+iter circle at ix-0.5, iy+0.5 size 0.5,0.5 fc rgb >> "black" fs solid >> >> >> Looking forward to Tetris in gnuplot! >> >> Petr > > I couldn't resist the challenge... > > It's not "real" Tetris but a variant called Xixit that I used to play a > lot on my 486. (I decided against Tetris because I had doubts about the > legal status of a reimplementation.) > > I also have doubts whether it should be included in the demo suite: the > game logic is sufficiently complex that it begins to strain the limits > of gnuplot. Well, theoretically, we have conditional execution, > variables and eval in gnuplot, so it can do anything, but the point is > whether it is sensible to do so - and if someone said this example is > not sensible, I'd have to agree. > > That said, it's playable and actually quite addictive. > > Have fun, > > Peter Juhasz > Excellent work! It may be a bit OTT but I think it is an excellent way to demonstrate the interactive possibilities of gnuplot , and after all , that's what demos are for. The fact that this does not work on wxt and qt probably should be regarded as pointing out a bug in the interactive code of those terminals. Though it would probably need someone pretty familiar with those libraries to find out why, it probably is worth noting. Now does it work on SVG or canvas ? ;) > That said, it's playable and actually quite addictive. Yes, last time I played tetris it lasted 24h ! It was great fun but I decided that's probably enough futility for one lifetime. Nice contribution. ;) |
|
From: Petr M. <mi...@ph...> - 2013-08-26 07:05:05
|
>> Looking forward to Tetris in gnuplot! > I couldn't resist the challenge... > > It's not "real" Tetris but a variant called Xixit that I used to play a > lot on my 486. Fantastic!!! Now it runs slightly better on qt than on x11. In the setup, I propose - bind the up arrow to nothing - bind also normal +/- to faster/slower - unset mouse > (I decided against Tetris because I had doubts about the legal status of a > reimplementation.) I don't think there are any nowadays; there is also tetris as a vim plugin. > I also have doubts whether it should be included in the demo suite: the > game logic is sufficiently complex that it begins to strain the limits > of gnuplot. Well, theoretically, we have conditional execution, > variables and eval in gnuplot, so it can do anything, but the point is > whether it is sensible to do so - and if someone said this example is > not sensible, I'd have to agree. I think there can be a subdirectory games/ in the demo directory. And on web page as well. --- PM |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2013-08-25 17:29:19
|
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 > > > > Just few ideas - add demo for bind commands: > > faster > > slower > > shape of snake's body - rectangle (snake) or circle (caterpillar) > > set obj 1000+iter circle at ix-0.5, iy+0.5 size 0.5,0.5 fc rgb > > "black" fs solid > > > > > > Looking forward to Tetris in gnuplot! > > > > Petr > > I couldn't resist the challenge... > > It's not "real" Tetris but a variant called Xixit that I used to play a > lot on my 486. (I decided against Tetris because I had doubts about the > legal status of a reimplementation.) > > I also have doubts whether it should be included in the demo suite: the > game logic is sufficiently complex that it begins to strain the limits > of gnuplot. Well, theoretically, we have conditional execution, > variables and eval in gnuplot, so it can do anything, but the point is > whether it is sensible to do so - and if someone said this example is > not sensible, I'd have to agree. > > That said, it's playable and actually quite addictive. > > Have fun, > > Peter Juhasz > > |
|
From: Juhász P. <pet...@gm...> - 2013-08-25 18:49:03
|
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
>
If I'm allowed one further observation I made during "development" of
these demos:
The "set mouse" family of commands seems to be exempt from the effect of
reset.
e.g.
set mouse verbose
plot x
# poke the mouse wheel or something
reset
replot
# the verbose reports are still there
or
unset mouse
reset
show mouse
# still off
Perhaps there are other misbehaving options.
Speaking of reset, the error reporting of that command is quite obtuse.
reset foo
^
line 0: warning: expected optional axis name
^
';' expected
The online help does not mention that properties can be reset on an
axis-by-axis basis (if that is indeed the meaning of the error message),
conversely, the options mentioned in the help are missing from the error
message.
Peter Juhasz
|
|
From: Juhász P. <pet...@gm...> - 2013-08-25 19:25:23
|
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. 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. Peter |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2013-08-25 20:15:05
|
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
>
>
|
|
From: Daniel J S. <dan...@ie...> - 2013-08-25 20:44:57
|
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.
As for the game, it seems to run fine, but it is whirling away redrawing
the cursor position at the bottom of the screen as well as the cursor
itself. If I move the mouse around, it's only when I get the mouse
positioned over some graph object like text that this redrawing speed
slows down to what I've seen in past versions.
So I think you are on the right track that somehow gnuplot is getting
into a mode where it runs away unintentionally.
Dan
|
|
From: Juhász P. <pet...@gm...> - 2013-08-25 21:10:17
|
On Sun, 2013-08-25 at 13:14 -0700, 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.
I tested with the x11 terminal.
I may have misinterpreted the symptoms: the apparent choppiness, and the
apparently longer pause after a triplet of block lands or cancels.
I do see something now that may hold a clue: press and hold the down key
to drop the blocks faster. In the old version I normally use the motion
appears smooth and the new blocks appear as soon as the old ones land,
meaning that the intended game logic works as intended.
In the new version the new blocks don't appear at all until you release
the down key, and then only after a noticeable pause (and the game logic
is apparently messed up, because several replots, among other things,
seem to be skipped.)
This indicates that the event handling somehow blocks the main thread.
>
> 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.
For what it's worth, I did some informal testing on the performance of
various versions with a synthetic test:
perl -le 'print "set term $TERM";for(1..5000){print "plot x,
".(sin($_/1000))."*x; $PAUSE"}' > fos; time $GNUPLOT fos
where $TERM was either wxt or x11, $PAUSE either "pause 0.005 or
nothing, and $GNUPLOT an old 4.5 version from 2011, cvs from 2013-08-22,
and current cvs.
Times are in seconds.
wxt wxt x11(*) x11
nopause pause nopause pause
4.5 10.483 16.488 7.326 6.166
cvs/23 9.595 16.645 3.597 6.410
cvs/25 12.387 19.387 9.969 8.665
(*) means that the iteration count was raised to 5000 in those tests to
get a comparable runtime.
So it looks that yesterday's modifications do incur some performance
penalty, both with and without pauses.
>
> Ethan
>
>
> > Peter
> >
> >
>
|
|
From: Juhász P. <pet...@gm...> - 2013-08-25 21:15:25
|
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
|
|
From: Daniel J S. <dan...@ie...> - 2013-08-25 21:34:07
|
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
|
|
From: Daniel J S. <dan...@ie...> - 2013-08-25 21:42:47
|
On 08/25/2013 04:33 PM, Daniel J Sebald wrote: > 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: [snip] >>> 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. I just rebuilt with the Qt terminal installed. That behaves very well (nice). There is no shell command line issue in that case. It would seem either this has something to do with installing the x11 terminal as the active terminal even though a plot hasn't been performed yet at start, or it is some bad pointer into memory that this corrupting a hunk of code. Dan |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2013-08-25 23:20:40
|
On Sunday, 25 August 2013, Daniel J Sebald wrote: > 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). Oops. Sorry. There was a line missing from x11.trm in yesterday's cvs version. It would hang waiting for terminal input if the input was from a file but the terminal was x11. Not good. Fixed in CVS as of a minute ago. > Huh, after running some demos, gnuplot now behaves like normal at the > shell command line...but it still has the super fast redrawing. I have not yet seen any case of "super fast redrawing". Could you explain in more detail? thanks for testing! Ethan |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2013-08-25 23:51:20
|
On Sunday, 25 August 2013, Juhász Péter wrote:
> For what it's worth, I did some informal testing on the performance of
> various versions with a synthetic test:
>
> perl -le 'print "set term $TERM";for(1..5000){print "plot x,
> ".(sin($_/1000))."*x; $PAUSE"}' > fos; time $GNUPLOT fos
>
> where $TERM was either wxt or x11, $PAUSE either "pause 0.005 or
> nothing, and $GNUPLOT an old 4.5 version from 2011, cvs from 2013-08-22,
> and current cvs.
>
> Times are in seconds.
>
> wxt wxt x11(*) x11
> nopause pause nopause pause
> 4.5 10.483 16.488 7.326 6.166
> cvs/23 9.595 16.645 3.597 6.410
> cvs/25 12.387 19.387 9.969 8.665
I get quite different results using your script.
Loop variable set to 1000
no pause or "pause 0.005"
average of two timing runs
4.4.4 4.6.3 cvs 25 Aug
=====================
wxt nopause 8.04 8.00 8.88
wxt pause 0.005 11.33 11.66 13.82
x11 nopause 8.78 8.47 6.37
x11 pause 0.005 8.80 8.50 8.04
qt nopause n/a 4.52 4.39
qt pause 0.005 n/a 6.11 8.49
Note: same script with pause 0.050 (1/20 sec) takes essentially
59 seconds whatever the terminal type.
1000 / 20 = 50 seconds, so I think the timer is doing exactly
what it is asked for.
The only thing I find surprising or unexpected here is that
qt is faster than both wxt and x11.
X11 with no pause is slightly faster than in earlier versions,
but I think that is likely due to Dima Kogan's speed optimizations.
> So it looks that yesterday's modifications do incur some performance
> penalty, both with and without pauses.
I can try again tomorrow on a different machine, but so far
I'm not seeing that.
Ethan
|
|
From: Daniel J S. <dan...@ie...> - 2013-08-26 05:34:15
|
On 08/25/2013 06:20 PM, sfeam (Ethan Merritt) wrote:
> On Sunday, 25 August 2013, Daniel J Sebald wrote:
>> 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).
>
> Oops. Sorry.
> There was a line missing from x11.trm in yesterday's cvs version.
> It would hang waiting for terminal input if the input was from a
> file but the terminal was x11. Not good.
> Fixed in CVS as of a minute ago.
>
>> Huh, after running some demos, gnuplot now behaves like normal at the
>> shell command line...but it still has the super fast redrawing.
>
> I have not yet seen any case of "super fast redrawing".
> Could you explain in more detail?
>
> thanks for testing!
>
> Ethan
OK, with the latest code the shell command line is working properly
again. Thanks Ethan.
As for the redrawing, it is simply that the position coordinates at the
bottom of the page are redrawn superfast and similarly the cursor icon
flickers between the cross and the busy symbol.
Looking more closely at the xixit.plt file, it looks like there are some
bugs to work out yet. The reason this is being refreshed so quickly is
that a redraw is forced every time through the loop. When I comment
that out:
iter = iter + 1
# do_redraw = 1
# and finally show the new state if needed
if (do_redraw) {
eval redraw
do_redraw = 0
replot
}
things behave more nicely. I've also come across the situation where I
get this error:
gnuplot> block_7_-1 = tc
because
"j = ymin;".\
and
block(i, j) = sprintf("block_%d_%d", int(i), int(j))
so if ymin becomes negative, that creates a syntax problem. I'm not
sure how ymin is becoming negative, but I think there are a lot of key
bindings that do something to move the plot around. If those keys
aren't bound to some bogus function that does nothing, they might cause
problems. For example, the up-arrow seems to move all the blocks
downward out of the window, but I don't see that the up-arrow is
"binded" to anything in the xixit.plt code.
Pressing and holding down the down-arrow can make the blocks drop past
the end of the screen and the game seems to get stuck as a consequence,
but I'm not 100% sure what it is supposed to do to move the stack downward.
I think that the pause can be much longer than 0.005. If I understand
the program correctly, the redraw isn't supposed to happen until the
blocks move, and that seems to be the case when commenting out
"do_redraw = 1" as above. The user's keypad action can initiate a
change in the plot, but I'd think there is no way someone playing the
game could type keys faster than, say, 1/10 of a second. I changed
"pause" to 0.1 and "wait" to 5 and the games seems to run fairly fast.
(I'd think one would want it to run fast by default and make it
challenging for the user.)
Dan
|
|
From: <pl...@pi...> - 2013-08-26 10:51:18
|
On 08/26/13 07:34, Daniel J Sebald wrote: > For example, the up-arrow seems to move all the blocks > downward out of the window, but I don't see that the up-arrow is > "binded" to anything in the xixit.plt code. Isn't that the expected plot scrolling action? /Peter |
|
From: Petr M. <mi...@ph...> - 2013-08-26 13:27:24
|
>> For example, the up-arrow seems to move all the blocks >> downward out of the window, but I don't see that the up-arrow is >> "binded" to anything in the xixit.plt code. > > Isn't that the expected plot scrolling action? yes, it's scrolling, thus this default action needs to be bind to "nothing". -- Petr |
|
From: <pl...@pi...> - 2013-08-30 23:21:17
|
Hi, this is only a niggle but a niggle that bugs me every day and every time I use gnuplot. Why isn't "auto-scale" included in the history of scaling values stored for the previous/next scale feature. eg reset plot datafile w l set xr [1:10]; replot now in an interactive terminal (eg wxt) I hit "p" but instead of it returning to autoscale it jumps to some scaling I used yesterday on a different plot. ie , the last NON autoscale setting of xr. Equally, if I explicitly set 'auto' and then zoom to some other setting, it does not get counted next time I do 'previous'. Is there a problem with including auto as a value in the scaling history? regards, Peter. |
|
From: sfeam <E. A Merritt> <sf...@us...> - 2013-08-30 23:48:21
|
On Friday, 30 August, 2013 21:45:50 pl...@pi... wrote: > Hi, > > this is only a niggle but a niggle that bugs me every day and every time > I use gnuplot. > > Why isn't "auto-scale" included in the history of scaling values stored > for the previous/next scale feature. > > eg > > reset > plot datafile w l > set xr [1:10]; replot > > now in an interactive terminal (eg wxt) I hit "p" but instead of it > returning to autoscale it jumps to some scaling I used yesterday on a > different plot. ie , the last NON autoscale setting of xr. > > Equally, if I explicitly set 'auto' and then zoom to some other setting, > it does not get counted next time I do 'previous'. > > Is there a problem with including auto as a value in the scaling history? Could it be that you are looking for the "u" hot key? Ethan > > > regards, Peter. > > > > ---------------------------------------------------------------------------- > -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! > Discover the easy way to master current and previous Microsoft technologies > and advance your career. Get an incredible 1,500+ hours of step-by-step > tutorial videos with LearnDevNow. Subscribe today and save! > http://pubads.g.doubleclick.net/gampad/clk?id=58040911&iu=/4140/ostg.clktrk > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta |
|
From: Juhász P. <pet...@gm...> - 2013-08-26 18:52:59
Attachments:
metaball1.sh
|
On Sun, 2013-08-25 at 16:51 -0700, sfeam (Ethan Merritt) wrote: > On Sunday, 25 August 2013, Juhász Péter wrote: [snip] > The only thing I find surprising or unexpected here is that > qt is faster than both wxt and x11. > X11 with no pause is slightly faster than in earlier versions, > but I think that is likely due to Dima Kogan's speed optimizations. About those, see the next attachment. ./metaball1.sh > foo; gnuplot foo With earlier versions the animation is quite smooth. With the current cvs it's glacial. So those optimizations may backfire in some cases. Interestingly, the more obvious ./metaball1.sh | gnuplot - is uselessly slow in all cases, because gnuplot echoes all commands to the terminal, but even with redirecting the output to /dev/null it is slower than in the file-reading case. (about this demo: it's adapted from a demo a colleague of mine wrote for his project called animator, http://repo.hu/projects/animator/ ) Peter |
|
From: Ethan A M. <sf...@us...> - 2013-08-26 19:48:35
|
On Monday, August 26, 2013 11:52:47 am Juhász Péter wrote: > On Sun, 2013-08-25 at 16:51 -0700, sfeam (Ethan Merritt) wrote: > > On Sunday, 25 August 2013, Juhász Péter wrote: > > [snip] > > > The only thing I find surprising or unexpected here is that > > qt is faster than both wxt and x11. > > X11 with no pause is slightly faster than in earlier versions, > > but I think that is likely due to Dima Kogan's speed optimizations. > > About those, see the next attachment. > > ./metaball1.sh > foo; gnuplot foo > > With earlier versions the animation is quite smooth. With the current > cvs it's glacial. So those optimizations may backfire in some cases. It's glacial because your demo puts it in a poll/wait loop where each poll has the 1 msec timeout that I mentioned earlier. If I reset that timeout to zero, then the timing for current cvs is comparable to earlier versions: $ time gnuplot_4.4.4 foo 3.156u 0.506s 0:04.37 83.5% $ time gnuplot_4.6.3 foo 4.525u 0.517s 0:05.16 97.4% $ time ~/cvs/gnuplot-cvs/src/gnuplot foo 3.440u 0.721s 0:04.39 94.7% It seems the 1 msec delay was a bad idea. I'll make it a defined constant in term_api.h, set it to 0 by default, and update CVS so you can test it. > Interestingly, the more obvious ./metaball1.sh | gnuplot - is uselessly > slow in all cases, because gnuplot echoes all commands to the terminal, > but even with redirecting the output to /dev/null it is slower than in > the file-reading case. Perhaps we should add a command line option -noprompt or something like that to suppress the echo if it is not wanted. > (about this demo: it's adapted from a demo a colleague of mine wrote for > his project called animator, http://repo.hu/projects/animator/ ) nice! > > Peter Ethan |
|
From: <pl...@pi...> - 2013-08-31 01:48:18
|
On 08/31/13 01:47, sfeam <Ethan A Merritt> wrote: > On Friday, 30 August, 2013 21:45:50 pl...@pi... wrote: >> Hi, >> >> this is only a niggle but a niggle that bugs me every day and every time >> I use gnuplot. >> >> Why isn't "auto-scale" included in the history of scaling values stored >> for the previous/next scale feature. >> >> eg >> >> reset >> plot datafile w l >> set xr [1:10]; replot >> >> now in an interactive terminal (eg wxt) I hit "p" but instead of it >> returning to autoscale it jumps to some scaling I used yesterday on a >> different plot. ie , the last NON autoscale setting of xr. >> >> Equally, if I explicitly set 'auto' and then zoom to some other setting, >> it does not get counted next time I do 'previous'. >> >> Is there a problem with including auto as a value in the scaling history? > > Could it be that you are looking for the "u" hot key? > > Ethan > > Thanks but no. p `builtin-zoom-previous` go to previous zoom in the zoom stack u `builtin-unzoom` I'm talking about the unzoomed (autoscaled) state being included in the zoom stack. ie first plot would put "auto" onto the zoom stack as would reset; replot eg reset set xr [1:50] plot datafile w l set auto; replot set xr [1:10]; replot then pressing p hotkey would take me to the unzoomed state not [1:50] as it currently does. a second "p" would then take me to [1:50] Although set auto is the "unzoomed" state it is a finite scaling option that has been viewed and likely explicitly set. The special treatment of this scaling is disrouting and frequently rather inconvenient. I hope that's clearer. regards, Peter. |
