gnuplot-beta — Developers and beta testers of new gnuplot code

Re: interactive game demo for gnuplot

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

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

Re: interactive game demo for gnuplot

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

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

Re: interactive game demo for gnuplot

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

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

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

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

Re: interactive game demo for gnuplot

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

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
> > 
> > 
> 

Re: interactive game demo for gnuplot

[<pl...@pi...>]

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. ;)

Re: interactive game demo for gnuplot

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

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

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
> 
> 

Re: interactive game demo for gnuplot

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

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

reset, was Re: interactive game demo for gnuplot

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

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

Re: interactive game demo for gnuplot

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

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
> 
> 

Re: interactive game demo for gnuplot

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

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

Re: Mousing hotkeys i/v/V to toggle multiple plots on or off

[Jon G. <jo...@th...>]

> > Actually I think that one key would be enough (the invert one) as
> > hotkeys are hit by the user, not by the script or piping program -
> > there is also just one key for toggling grid, log, ruler, ...
>
> I had the same initial reaction as you, that only the "i" key was
> necessary, since you could get back the full set of plots with a
> replot or "e" key.
>
> It is still true that  "V" = "v" + "i"  and therefore so far as I can see
> only one of the keys "v" or "V" is needed.

The main reason behind this patch was to make dealing with plots with a
large number of lines less of a pain, and in that light the most useful
operation is hiding all lines. *Showing* all lines on the other hand
seems less useful to me, and in any case as Ethan points out, we have
the "e" key for this. It therefore makes most sense to me if the
shortcut that is kept is "V" (hide all lines; this could be changed to
"v"). "v" (show all) is not all that important to me.

As to whether "V" is needed at all considering you can do it with "e" +
"i", I know I would personally much prefer the operationto be possible
with a single key. That said, perhaps the default configuration could be
to have "i" only, but keep the builtins so that people could bind "V" or
"v" if they'd like?

> The counterexample is a multiplot. You cannot replot an individual
> panel of the multiplot, but the "v/V" keys do work to display or hide
> the full set of plots in that panel.

I don't have much experience with multiplots, but it seems to me like
"V" could still be useful considering "e" might not really do what you
want (nor what you'd expect).

> > In order to achieve this functionality from command line, a command
> > like "set plot visibility {on|off|invert}"
>
> The issues of multiple windows or multiplots in a single window
> complicate this.  If you read through the discussion attached to the
> patch, you'll see that we discussed adding additional parameters to
> the term->modify_plots() interface to handle multiple plots or windows.

The ideal would be to be able to say something like:

	set plot 1:1 visibility on    # Show plot 1 in window 1
	set plot 2:3-5 visibility off # Hide plots 3-5 in window 2
	set plot 2: visibility invert # Invert visibility of all plots
	                              # in window 2

Unfortunately, gnuplot does not (currently) keep track of the visibility
of individual plots, nor does it (afaik) have a standardized way of
specifying a certain window or (range of) plot(s).

That said, it should certainly be possible to implement. `modify_plots`
was imagined to be quite generic, and adding parameters for window and
plot specifiers should be quite straightforward once a good standard for
this is decided.

> But I thought people would like to try it out in the current form
> before discussing possible extensions.

^ This.

> > I propose to have only "v" key to invert the visibility and the "set plot" 
> > command.

I think having "hide all" as well would be very useful for some users
(myself included).

Jon

Re: Mousing hotkeys i/v/V to toggle multiple plots on or off

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

On Thursday, 22 August 2013, Petr Mikulik wrote:
>  	Hello Ethan,
> 
> > Log Message:
> > Mousing hotkeys i/v/V to toggle multiple plots on or off
> > RCS file: /cvsroot/gnuplot/gnuplot/src/mouse.c,v
> 
> please change the sequence of bind associations to group V/v/i together:
> 
>        bind_append("V", (char *) 0, builtin_set_plots_invisible);
>        bind_append("v", (char *) 0, builtin_set_plots_visible);
>        bind_append("i", (char *) 0, builtin_invert_plot_visibilities);
> 
> Actually I think that one key would be enough (the invert one) as hotkeys are 
> hit by the user, not by the script or piping program - there is also just one 
> key for toggling grid, log, ruler, ...

I will let Jon Gjengset answer that, since it is his patch (cc'ed on this message).
See discussion at
  https://sourceforge.net/p/gnuplot/patches/633/

I had the same initial reaction as you, that only the "i" key was necessary,
since you could get back the full set of plots with a replot or "e" key.
The counterexample is a multiplot.   You cannot replot an
individual panel of the multiplot, but the "v/V" keys do work to 
display or hide the full set of plots in that panel.

It is still true that  "V" = "v" + "i"  and therefore so far as I can see
only one of the keys "v" or "V" is needed.

> In order to achieve this functionality from command line, a command like
>  	set plot visibility {on|off|invert}
> similarly to
>  	set mouse ruler at 1,1
>  	set mouse noruler

I agree that some command line interface is possible.
That was the reason for implementing this as a terminal entry point
rather than just handling the hotkey event inside the each terminal
driver without notifying the core code.

The issues of multiple windows or multiplots in a single window
complicate this.  If you read through the discussion attached to the
patch, you'll see that we discussed adding additional parameters to
the term->modify_plots() interface to handle multiple plots or windows.
But I thought people would like to try it out in the current form
before discussing possible extensions.

	Ethan

> I propose to have only "v" key to invert the visibility and the "set plot" 
> command.
> 
> ---
> PM
> 

Re: interactive game demo for gnuplot

[Petr M. <mi...@ph...>]

> 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

Mousing hotkeys i/v/V to toggle multiple plots on or off

[Petr M. <mi...@ph...>]

 	Hello Ethan,

> Log Message:
> Mousing hotkeys i/v/V to toggle multiple plots on or off
> RCS file: /cvsroot/gnuplot/gnuplot/src/mouse.c,v

please change the sequence of bind associations to group V/v/i together:

       bind_append("h", (char *) 0, builtin_help);
       bind_append("i", (char *) 0, builtin_invert_plot_visibilities);
       bind_append("l", (char *) 0, builtin_toggle_log);
       bind_append("L", (char *) 0, builtin_nearest_log);
       bind_append("m", (char *) 0, builtin_toggle_mouse);
       bind_append("r", (char *) 0, builtin_toggle_ruler);
       bind_append("V", (char *) 0, builtin_set_plots_invisible);
       bind_append("v", (char *) 0, builtin_set_plots_visible);
       bind_append("i", (char *) 0, builtin_invert_plot_visibilities);


Actually I think that one key would be enough (the invert one) as hotkeys are 
hit by the user, not by the script or piping program - there is also just one 
key for toggling grid, log, ruler, ...

In order to achieve this functionality from command line, a command like
 	set plot visibility {on|off|invert}
similarly to
 	set mouse ruler at 1,1
 	set mouse noruler

I propose to have only "v" key to invert the visibility and the "set plot" 
command.

---
PM

Re: interactive game demo for gnuplot

[Ethan A M. <sf...@us...>]

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
> 
> 

interactive game demo for gnuplot

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

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

gnuplot on 64-bit Windows, again

[Allin C. <cot...@wf...>]

Follow-up to my posting of July 24: I now have a mingw64 build 
of gnuplot that works correctly on Windows 8. Encouraged by 
this I'm re-posting my patch set. It's smaller this time 
because I'm skipping the changes that Ethan (very reasonably) 
didn't like. (These were designed to hush compiler warnings 
stemming from a perverse Microsoft API rather than any real 
problem in the gnuplot code.)

All my changes are bracketed by ifdef _WIN64, so they 
shouldn't affect any other builds.

Besides patches to the C code I had to do two things to get a 
working build for Windows 8:

1) The file win/wgnuplot.exe.manifest specifies the 
processorArchitecture as "X86". For an x86_64 build this must 
be changed to "amd64" (or wgnuplot.exe won't start). The 
manifest file is included by win/wgnuplot.rc. I've modified 
wgnuplot.rc so that it includes an alternative manifest file, 
wgnuplot.exe.manifest64, if the symbol _WIN64 is defined. (The 
alternative file simply substitutes "amd64" for "X86" in two 
places. To support ming64, wgnuplot.exe.manifest64 should be 
added to the repository.)

2) For the symbols needed for HTML Help support, I tried using 
a 64-bit version of htmlhelp.lib from the current Windows SDK. 
The linker choked on this, with some weird error messages. 
Googling reveals that htmlhelp.lib is some sort of glue or 
shim, and the real business is done by hhctrl.ocx. So I took a 
copy of the 64-bit hhctrl.ocx from Windows 8, used pexports to 
create a .def file, then used mingw64's dlltool to create an 
import library, hhctrl.dll.a. I modified the mingw Makefile, 
substituting "-lhhctrl.dll" for "-lhtmlhelp". The linker was 
then happy and HTML help works OK.

There's nothing in my patch set pertaining to point 2), at 
this point it's just a heads-up for anyone trying a mingw64 
build.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: confusing option name for wxWidgets configuration

[Ethan A M. <sf...@us...>]

On Friday, August 09, 2013 01:46:57 am Mojca Miklavec wrote:
> On Wed, Aug 7, 2013 at 7:22 PM, sfeam (Ethan Merritt) wrote:
> > On Wednesday, 07 August 2013, Mojca Miklavec wrote:
> >> On Wed, Aug 7, 2013 at 7:19 AM, sfeam (Ethan Merritt) wrote:
> >
> >>> The "official" options are:
> >>>     AC_ARG_WITH(wxdir,
> >>>                 [  --with-wxdir=PATH       Use uninstalled version of wxWidgets in PATH],
> >>>                 [ wx_config_name="$withval/wx-config"
> >
> > Wait. Are you saying it would be better to have
> >    --with-wxdir=PATH
> > than it is to have the current
> >    --with-wx-config=PATH
> > ??
> 
> Yes.
> 
> Not for the reason of "more functionality", but for the reason of
> better consistency with upstream wxWidgets.

OK. Done.

	Ethan

Re: confusing option name for wxWidgets configuration

[Mojca M. <moj...@gm...>]

On Wed, Aug 7, 2013 at 7:22 PM, sfeam (Ethan Merritt) wrote:
> On Wednesday, 07 August 2013, Mojca Miklavec wrote:
>> On Wed, Aug 7, 2013 at 7:19 AM, sfeam (Ethan Merritt) wrote:
>
>>> The "official" options are:
>>>     AC_ARG_WITH(wxdir,
>>>                 [  --with-wxdir=PATH       Use uninstalled version of wxWidgets in PATH],
>>>                 [ wx_config_name="$withval/wx-config"
>
> Wait. Are you saying it would be better to have
>    --with-wxdir=PATH
> than it is to have the current
>    --with-wx-config=PATH
> ??

Yes.

Not for the reason of "more functionality", but for the reason of
better consistency with upstream wxWidgets.

> I don't mind that, but either way it asks for a PATH not a filename.
> And you'd still have to create the file $withval/wx-config

Yes, I know. This is why I suggested to support both --with-wxdir=PATH
and --with-wx-config=FILE, but even if supporting both isn't
acceptable for gnuplot, it would still be better to have consistent
name.

> Finally, I don't understand why there is a problem having both versions
> 2.8 and 2.9 installed.

It's not a problem of not being able to have both installed at some
obscure location. But it's impossible to have wx-config installed for
both at default location.

On the link you gave me there's an example of using wx-config:
    g++ `wx-config --cxxflags` -o out *.cpp `wx-config --libs`

Say that "wx-config" points to the installation of version 2.9 (it
cannot point to both). On my machine wx-config --cflags returns the
following for example:
    -I/opt/local/lib/wx/include/osx_cocoa-unicode-2.9
-I/opt/local/include/wx-2.9 ...

If another package requires 2.8 and simply calls "wx-config" (as in
the example above) without letting the user configure where to find
wx-config, one simply cannot install that package without nasty
patches.

> For better or worse (mostly the latter) OSX does
> not have a system-wide ld.so.conf list of library paths, so there should not
> be a problem that causes only one of the two versions to be found as
> default by all programs.

I didn't understand that. (In case of gnuplot the library search path
is set by wx-config at compile time. Once the binary is compiled
against the right wxWidgets there are no problems any more. The only
"problem" arises when configuring/compiling software that depends on
wxWidgets.)

Mojca

Re: Automatically keeping "last modified" up to date

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

On Wednesday, 07 August 2013, Hans-Bernhard Bröker wrote:
> On 07.08.2013 19:49, sfeam (Ethan Merritt) wrote:
> 
> > How about changing version.c to something like
> >
> > #ifndef LAST_MODIFIED
> > #define LAST_MODIFIED "2012-06-19"
> > #endif
> > const char gnuplot_date[] = LAST_MODIFIED;
> >
> > And then using some autotools magic that I would have to hunt for
> > do something along the lines of
> 
> It would have to be different magic, I'm afraid.  Autotools isn't run at 
> the point in time that counts: a simple re-make of an already configured 
> source tree.
> 
> > LAST_MODIFIED = <some magic involving awk or grep>
> > DEFS = $DEFS -DLAST_MODIFIED=${LAST_MODIFIED}
> 
> > That should reproduce the current behavior without modifying
> > any source files.
> 
> Not quite.  Changes to non-source files (like the Makefile) don't 
> trigger re-builds of version.o.  There has to be some artificial 
> dependence of version.o on ChangeLog added to the generated Makefile.

The attached patch does the trick for me, but it probably fails 
for those same out-of-tree builds that were failing already.

It replaces the stuff currently in src/Makefile.maint with the following:
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
version.o: modification_date

modification_date: ../ChangeLog
        @echo Making $@
        echo "#undef LAST_MODIFIED" >> ../config.h
        echo "#define LAST_MODIFIED \"${last_change}\"" >> ../config.h
        echo "#define LAST_MODIFIED \"${last_change}\"" > modification_date
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

modification_date is declared a BUILT_FILE in Makefile.am so it gets 
created before anything else.

The main problem with this from my perspective is that if you touch
the ChangeLog at all, it triggers a rebuild of everything, not just version.o,
because it appends the date to config.h and everything depends on that.

I imagine there is a way to generate a new file at the top level that, 
like config.h, is considered OK to modify.  But I don't know how to do that.

If the people who don't like the current mechanism are happier with
this one, please help clean up the out-of-tree builds.
Is it just a matter of adding $(top_srcdir) etc throughout Makefile.maint?

	Ethan

Re: Automatically keeping "last modified" up to date

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

On Wed, 2013-08-07 at 09:42 +0100, Allin Cottrell wrote:
> On Tue, 6 Aug 2013, Ethan A Merritt wrote:
> 
> > On Tuesday, August 06, 2013 01:01:07 pm Allin Cottrell wrote:
> >> On Tue, 6 Aug 2013, Ethan A Merritt wrote:
> >>
> >>> On Tuesday, August 06, 2013 12:26:04 pm Allin Cottrell wrote:
> >>>> There's one other fishy thing in that neighborhood. When I do
> >>>> a cvs update it seems I quite often get the cvs 'M' flag
> >>>> indicating that src/version.c is modified, when I certainly
> >>>> haven't edited that file.
> >>>> Allin Cottrell
> >>>
> >>> Exactly.  That's as expected.
> >>> When you run "make" it changes gnuplot_date[] in version.c file to reflect
> >>> the most recently modified date.  So if you later update from CVS it sees
> >>> that your local copy of version.c is different from the base copy in CVS.
> >>
> >> OK, I see. And I don't think this is a big deal. But isn't it
> >> sort of a principle of version control to operate a strict
> >> separation between files that are supplied from the repository
> >> (and hence are, in a sense, "read-only") and files that are
> >> automatically generated in the course of a build? Gnuplot's
> >> version.c seems to cross that line.
> >>
> >> Allin Cottrell
> >
> > Well, that obviously doesn't make sense if your purpose in downloading
> > from CVS is to work on development.  The files are clearly not read-only.
> > You are editing and re-editing them constantly during the course of an
> > edit/build/debug cycle.
> 
> That's why I said "in a sense, read-only": the "sense" was 
> supposed to be that they are in effect read-only if you're 
> just building gnuplot from CVS. You don't want to modify 
> anything inadvertently. If you're hacking on the code, 
> obviously you're free to modify any file.
> 

My 2 cents:

The technical issue we have here is rooted in a deeper matter of
principle. In any source repository there may be source files that are
"static" in the sense that they are not changed during the make process
and fed to the compiler as is, and template files, which are not
compiled directly, but some process generates the required source files
from them. Version.c, as we have it now, tries to be both: there is a
magical process in place that modifies it with the current date, but it
happens to be compilable without modification (likely because someone
have checked in a processed version to the repository earlier).

There ought to be a separation between the two kinds of files, one that
is clearly reflected in the naming convention.
So the one and only file in the repository should be a template file,
called version.c.templ or something, and the magical update process
should create from it the source file version.c, which should not be
under version control. This magical process would substitute the current
date into the file, as it does now, but, in extreme cases where there is
no sed available etc., it could fall back to simply copying the contents
of the file (which means that the default contents should be sensible
and compilable).

Peter Juhasz

Re: Segmentation core dump in fillbetween.dem due to "%lf %lf %lf"

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

On Wednesday, 07 August 2013, Daniel J Sebald wrote:
> I'm seeing a core dump in one of the demos, fillbetween.dem:

Thanks for catching that, Dan.

The immediate cause of the segfault is much simpler and stupider
on my part than the path you are worried about.  I foolishly tried
to reserve enough space for the columheader in the output string
by calling strlen(df_column[j].header),  but if there is no column
header then this is NULL.  strlen doesn't like NULL, so -- boom.

As to overflowing the format, I did worry about that.
It would overflow in the 4th digit, so you are OK up to 999 columns
of input, and I think the program will reject that many for other reasons.  
Even if there are more than 3 digits, what happens is the title
string being constructed is corrupted by the presence of the extra
digits in the middle of the result.  It doesn't overflow the total length.
But you are correct that for 100% cleanliness the code could
check explicitly against a maximum number of allowed columns.
I'm not sure what that maximum is.

Fixed in CVS, and thanks again for catching it so quickly.

	Ethan

> 
> 	G N U P L O T
> 	Version 4.7 patchlevel 0    last modified 2012-06-19
> 
> 	Copyright (C) 1986-1993, 1998, 2004, 2007-2012
> 	Thomas Williams, Colin Kelley and many others
> 
> 	gnuplot home:     http://www.gnuplot.info
> 	mailing list:     gnu...@li...
> 	faq, bugs, etc:   type "help FAQ"
> 	immediate help:   type "help"  (plot window: hit 'h')
> 
> Terminal type set to 'qt'
> gnuplot> set title "Fill area between two curves"
> gnuplot> set style data lines
> gnuplot> set xrange [10:*]
> gnuplot> set yrange [0:175]
> gnuplot> plot 'silver.dat' u 1:2:3 "%lf %lf %lf" w filledcu, \
> >      '' u 1:2 lt -1 notitle, '' u 1:3 lt -1 notitle
> Segmentation fault (core dumped)
> 
> 
> Removing the "%lf %lf %lf" format specifier fixes the problem:
> 
> Terminal type set to 'qt'
> gnuplot> set title "Fill area between two curves"
> gnuplot> set style data lines
> gnuplot> set xrange [10:*]
> gnuplot> set yrange [0:175]
> gnuplot> plot 'silver.dat' u 1:2:3  w filledcu, \
> >     '' u 1:2 lt -1 notitle, '' u 1:3 lt -1 notitle
> 
> 
> I think the problem is a recent change:
> 
> http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/datafile.c?r1=1.260&r2=1.261
> 
> I looks like there are some tricky string writes and memory frees.  This 
> line looks suspicious:
> 
>       snprintf(placeholder+11, 4, "%02d@", column_for_key_title);
> 
> if
> 
> static char placeholder[] = "@COLUMNHEAD00@";
> 
> Adding 11 to the placeholder pointer puts the pointer at the first 0 of 
> "...00@".  If I'm not mistaken, %02d means a minimum of 2 digits so it 
> could be more than 2 digits wide.  If it is more than two digits wide, 
> then either the @ or some other numeral is in the fourth position and 
> will overwrite the null terminating string and memory could be accessed 
> outside of a segment from a run-away string.  It should be
> 
>       snprintf(placeholder+11, 3, "%02d@", column_for_key_title);
> 
> but if one wants to ensure that an at-symbol @ appears at the end of the 
> string and there is adequate space for a large number, then some other 
> strategy is needed.
> 
> Could be in clearing the headers, on the other hand.
> 
> Dan