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

Re: gnuplot 4.8?

[sfeam <sf...@us...>]

On Monday, June 30, 2014 06:10:24 PM Tatsuro MATSUOKA wrote:
> ----- Original Message -----
> 
> > From: sfeam 
> > To: gnuplot-beta
> > Cc: Allin Cottrell 
> > Date: 2014/6/30, Mon 05:16
> > Subject: Re: gnuplot 4.8?
> > 
> > On Sunday, June 29, 2014 03:44:23 PM Allin Cottrell wrote:
> >>  I understand that 5.0 is supposed to be the release where the
> >>  gnuplot developers are free to make some backward-incompatible
> >>  changes. I've no problem with that, but I wonder if there's any
> >>  thought to produce a gnuplot 4.8?
> > 
> > The 4.6 development source is a separate branch in CVS.
> > The 4.7 (later 5.0) branch split off from it and gradually diverged.
> > Most bugfixes have been applied to both branches, but they have
> > diverged enough that in some cases the "fix" for a problem in 4.6
> > is limited to the existence of a better implementation in 5.0.
> > 
> > There will be at least one more patchlevel release 4.6.6.
> > My crystal ball does not tell me at what rate fixable bugs will continue
> > to be reported againt 4.6 as opposed to 5.0.  Other incremental
> > releases could eventually appear, but I don't see a good rationale for
> > starting a 4.8  series.   If a fix/change is compatible then it could go
> > into 4.6; if not then it belongs in 5.0.
> > 
> > A brief listing of changes accumulated since the last release is
> > kept at the top of the NEWS files:
> > 
> > NEWS
> > New features, changes and fixes in gnuplot version 4.6.6
> > ========================================================
> > 
> > * NEW linetype keyword "nodraw" can be used to draw only the points in
> > "with lp"
> > * NEW plot option to "skip N" lines at start of an ascii data file
> > * NEW 'set fit prescale' normalized fit parameters before M-L refinement
> > * NEW update svg terminal to grey out the key entry when a plot is toggled
> > off * CHANGE Accept "with image pixels" as a synonym for "with image
> > failsafe"
> > * CHANGE return NaN if a requested numerical data value fins a string
> > instead * CHANGE Consume only one space following the font name in an
> > enhanced test string
> > * FIX Faster recovery from outboard server gnuplot_qt being killed
> > * FIX get rid of O(N^2) memory allocation for string data in long input
> > lines * FIX large integers in iteration spec could cause overflow end
> > condition check * FIX object fillcolors should be consistent with the
> > color of current linetypes * FIX LFS support on 64bit platforms (not
> > backported for 32bit platforms) * FIX timecolumn() applied to non-axis
> > data reports an error rather than faulting
> > * FIX clipping could fail on integer overflow
> > * FIX segfault resulting from strcol(N) applied to empty field in a *.csv
> > file * FIX adjustment of key size to accommodate long key title
> > * FIX treat data value read as "NaN" the same as we would
> > "1/0"
> > * FIX handling of events triggered by closing the qt plot window
> > * FIX iteration failure due to integer overflow
> > * FIX clip r axis tics to current plot boundary
> > * FIX logscale cb axis with volatile data
> > 
> >     Ethan
> 
> Do you really make package of gnuplot-4.6.6?
> If it will be upload on the web, I can prepare windows and Cygwin binaries
> both for 32 and 64 bit.

I have shown the NEWS file from the 4.6 CVS repository.
Each PATCHLEVEL release is basically a snapshot of the repository.
4.6.5 was a snapshot from February 2014.
Some time later this year we will take another snapshot and this will
be release 4.6.6.   It will contain the changes listed above and any
other changes made between now and the tie of release.

	Ethan


> Tatsuro

Re: gnuplot 4.8?

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: sfeam 
> To: gnuplot-beta
> Cc: Allin Cottrell 
> Date: 2014/6/30, Mon 05:16
> Subject: Re: gnuplot 4.8?
> 
> On Sunday, June 29, 2014 03:44:23 PM Allin Cottrell wrote:
>>  I understand that 5.0 is supposed to be the release where the
>>  gnuplot developers are free to make some backward-incompatible
>>  changes. I've no problem with that, but I wonder if there's any
>>  thought to produce a gnuplot 4.8?
> 
> The 4.6 development source is a separate branch in CVS.
> The 4.7 (later 5.0) branch split off from it and gradually diverged.
> Most bugfixes have been applied to both branches, but they have 
> diverged enough that in some cases the "fix" for a problem in 4.6
> is limited to the existence of a better implementation in 5.0.
> 
> There will be at least one more patchlevel release 4.6.6.
> My crystal ball does not tell me at what rate fixable bugs will continue
> to be reported againt 4.6 as opposed to 5.0.  Other incremental
> releases could eventually appear, but I don't see a good rationale for
> starting a 4.8  series.   If a fix/change is compatible then it could go into
> 4.6; if not then it belongs in 5.0. 
> 
> A brief listing of changes accumulated since the last release is
> kept at the top of the NEWS files:
> 
> NEWS
> New features, changes and fixes in gnuplot version 4.6.6
> ========================================================
> 
> * NEW linetype keyword "nodraw" can be used to draw only the points in 
> "with lp"
> * NEW plot option to "skip N" lines at start of an ascii data file
> * NEW 'set fit prescale' normalized fit parameters before M-L refinement
> * NEW update svg terminal to grey out the key entry when a plot is toggled off
> * CHANGE Accept "with image pixels" as a synonym for "with image 
> failsafe"
> * CHANGE return NaN if a requested numerical data value fins a string instead
> * CHANGE Consume only one space following the font name in an enhanced test 
> string
> * FIX Faster recovery from outboard server gnuplot_qt being killed
> * FIX get rid of O(N^2) memory allocation for string data in long input lines
> * FIX large integers in iteration spec could cause overflow end condition check
> * FIX object fillcolors should be consistent with the color of current linetypes
> * FIX LFS support on 64bit platforms (not backported for 32bit platforms)
> * FIX timecolumn() applied to non-axis data reports an error rather than 
> faulting
> * FIX clipping could fail on integer overflow
> * FIX segfault resulting from strcol(N) applied to empty field in a *.csv file
> * FIX adjustment of key size to accommodate long key title
> * FIX treat data value read as "NaN" the same as we would 
> "1/0"
> * FIX handling of events triggered by closing the qt plot window
> * FIX iteration failure due to integer overflow
> * FIX clip r axis tics to current plot boundary
> * FIX logscale cb axis with volatile data
> 
>     Ethan


Do you really make package of gnuplot-4.6.6?
If it will be upload on the web, I can prepare windows and Cygwin binaries both for 32 and 64 bit.

Tatsuro

Re: gnuplot 4.6.5 for 64-bit Windows?

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
> From: Allin Cottrell 
> To: Tatsuro MATSUOKA 
> Cc: gnuplot-bet
> Date: 2014/6/29, Sun 23:05
> Subject: Re: gnuplot 4.6.5 for 64-bit Windows?
> 
> On Fri, 27 Jun 2014, Tatsuro MATSUOKA wrote:
> 
>>  ----- Original Message -----
>> 
>>>  From: Allin Cottrell
>>>  To: Tatsuro MATSUOKA 
>>>  Cc: gnuplot-beta
>>>  Date: 2014/6/26, Thu 22:18
>>>  Subject: Re: gnuplot 4.6.5 for 64-bit Windows?
>>> 
>>>  On Thu, 26 Jun 2014, Tatsuro MATSUOKA wrote:
>>> 
>>>>   ----- Original Message -----
>>>> 
>>>>>   From: Allin Cottrell
>>>>>   To: gnuplot-beta
>>>>>   Cc: Date: 2014/6/26, Thu 08:20
>>>>>   Subject: gnuplot 4.6.5 for 64-bit Windows?
>>>>> 
>>>>>   I wonder if anyone has managed to build wgnuplot.exe of 
> gnuplot 4.6.5 
>>>  for 64-bit Windows, and if so, what the "trick" is?
>>>>> 
>>>>>   I tried back-porting my patch for gnuplot CVS to 4.6.5 and it 
> built 
>>>  without error (I should say, this is cross-building on Linux using 
> mingw, which has worked fine for CVS gnuplot), but the binary behaves strangely. 
> In batch mode -- give it a script and ask it to produce a plot file -- it works 
> fine. But in interactive mode this is what I'm seeing (on 64-bit Windows 8):
>>>>> 
>>>>>   * If invoked as wgnuplot.exe without any arguments it opens 
> fleetingly 
>>>  and then immediately exits.
>>>>> 
>>>>>   * If invoked with the argument "-" (which, BTW, I 
> don't 
>>>  see documented anywhere, maybe my bad?), as in
>>>>> 
>>>>>   wgnuplot.exe -
>>>>> 
>>>>>   it stays open but behaves oddly: the overall GUI looks OK, the 
> menus 
>>>  work, but there's no prompt and while you can type stuff, nothing 
> appears in the "console" or text area.
>>>>> 
>>>>>   It took me a while to figure out that typed commands do 
> actually work: 
>>>  if, for example you type, blindly, "plot sin(x)<Enter>" 
> you get a perfectly good plot of sin(x).
>>>>> 
>>>>>   Anyway, any notions of how to put this to rights? Thanks.
>>>> 
>>>> 
>>>>   Is there any reason why you will back to 4.6.5 for 64bit?
>>> 
>>>  Yes: there are some backward-incompatible changes in current 
> CVS/gnuplot 5.0 and I wanted to build the latest-and-greatest on the 4.6 branch.
>>> 
>>>>   I have built 64bit binay using cvs source on native windows 7 
> 64bit and 
>>>  upload on my web.
>>> 
>>>  I too have built CVS gnuplot successfully for win64.
>>> 
>>>>   For 4.6, the patch is needed for 64 bit build for windows. Is the 
> patch 
>>>  shown the below enough for 64bit build of 4.6.5? 
> http://gnuplot.10905.n7.nabble.com/gnuplot-on-64-bit-Windows-again-td17580.html
>>> 
>>>  Yep, that's my message/patch! It's what I applied to the 4.6.5 
> source. It enabled me to build the program without any errors from the compiler, 
> but as I said it doesn't run properly.
>> 
>>  Thank you for the information. 
>> 
>>  I applied the patch and successfully built gnuplot 4.6.5 using MinGW-w64 
> (4.8.3)
>>  (+ msys) on windows 7 64bit
>> 
>>  I executed the wgnuplot from command line.
>>  It seemed work without problem.
>> 
>>  See
>>  http://www.geocities.jp/tmgpltwin/Files/Files.html#0062
>>  20140627wgp465.png
>> 
>> 
>>  wnguplot started up without '-'. And messages were represented 
> normally.
>>  In addition, echo backs to key stokes worked without problem. 
> 
> Thanks, then there must be something wrong with my build process, or in my 
> application of the 64-bit patch.
> 
> Allin Cottrell


http://www.tatsuromatsuoka.com/gnuplot/Eng/gp46/gp465_64.zip 

(Sorry the previous mail http:// is mistyped as http;//)

Did you try that the above worked on your windows PC?

Tatsuro

Re: gnuplot 4.8?

[sfeam <sf...@us...>]

On Sunday, June 29, 2014 03:44:23 PM Allin Cottrell wrote:
> I understand that 5.0 is supposed to be the release where the
> gnuplot developers are free to make some backward-incompatible
> changes. I've no problem with that, but I wonder if there's any
> thought to produce a gnuplot 4.8?

The 4.6 development source is a separate branch in CVS.
The 4.7 (later 5.0) branch split off from it and gradually diverged.
Most bugfixes have been applied to both branches, but they have 
diverged enough that in some cases the "fix" for a problem in 4.6
is limited to the existence of a better implementation in 5.0.

There will be at least one more patchlevel release 4.6.6.
My crystal ball does not tell me at what rate fixable bugs will continue
to be reported againt 4.6 as opposed to 5.0.  Other incremental
releases could eventually appear, but I don't see a good rationale for
starting a 4.8  series.   If a fix/change is compatible then it could go into
4.6; if not then it belongs in 5.0. 

A brief listing of changes accumulated since the last release is
kept at the top of the NEWS files:

NEWS
New features, changes and fixes in gnuplot version 4.6.6
========================================================

* NEW linetype keyword "nodraw" can be used to draw only the points in "with lp"
* NEW plot option to "skip N" lines at start of an ascii data file
* NEW 'set fit prescale' normalized fit parameters before M-L refinement
* NEW update svg terminal to grey out the key entry when a plot is toggled off
* CHANGE Accept "with image pixels" as a synonym for "with image failsafe"
* CHANGE return NaN if a requested numerical data value fins a string instead
* CHANGE Consume only one space following the font name in an enhanced test string
* FIX Faster recovery from outboard server gnuplot_qt being killed
* FIX get rid of O(N^2) memory allocation for string data in long input lines
* FIX large integers in iteration spec could cause overflow end condition check
* FIX object fillcolors should be consistent with the color of current linetypes
* FIX LFS support on 64bit platforms (not backported for 32bit platforms)
* FIX timecolumn() applied to non-axis data reports an error rather than faulting
* FIX clipping could fail on integer overflow
* FIX segfault resulting from strcol(N) applied to empty field in a *.csv file
* FIX adjustment of key size to accommodate long key title
* FIX treat data value read as "NaN" the same as we would "1/0"
* FIX handling of events triggered by closing the qt plot window
* FIX iteration failure due to integer overflow
* FIX clip r axis tics to current plot boundary
* FIX logscale cb axis with volatile data
 
	Ethan


> I get the impression -- admittedly, without studying the code base
> in detail -- that CVS gnuplot has accumulated a number of helpful
> fixes along with some nice new options. My notion of a possible 4.8
> is basically 5.0 with the backward-incompatible elements reverted. I
> guess it would be trivial to revert some things (the default color
> scheme, the default for text in respect of enhanced versus
> non-enhanced) but maybe less trivial to revert others.

> Anyway, just wondering. The "use case" is that some of us who employ
> gnuplot as ancillary to data-analysis software would find it very
> nice to have a version that's both backward-compatible -- the
> important thing here is that scripts designed for 4.4 and 4.6 will
> still work -- and up-to-date with all bug-fixes, and buildable for
> win64 out of the box.

gnuplot 4.8?

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

I understand that 5.0 is supposed to be the release where the 
gnuplot developers are free to make some backward-incompatible 
changes. I've no problem with that, but I wonder if there's any 
thought to produce a gnuplot 4.8?

I get the impression -- admittedly, without studying the code base 
in detail -- that CVS gnuplot has accumulated a number of helpful 
fixes along with some nice new options. My notion of a possible 4.8 
is basically 5.0 with the backward-incompatible elements reverted. I 
guess it would be trivial to revert some things (the default color 
scheme, the default for text in respect of enhanced versus 
non-enhanced) but maybe less trivial to revert others.

Anyway, just wondering. The "use case" is that some of us who employ 
gnuplot as ancillary to data-analysis software would find it very 
nice to have a version that's both backward-compatible -- the 
important thing here is that scripts designed for 4.4 and 4.6 will 
still work -- and up-to-date with all bug-fixes, and buildable for 
win64 out of the box.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: terminal quirks, wxt vs qt

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

On Thu, 26 Jun 2014, sfeam wrote:

> On Thursday, 26 June 2014 01:02:29 PM Allin Cottrell wrote:
>> Playing with 5.0-rc1 on Linux, I noticed an asymmetry with the wxt and qt
>> terminals. Say you want to open a 3-D plot file and rotate the image
>> interactively. With term = wxt it's enough to do
>>
>> gnuplot 3dfile -persist
>>
>> but with term = qt (using qt 4, at any rate) you don't get interaction,
>> that requires a controlling terminal window, as in
>>
>> xterm -e gnuplot gp3d.plt -
>>
>> Sorry if I'm just repeating something well known, but this difference is
>> relevant if gnuplot is being launched by a third-party program; it's much
>> more elegant not to have to open a parent terminal window.
>
> The difference is more profound than you describe.
>
> "persist" mode does not support 3D rotation, because gnuplot itself does
> not support true 3D rotation.  It draws successive 2D projections in
> response to mouse feedback requesting that the figure be redrawn at an
> incrementally different viewing angle.  The point is that the "rotation"
> is really a series of "replot" commands and as such can only be performed
> while gnuplot is still running, not after it has exited.
>
> What is misleading you is that the wxt does not really have a true
> "persist" mode (nor does the Windows terminal).  Instead it interprets
> "persist"  as "don't really exit until the plot window is closed".
>
> Terminals that have a true persist mode allow you do continue interactions
> with the plot window after gnuplot has exited.
>
> Anyhow, you can get the same behaviour from the qt or x11 terminals,
> but not by using "persist".  Use something like "pause mouse close" instead.
>
> I am open to suggestions about whether the -persist option itself
> should be re-implemented to mean exactly this.  There are downsides as
> well, as this causes a proliferation of gnuplot processes if you create
> multiple display windows.

Thanks for the explanation. I never knew you could do that with the x11 
terminal. With the qt term I'm seeing different behavior in gnuplot 4.6.5 
versus the 5.0 rc. In 5.0 it works very nicely with "pause mouse close", 
but in 4.6.5 it's a bit odd: I can't "ungrab" the image -- that is, any 
mouse motion rotates the image, regardless of buttons pressed or not -- 
and then closing the plot window doesn't cause gnuplot to exit.

Allin Cottrell

Re: gnuplot 4.6.5 for 64-bit Windows?

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

On Fri, 27 Jun 2014, Tatsuro MATSUOKA wrote:

> ----- Original Message -----
>
>> From: Allin Cottrell
>> To: Tatsuro MATSUOKA 
>> Cc: gnuplot-beta
>> Date: 2014/6/26, Thu 22:18
>> Subject: Re: gnuplot 4.6.5 for 64-bit Windows?
>> 
>> On Thu, 26 Jun 2014, Tatsuro MATSUOKA wrote:
>>
>>>  ----- Original Message -----
>>>
>>>>  From: Allin Cottrell
>>>>  To: gnuplot-beta
>>>>  Cc: Date: 2014/6/26, Thu 08:20
>>>>  Subject: gnuplot 4.6.5 for 64-bit Windows?
>>>>
>>>>  I wonder if anyone has managed to build wgnuplot.exe of gnuplot 4.6.5 
>> for 64-bit Windows, and if so, what the "trick" is?
>>>>
>>>>  I tried back-porting my patch for gnuplot CVS to 4.6.5 and it built 
>> without error (I should say, this is cross-building on Linux using mingw, which 
>> has worked fine for CVS gnuplot), but the binary behaves strangely. In batch 
>> mode -- give it a script and ask it to produce a plot file -- it works fine. But 
>> in interactive mode this is what I'm seeing (on 64-bit Windows 8):
>>>>
>>>>  * If invoked as wgnuplot.exe without any arguments it opens fleetingly 
>> and then immediately exits.
>>>>
>>>>  * If invoked with the argument "-" (which, BTW, I don't 
>> see documented anywhere, maybe my bad?), as in
>>>>
>>>>  wgnuplot.exe -
>>>>
>>>>  it stays open but behaves oddly: the overall GUI looks OK, the menus 
>> work, but there's no prompt and while you can type stuff, nothing appears in 
>> the "console" or text area.
>>>>
>>>>  It took me a while to figure out that typed commands do actually work: 
>> if, for example you type, blindly, "plot sin(x)<Enter>" you get 
>> a perfectly good plot of sin(x).
>>>>
>>>>  Anyway, any notions of how to put this to rights? Thanks.
>>> 
>>>
>>>  Is there any reason why you will back to 4.6.5 for 64bit?
>> 
>> Yes: there are some backward-incompatible changes in current CVS/gnuplot 5.0 and 
>> I wanted to build the latest-and-greatest on the 4.6 branch.
>>
>>>  I have built 64bit binay using cvs source on native windows 7 64bit and 
>> upload on my web.
>> 
>> I too have built CVS gnuplot successfully for win64.
>>
>>>  For 4.6, the patch is needed for 64 bit build for windows. Is the patch 
>> shown the below enough for 64bit build of 4.6.5? 
>> http://gnuplot.10905.n7.nabble.com/gnuplot-on-64-bit-Windows-again-td17580.html
>> 
>> Yep, that's my message/patch! It's what I applied to the 4.6.5 source. 
>> It enabled me to build the program without any errors from the compiler, but as 
>> I said it doesn't run properly.
>
> Thank you for the information. 
>
> I applied the patch and successfully built gnuplot 4.6.5 using MinGW-w64 (4.8.3)
> (+ msys) on windows 7 64bit
>
> I executed the wgnuplot from command line.
> It seemed work without problem.
>
> See
> http://www.geocities.jp/tmgpltwin/Files/Files.html#0062
> 20140627wgp465.png
>
>
> wnguplot started up without '-'. And messages were represented normally.
> In addition, echo backs to key stokes worked without problem. 

Thanks, then there must be something wrong with my build process, or in my 
application of the 64-bit patch.

Allin Cottrell

Re: gnuplot 4.6.5 for 64-bit Windows?

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Allin Cottrell
> To: Tatsuro MATSUOKA 
> Cc: gnuplot-beta
> Date: 2014/6/26, Thu 22:18
> Subject: Re: gnuplot 4.6.5 for 64-bit Windows?
> 
> On Thu, 26 Jun 2014, Tatsuro MATSUOKA wrote:
> 
>>  ----- Original Message -----
>> 
>>>  From: Allin Cottrell
>>>  To: gnuplot-beta
>>>  Cc: Date: 2014/6/26, Thu 08:20
>>>  Subject: gnuplot 4.6.5 for 64-bit Windows?
>>> 
>>>  I wonder if anyone has managed to build wgnuplot.exe of gnuplot 4.6.5 
> for 64-bit Windows, and if so, what the "trick" is?
>>> 
>>>  I tried back-porting my patch for gnuplot CVS to 4.6.5 and it built 
> without error (I should say, this is cross-building on Linux using mingw, which 
> has worked fine for CVS gnuplot), but the binary behaves strangely. In batch 
> mode -- give it a script and ask it to produce a plot file -- it works fine. But 
> in interactive mode this is what I'm seeing (on 64-bit Windows 8):
>>> 
>>>  * If invoked as wgnuplot.exe without any arguments it opens fleetingly 
> and then immediately exits.
>>> 
>>>  * If invoked with the argument "-" (which, BTW, I don't 
> see documented anywhere, maybe my bad?), as in
>>> 
>>>  wgnuplot.exe -
>>> 
>>>  it stays open but behaves oddly: the overall GUI looks OK, the menus 
> work, but there's no prompt and while you can type stuff, nothing appears in 
> the "console" or text area.
>>> 
>>>  It took me a while to figure out that typed commands do actually work: 
> if, for example you type, blindly, "plot sin(x)<Enter>" you get 
> a perfectly good plot of sin(x).
>>> 
>>>  Anyway, any notions of how to put this to rights? Thanks.
>> 
>> 
>>  Is there any reason why you will back to 4.6.5 for 64bit?
> 
> Yes: there are some backward-incompatible changes in current CVS/gnuplot 5.0 and 
> I wanted to build the latest-and-greatest on the 4.6 branch.
> 
>>  I have built 64bit binay using cvs source on native windows 7 64bit and 
> upload on my web.
> 
> I too have built CVS gnuplot successfully for win64.
> 
>>  For 4.6, the patch is needed for 64 bit build for windows. Is the patch 
> shown the below enough for 64bit build of 4.6.5? 
> http://gnuplot.10905.n7.nabble.com/gnuplot-on-64-bit-Windows-again-td17580.html
> 
> Yep, that's my message/patch! It's what I applied to the 4.6.5 source. 
> It enabled me to build the program without any errors from the compiler, but as 
> I said it doesn't run properly.

Thank you for the information. 

I applied the patch and successfully built gnuplot 4.6.5 using MinGW-w64 (4.8.3)
(+ msys) on windows 7 64bit

I executed the wgnuplot from command line.
It seemed work without problem.

See
http://www.geocities.jp/tmgpltwin/Files/Files.html#0062
20140627wgp465.png


wnguplot started up without '-'. And messages were represented normally.
In addition, echo backs to key stokes worked without problem. 

For me 64 bit gnuplot works fine.

My binary is able to get from

http;//www.tatsuromatsuoka.com/gnuplot/Eng/gp46/gp465_64.zip


Tatsuro

Re: terminal quirks, wxt vs qt

[sfeam <sf...@us...>]

On Thursday, 26 June 2014 01:02:29 PM Allin Cottrell wrote:
> Playing with 5.0-rc1 on Linux, I noticed an asymmetry with the wxt and qt 
> terminals. Say you want to open a 3-D plot file and rotate the image 
> interactively. With term = wxt it's enough to do
> 
> gnuplot 3dfile -persist
> 
> but with term = qt (using qt 4, at any rate) you don't get interaction, 
> that requires a controlling terminal window, as in
> 
> xterm -e gnuplot gp3d.plt -
> 
> Sorry if I'm just repeating something well known, but this difference is 
> relevant if gnuplot is being launched by a third-party program; it's much 
> more elegant not to have to open a parent terminal window.

The difference is more profound than you describe.

"persist" mode does not support 3D rotation, because gnuplot itself does
not support true 3D rotation.  It draws successive 2D projections in 
response to mouse feedback requesting that the figure be redrawn at an
incrementally different viewing angle.  The point is that the "rotation"
is really a series of "replot" commands and as such can only be performed
while gnuplot is still running, not after it has exited.

What is misleading you is that the wxt does not really have a true 
"persist" mode (nor does the Windows terminal).  Instead it interprets
"persist"  as "don't really exit until the plot window is closed".

Terminals that have a true persist mode allow you do continue interactions
with the plot window after gnuplot has exited.  

Anyhow, you can get the same behaviour from the qt or x11 terminals,
but not by using "persist".  Use something like "pause mouse close" instead.

I am open to suggestions about whether the -persist option itself
should be re-implemented to mean exactly this.  There are downsides as
well, as this causes a proliferation of gnuplot processes if you create
multiple display windows.

	Ethan

terminal quirks, wxt vs qt

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

Playing with 5.0-rc1 on Linux, I noticed an asymmetry with the wxt and qt 
terminals. Say you want to open a 3-D plot file and rotate the image 
interactively. With term = wxt it's enough to do

gnuplot 3dfile -persist

but with term = qt (using qt 4, at any rate) you don't get interaction, 
that requires a controlling terminal window, as in

xterm -e gnuplot gp3d.plt -

Sorry if I'm just repeating something well known, but this difference is 
relevant if gnuplot is being launched by a third-party program; it's much 
more elegant not to have to open a parent terminal window.

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

Re: gnuplot 4.6.5 for 64-bit Windows?

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

On Thu, 26 Jun 2014, Tatsuro MATSUOKA wrote:

> ----- Original Message -----
>
>> From: Allin Cottrell
>> To: gnuplot-beta
>> Cc: 
>> Date: 2014/6/26, Thu 08:20
>> Subject: gnuplot 4.6.5 for 64-bit Windows?
>> 
>> I wonder if anyone has managed to build wgnuplot.exe of gnuplot 
>> 4.6.5 for 64-bit Windows, and if so, what the "trick" is?
>> 
>> I tried back-porting my patch for gnuplot CVS to 4.6.5 and it built 
>> without error (I should say, this is cross-building on Linux using 
>> mingw, which has worked fine for CVS gnuplot), but the binary 
>> behaves strangely. In batch mode -- give it a script and ask it to 
>> produce a plot file -- it works fine. But in interactive mode this 
>> is what I'm seeing (on 64-bit Windows 8):
>> 
>> * If invoked as wgnuplot.exe without any arguments it opens 
>> fleetingly and then immediately exits.
>> 
>> * If invoked with the argument "-" (which, BTW, I don't see 
>> documented anywhere, maybe my bad?), as in
>> 
>> wgnuplot.exe -
>> 
>> it stays open but behaves oddly: the overall GUI looks OK, the menus 
>> work, but there's no prompt and while you can type stuff, nothing 
>> appears in the "console" or text area.
>> 
>> It took me a while to figure out that typed commands do actually 
>> work: if, for example you type, blindly, "plot sin(x)<Enter>" 
>> you 
>> get a perfectly good plot of sin(x).
>> 
>> Anyway, any notions of how to put this to rights? Thanks.
>
>
> Is there any reason why you will back to 4.6.5 for 64bit?

Yes: there are some backward-incompatible changes in current CVS/gnuplot 
5.0 and I wanted to build the latest-and-greatest on the 4.6 branch.

> I have built 64bit binay using cvs source on native windows 7 64bit and 
> upload on my web.

I too have built CVS gnuplot successfully for win64.

> For 4.6, the patch is needed for 64 bit build for windows. Is the patch 
> shown the below enough for 64bit build of 4.6.5? 
> http://gnuplot.10905.n7.nabble.com/gnuplot-on-64-bit-Windows-again-td17580.html

Yep, that's my message/patch! It's what I applied to the 4.6.5 source. It 
enabled me to build the program without any errors from the compiler, but 
as I said it doesn't run properly.

Allin Cottrell

Re: gnuplot 4.6.5 for 64-bit Windows?

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Allin Cottrell
> To: gnuplot-beta
> Cc: 
> Date: 2014/6/26, Thu 08:20
> Subject: gnuplot 4.6.5 for 64-bit Windows?
> 
> I wonder if anyone has managed to build wgnuplot.exe of gnuplot 
> 4.6.5 for 64-bit Windows, and if so, what the "trick" is?
> 
> I tried back-porting my patch for gnuplot CVS to 4.6.5 and it built 
> without error (I should say, this is cross-building on Linux using 
> mingw, which has worked fine for CVS gnuplot), but the binary 
> behaves strangely. In batch mode -- give it a script and ask it to 
> produce a plot file -- it works fine. But in interactive mode this 
> is what I'm seeing (on 64-bit Windows 8):
> 
> * If invoked as wgnuplot.exe without any arguments it opens 
> fleetingly and then immediately exits.
> 
> * If invoked with the argument "-" (which, BTW, I don't see 
> documented anywhere, maybe my bad?), as in
> 
> wgnuplot.exe -
> 
> it stays open but behaves oddly: the overall GUI looks OK, the menus 
> work, but there's no prompt and while you can type stuff, nothing 
> appears in the "console" or text area.
> 
> It took me a while to figure out that typed commands do actually 
> work: if, for example you type, blindly, "plot sin(x)<Enter>" 
> you 
> get a perfectly good plot of sin(x).
> 
> Anyway, any notions of how to put this to rights? Thanks.
> 


Is there any reason why you will back to 4.6.5 for 64bit?

I have built 64bit binay using cvs source on native windows 7 64bit and upload on my web.
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/



The flaw you mentioned does not appear for wgnuplot for cvs version (5.0rc-1).

For 4.6, the patch is needed for 64 bit build for windows.
Is the patch shown the below enough for 64bit build of 4.6.5?
http://gnuplot.10905.n7.nabble.com/gnuplot-on-64-bit-Windows-again-td17580.html


I will try to build if I will find time.

Please wait a while.

Tatsuro 

gnuplot 4.6.5 for 64-bit Windows?

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

I wonder if anyone has managed to build wgnuplot.exe of gnuplot 
4.6.5 for 64-bit Windows, and if so, what the "trick" is?

I tried back-porting my patch for gnuplot CVS to 4.6.5 and it built 
without error (I should say, this is cross-building on Linux using 
mingw, which has worked fine for CVS gnuplot), but the binary 
behaves strangely. In batch mode -- give it a script and ask it to 
produce a plot file -- it works fine. But in interactive mode this 
is what I'm seeing (on 64-bit Windows 8):

* If invoked as wgnuplot.exe without any arguments it opens 
fleetingly and then immediately exits.

* If invoked with the argument "-" (which, BTW, I don't see 
documented anywhere, maybe my bad?), as in

wgnuplot.exe -

it stays open but behaves oddly: the overall GUI looks OK, the menus 
work, but there's no prompt and while you can type stuff, nothing 
appears in the "console" or text area.

It took me a while to figure out that typed commands do actually 
work: if, for example you type, blindly, "plot sin(x)<Enter>" you 
get a perfectly good plot of sin(x).

Anyway, any notions of how to put this to rights? Thanks.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: How to get key information from qt terminal to gnuplot

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Petr Mikulik 
> To: Tatsuro MATSUOKA 
> Cc: Merritt Ethan ; gnuplot-beta
> Date: 2014/6/25, Wed 17:43
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
>>  I have a look into this issue a little deeper.
>>  Currently terminal raise and lower commands are treated in command.c
>> 
>>  The treatment for OS2, X11, Windows and WXWIDGETS is managed in
>> 
>>  void
>>  raise_lower_command(int lower)
>> 
>>  I do know the reason why but those are written in command.c but not 
> mouse.c.
> 
> Because these are gnuplot command line commands:
>     gnuplot> raise
>     gnuplot> lower
> 
> to raise/lower the terminal window (not the console window).


Thanks! I completely misled the situation.

I checked this feature for the qt on windows and it did not work as expected.
This feature is better to be implemented for qt terminal.

Tatsuro

Re: How to get key information from qt terminal to gnuplot

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

> I have a look into this issue a little deeper.
> Currently terminal raise and lower commands are treated in command.c
>
> The treatment for OS2, X11, Windows and WXWIDGETS is managed in
>
> void
> raise_lower_command(int lower)
>
> I do know the reason why but those are written in command.c but not mouse.c.

Because these are gnuplot command line commands:
 	gnuplot> raise
 	gnuplot> lower

to raise/lower the terminal window (not the console window).

---
Petr

Re: How to get key information from qt terminal to gnuplot

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Ethan A Merritt 
> To: gnuplot-beta; Tatsuro MATSUOKA 
> Cc: 
> Date: 2014/6/24, Tue 04:55
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
> On Tuesday, 24 June, 2014 04:49:36 Tatsuro MATSUOKA wrote:
>> 
>>  ----- Original Message -----
>>  > From: sfeam 
>>  > To: gnuplot-beta
>>  > Cc: Petr Mikulik 
>>  > Date: 2014/6/23, Mon 14:52
>>  > Subject: Re: How to get key information from qt terminal to gnuplot
>>  > 
>>  Although Ethan's idea is attractive, I will try console raise feature 
> for qt terminal by Petr's way at this moment.
>>  To implement Ethan's idea, we have to have wrapper function to get 
> keycode.
>>  This is because each terminal implements the way to get keycode diffident 
> way and keycode map for each the terminal is different (especially of windows).
>> 
>>  I will wait that someone who has good knowledge inter platform try to 
> implement.
> 
> Isn't it true that all terminals already do the necessary key-code
> processing so that they can send key events to the core code in mouse.c?
> 
> For example, does  "mouselabels.dem" work on MSWin?   That demo reads
> keystrokes in the plot window, turns them into labels in the core code, and then
> replots with the new label.   If the demo works, it shows that keycodes 
> including
> the space-key are correctly transmitted to the core code.


I have a look into this issue a little deeper.
Currently terminal raise and lower commands are treated in command.c

The treatment for OS2, X11, Windows and WXWIDGETS is managed in

void
raise_lower_command(int lower)

I do know the reason why but those are written in command.c but not mouse.c.


Tatsuro

Re: How to get key information from qt terminal to gnuplot

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Jérôme Lodewyck 
> To: Tatsuro MATSUOKA ; gnuplot-beta
> Cc: 
> Date: 2014/6/24, Tue 18:42
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
> Hi,
> 
>     I did not really follow what you want to achieve, but the error message 
> tells that you have to specify on which widget you want to set the focus 
> policy. If you want to set the policy of the QtGnuplotWidget containing 
> the scene, you might try
> 
> m_widget->setFocusPolicy( Qt::NoFocus);

Jérôme

Thank you for the reply!!

I have executed mouselabels demo on qt terminal on Ubuntu 12.04 LTS. 
It partially work. Key input reflected in the plot window. 
However, <del>, <bs> and <esc> work but <tab> does not work. 

For the above fact, Ethan show the thread concering tab key

http://stackoverflow.com/questions/18160051/intercepting-tab-key-press-to-manage-focus-switching-manually

The first answer for the question says that :

Using setFocusPolicy( Qt::NoFocus) property of QWidget, one can set Focus policy on widget which doesn't require tab focus. I thought that I could get tab code using setFocusPolicy( Qt::NoFocus).

Using 
m_widget->setFocusPolicy( Qt::NoFocus);
instead of 
QWidget::setFocusPolicy( Qt::NoFocus);

I could complie QtGnuplotWidget.cpp and got gnuplot_qt.

However, tab key feature does not work on mouselabels demo (demo/mouselabels.dem) on qt term.
Perhaps I have misled the answer of the question.

If you have an idea to tab key to work on the plot window in qt terminal please show the way.

Tatsuro

Re: How to get key information from qt terminal to gnuplot

[Jérôme L. <lod...@us...>]

Hi,

	I did not really follow what you want to achieve, but the error message 
tells that you have to specify on which widget you want to set the focus 
policy. If you want to set the policy of the QtGnuplotWidget containing 
the scene, you might try

m_widget->setFocusPolicy( Qt::NoFocus);

Jérôme


Le 24/06/2014 11:32, Tatsuro MATSUOKA a écrit :
> ----- Original Message -----
>
>> From: sfeam
>> To: gnuplot-beta Tatsuro MATSUOKA>
>> Date: 2014/6/24, Tue 13:12
>> Subject: Re: How to get key information from qt terminal to gnuplot
>>
>> On Tuesday, 24 June 2014 12:15:07 PM Tatsuro MATSUOKA wrote:
>>
>>>   > It partially work. Key input reflected in the plot window.
>>>   > However, <del>, <bs> and <esc> work but <tab>
>> does not
>>>   > work.
>>
>> The <tab> key is not normally available to Qt apps, with some exceptions
>> like text-entry widgets.  It is trapped by the Qt top layer and normally
>> interpreted as a request to switch focus to the next Qt widget.
>> I suppose this made sense when Qt was mostly being
>> used as a phone O/S but it's really annoying on the desktop.
>> The closest I could find to a clue how to work around this was this
>> thread:
>>
>> http://stackoverflow.com/questions/18160051/intercepting-tab-key-press-to-manage-focus-switching-manually
>>
>> I did not try to add this to gnuplot, however, so I don't
>> know whether it would work for us or not.
>>
>>      Ethan
>
> Thank you for the pointer.
>
> According to the first answer on the web page above, I added
>
>      QWidget::setFocusPolicy( Qt::NoFocus); //trial
> to the top of void QtGnuplotScene::keyPressEvent(QKeyEvent* event)
> in QtGnuplotWidget.cpp.
>
> I have met the error:
>
> QtGnuplotScene.cpp:881:38: error: cannot call member function 'void QWidget::setFocusPolicy(Qt::FocusPolicy)' without object
>
> I do not have enough knowldege for C++ so that I cannot understand what the error message means.
> I should make a mistake but I cannot find out what am I wrong.
>
> Sorry for my ignorance for this matter.
>
> Tatsuro
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: How to get key information from qt terminal to gnuplot

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: sfeam 
> To: gnuplot-beta Tatsuro MATSUOKA>
> Date: 2014/6/24, Tue 13:12
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
> On Tuesday, 24 June 2014 12:15:07 PM Tatsuro MATSUOKA wrote:
> 
>>  > It partially work. Key input reflected in the plot window.
>>  > However, <del>, <bs> and <esc> work but <tab> 
> does not 
>>  > work.
> 
> The <tab> key is not normally available to Qt apps, with some exceptions
> like text-entry widgets.  It is trapped by the Qt top layer and normally
> interpreted as a request to switch focus to the next Qt widget.
> I suppose this made sense when Qt was mostly being
> used as a phone O/S but it's really annoying on the desktop.
> The closest I could find to a clue how to work around this was this
> thread:
>   
> http://stackoverflow.com/questions/18160051/intercepting-tab-key-press-to-manage-focus-switching-manually
> 
> I did not try to add this to gnuplot, however, so I don't
> know whether it would work for us or not.
> 
>     Ethan

Thank you for the pointer.

According to the first answer on the web page above, I added

    QWidget::setFocusPolicy( Qt::NoFocus); //trial
to the top of void QtGnuplotScene::keyPressEvent(QKeyEvent* event) 
in QtGnuplotWidget.cpp.

I have met the error:

QtGnuplotScene.cpp:881:38: error: cannot call member function 'void QWidget::setFocusPolicy(Qt::FocusPolicy)' without object

I do not have enough knowldege for C++ so that I cannot understand what the error message means.
I should make a mistake but I cannot find out what am I wrong.

Sorry for my ignorance for this matter.

Tatsuro

Re: How to get key information from qt terminal to gnuplot

[sfeam <sf...@us...>]

On Tuesday, 24 June 2014 12:15:07 PM Tatsuro MATSUOKA wrote:

> > It partially work. Key input reflected in the plot window.
> > However, <del>, <bs> and <esc> work but <tab> does not 
> > work.

The <tab> key is not normally available to Qt apps, with some exceptions
like text-entry widgets.  It is trapped by the Qt top layer and normally
interpreted as a request to switch focus to the next Qt widget.
I suppose this made sense when Qt was mostly being
used as a phone O/S but it's really annoying on the desktop.
The closest I could find to a clue how to work around this was this
thread:
   http://stackoverflow.com/questions/18160051/intercepting-tab-key-press-to-manage-focus-switching-manually

I did not try to add this to gnuplot, however, so I don't
know whether it would work for us or not.

	Ethan


> > The qt terminal seems to have bug for key input handling but behave differently 
> > on windows and Linux.
> > 
> > Regards
> > 
> This is just information. 
> On plot window of qt term 0n windows, key command like "h", "p" is effective
> so that communication of qt terminal to gnuplot is effective.
> So it is strange why mouselabels demo does not work at all on the qt terminal on windows.
> 
> Tatsuro

Re: How to get key information from qt terminal to gnuplot

[Tatsuro M. <tma...@ya...>]

----- Original Message -----
> From: Tatsuro MATSUOKA
> To: tmacchant3Tait; gnuplot-beta
> Cc: 
> Date: 2014/6/24, Tue 08:43
> Subject: Re: How to get key information from qt terminal to gnuplot
> 
> ----- Original Message -----
> 
>>  From: Tatsuro MATSUOKA 
>>  To: Tait  gnuplot-beta> Cc: 
>>  Date: 2014/6/24, Tue 06:18
>>  Subject: Re: How to get key information from qt terminal to gnuplot
>>  ----- Original Message -----
>>>   From: Tait
>>>   To: gnuplot-bet
>>>   Cc: 
>>>   Date: 2014/6/24, Tue 05:32
>>>   Subject: Re: How to get key information from qt terminal to gnuplot
>>> 
>>>   Ethan A Merritt said (on 2014/06/23):
>>>>    Isn't it true that all terminals already do the necessary 
> key-code
>>>>    processing so that they can send key events to the core code in 
>>  mouse.c?
>>>> 
>>>>    For example, does  "mouselabels.dem" work on MSWin?   
> That 
>>  demo 
>>>   reads
>>>>    keystrokes in the plot window, turns them into labels in the core 
> 
>>  code, and 
>>>   then
>>>>    replots with the new label.   If the demo works, it shows that 
>>  keycodes 
>>>   including
>>>>    the space-key are correctly transmitted to the core code.
>>>> 
>>>>        Ethan
>>> 
>>>   The mouselabels demo does work* on Windows in wxt and windows terms,
>>>   although one cannot create a label containing a space (because the
>>>   space brings up the console) or q (it is ignored).
>>> 
>>>   * for some value of "works"... The Windows terminal tends to 
> eat
>>>   keystrokes unless they're typed much more slowly than a normal 
> typing
>>>   pace. The wxt terminal places the red text on top of the black, making
>>>   it impossible to read either, and sometimes (I haven't figured out 
> how
>>>   to replicate it on-demand) backspace doesn't work. Both seem to 
> add an
>>>   extra "\033" label after hitting ESC to end label input. 
> None 
>>  of 
>>>   the
>>>   Windows builds have a qt terminal to try.
>> 
>> 
>>  Tait is right.
>>  For qt on windows, mouselabels demo does not work.
>> 
>>  As the first work, I will try to mouselabels demo to wrok on qt for 
> windows.
>> 
>>  Tatsuro
> 
> 
> I misled the mouselabels demo, I have execute it on wxt and windows terminmal on 
> windows.
> That worked but echo back 'paused' to the command screen at each key 
> stoke.
> This is not a bug but it is annoying.
> 
> I have execute mouselabels demo on qt terminal on Ubuntu 12.04 LTS.
> 
> It partially work. Key input reflected in the plot window.
> However, <del>, <bs> and <esc> work but <tab> does not 
> work.
> 
> The qt terminal seems to have bug for key input handling but behave differently 
> on windows and Linux.
> 
> Regards
> 
This is just information. 
On plot window of qt term 0n windows, key command like "h", "p" is effective
so that communication of qt terminal to gnuplot is effective.
So it is strange why mouselabels demo does not work at all on the qt terminal on windows.

Tatsuro

Re: How to get key information from qt terminal to gnuplot

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: Tatsuro MATSUOKA 
> To: Tait  gnuplot-beta> Cc: 
> Date: 2014/6/24, Tue 06:18
> Subject: Re: How to get key information from qt terminal to gnuplot
> ----- Original Message -----
>>  From: Tait
>>  To: gnuplot-bet
>>  Cc: 
>>  Date: 2014/6/24, Tue 05:32
>>  Subject: Re: How to get key information from qt terminal to gnuplot
>> 
>>  Ethan A Merritt said (on 2014/06/23):
>>>   Isn't it true that all terminals already do the necessary key-code
>>>   processing so that they can send key events to the core code in 
> mouse.c?
>>> 
>>>   For example, does  "mouselabels.dem" work on MSWin?   That 
> demo 
>>  reads
>>>   keystrokes in the plot window, turns them into labels in the core 
> code, and 
>>  then
>>>   replots with the new label.   If the demo works, it shows that 
> keycodes 
>>  including
>>>   the space-key are correctly transmitted to the core code.
>>> 
>>>       Ethan
>> 
>>  The mouselabels demo does work* on Windows in wxt and windows terms,
>>  although one cannot create a label containing a space (because the
>>  space brings up the console) or q (it is ignored).
>> 
>>  * for some value of "works"... The Windows terminal tends to eat
>>  keystrokes unless they're typed much more slowly than a normal typing
>>  pace. The wxt terminal places the red text on top of the black, making
>>  it impossible to read either, and sometimes (I haven't figured out how
>>  to replicate it on-demand) backspace doesn't work. Both seem to add an
>>  extra "\033" label after hitting ESC to end label input. None 
> of 
>>  the
>>  Windows builds have a qt terminal to try.
> 
> 
> Tait is right.
> For qt on windows, mouselabels demo does not work.
> 
> As the first work, I will try to mouselabels demo to wrok on qt for windows.
> 
> Tatsuro


I misled the mouselabels demo, I have execute it on wxt and windows terminmal on windows.
That worked but echo back 'paused' to the command screen at each key stoke.
This is not a bug but it is annoying.

I have execute mouselabels demo on qt terminal on Ubuntu 12.04 LTS.

It partially work. Key input reflected in the plot window.
However, <del>, <bs> and <esc> work but <tab> does not work.

The qt terminal seems to have bug for key input handling but behave differently on windows and Linux.

Regards

Tatsuro

Re: Version 5: Dashes, Monochrome, Postscript

[Philipp K. J. <ja...@ie...>]

On Mon, 23 Jun 2014 15:05:20 -0700
Ethan A Merritt <merritt@u.washington.edu> wrote:

> On Monday, 23 June, 2014 15:01:16 Philipp K. Janert wrote:
> > On Mon, 23 Jun 2014 14:45:37 -0700
> > Ethan A Merritt <sf...@us...> wrote:
> > 
> > > On Monday, 23 June, 2014 14:20:48 Philipp K. Janert wrote:
> > > > On Mon, 23 Jun 2014 23:10:32 +0200
> > > > Christoph Bersch <us...@be...> wrote:
> > > > 
> > > > > Zitat von "Philipp K. Janert" <ja...@ie...>:
> > > > > >
> > > > > > Is there a way to turn on "dashed" plot styles
> > > > > > again, without having to individually set each
> > > > > > line separately?
> > > > > 
> > > > > You can use
> > > > > 
> > > > > set for [i=1:8] linetype i dashtype i
> > > > 
> > > > Thanks, that (mostly) works.
> > > 
> > > For now I recommend
> > >    load '.../share/colors_mono.gp'
> > 
> > Unfortunately, that breaks on gp5rc1 with the following 
> > message:
> > 
> > gnuplot> set linetype 4 lt 1 lw 2.5 lc rgb "black"
> >                         ^
> >          "Gnuplot-Workspace/gnuplot-5rc1/gnuplot-5.0.rc1/share/colors_mono.gp",
> > line 8: linetype definition cannot use linetype
> 
> Sigh. Yeah.  That got fixed later but missed the -rc1.
> The script as it currently exists in CVS is:
> 
> #
> # Provide a consistent set of four distinguishable
> # black line types.
> # NB: This does not work with "set term post mono"
> #
> unset for [i=1:8] linetype i
> set linetype 4 dt 1 lw 2 lc rgb "black"
> set linetype 3 dt 3 lw 1.5 lc rgb "black"
> set linetype 2 dt 2 lw 1.5 lc rgb "black"
> set linetype 1 dt solid lw 1 lc rgb "black"
> set linetype cycle 4
> #
> set palette gray
> 

Thanks - I'll check out the CVS version. 

Re: Version 5: Dashes, Monochrome, Postscript

[Ethan A M. <merritt@u.washington.edu>]

On Monday, 23 June, 2014 15:01:16 Philipp K. Janert wrote:
> On Mon, 23 Jun 2014 14:45:37 -0700
> Ethan A Merritt <sf...@us...> wrote:
> 
> > On Monday, 23 June, 2014 14:20:48 Philipp K. Janert wrote:
> > > On Mon, 23 Jun 2014 23:10:32 +0200
> > > Christoph Bersch <us...@be...> wrote:
> > > 
> > > > Zitat von "Philipp K. Janert" <ja...@ie...>:
> > > > >
> > > > > Is there a way to turn on "dashed" plot styles
> > > > > again, without having to individually set each
> > > > > line separately?
> > > > 
> > > > You can use
> > > > 
> > > > set for [i=1:8] linetype i dashtype i
> > > 
> > > Thanks, that (mostly) works.
> > 
> > For now I recommend
> >    load '.../share/colors_mono.gp'
> 
> Unfortunately, that breaks on gp5rc1 with the following 
> message:
> 
> gnuplot> set linetype 4 lt 1 lw 2.5 lc rgb "black"
>                         ^
>          "Gnuplot-Workspace/gnuplot-5rc1/gnuplot-5.0.rc1/share/colors_mono.gp",
> line 8: linetype definition cannot use linetype

Sigh. Yeah.  That got fixed later but missed the -rc1.
The script as it currently exists in CVS is:

#
# Provide a consistent set of four distinguishable
# black line types.
# NB: This does not work with "set term post mono"
#
unset for [i=1:8] linetype i
set linetype 4 dt 1 lw 2 lc rgb "black"
set linetype 3 dt 3 lw 1.5 lc rgb "black"
set linetype 2 dt 2 lw 1.5 lc rgb "black"
set linetype 1 dt solid lw 1 lc rgb "black"
set linetype cycle 4
#
set palette gray


	Ethan



> 
> > 
> > There was some discussion of building this in somehow
> > rather than requiring a separate "load" command.
> > One option is to add a "mono" option to the new
> > "set colors" command.
> 
> Building it in would be nice, although I find it
> acceptable having to "load" something - PROVIDED
> this really brings me back to the past gnuplot
> terminal behavior.
> 
> > 
> > The drawback there is possible confusion that the existing
> > options (default | podo | classic) affect _only_ color, whereas
> > "mono" would affect color and linewidth and dash pattern.
> > 
> > Also related:
> > 
> > There is a proposal to add a command that would set
> > a repeat cycle for dashtypes, so that patterns 1-N would
> > be repeated for linetypes N+1 - 2N and so on.
> > 
> > We currently have such a command for linetypes 
> > "set linetype cycle"
> > but not for point types or dash patterns.
> > 
> > > For some reason, solid black (lt 1) seems
> > > twice as thick in postscript output than
> > > the dashed lines. Should I expect that?
> > 
> > That is a known [unintended] problem. 
> > It's not obvious to me how to fix it, but I hope something will
> > be possible for -rc2.
> 
> Is there a bug report (or some context) you can
> point me to?
> 
> > 
> > > Also: there used to be a special line type 0
> > > (for grid lines, and such). Does that still 
> > > exist?
> > 
> > Yes. 
> > 
> 
> Thanks.
> 
> > 
> > 	Ethan
> > 
> > > Finally: To drop "solid|dashed" from terminal
> > > specifications is a MAJOR breakage of backwards
> > > compatibility. Should that not be made optional?
> > > (At the very least, it should be included in the
> > > list of "incompatible changes".)
> > > 
> > > > 
> > > > for this.
> > > > 
> > > > Christoph
> > 
> 
> 
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Version 5: Dashes, Monochrome, Postscript

[Philipp K. J. <ja...@ie...>]

On Mon, 23 Jun 2014 14:45:37 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Monday, 23 June, 2014 14:20:48 Philipp K. Janert wrote:
> > On Mon, 23 Jun 2014 23:10:32 +0200
> > Christoph Bersch <us...@be...> wrote:
> > 
> > > Zitat von "Philipp K. Janert" <ja...@ie...>:
> > > >
> > > > Is there a way to turn on "dashed" plot styles
> > > > again, without having to individually set each
> > > > line separately?
> > > 
> > > You can use
> > > 
> > > set for [i=1:8] linetype i dashtype i
> > 
> > Thanks, that (mostly) works.
> 
> For now I recommend
>    load '.../share/colors_mono.gp'

Unfortunately, that breaks on gp5rc1 with the following 
message:

gnuplot> set linetype 4 lt 1 lw 2.5 lc rgb "black"
                        ^
         "Gnuplot-Workspace/gnuplot-5rc1/gnuplot-5.0.rc1/share/colors_mono.gp",
line 8: linetype definition cannot use linetype

> 
> There was some discussion of building this in somehow
> rather than requiring a separate "load" command.
> One option is to add a "mono" option to the new
> "set colors" command.

Building it in would be nice, although I find it
acceptable having to "load" something - PROVIDED
this really brings me back to the past gnuplot
terminal behavior.

> 
> The drawback there is possible confusion that the existing
> options (default | podo | classic) affect _only_ color, whereas
> "mono" would affect color and linewidth and dash pattern.
> 
> Also related:
> 
> There is a proposal to add a command that would set
> a repeat cycle for dashtypes, so that patterns 1-N would
> be repeated for linetypes N+1 - 2N and so on.
> 
> We currently have such a command for linetypes 
> "set linetype cycle"
> but not for point types or dash patterns.
> 
> > For some reason, solid black (lt 1) seems
> > twice as thick in postscript output than
> > the dashed lines. Should I expect that?
> 
> That is a known [unintended] problem. 
> It's not obvious to me how to fix it, but I hope something will
> be possible for -rc2.

Is there a bug report (or some context) you can
point me to?

> 
> > Also: there used to be a special line type 0
> > (for grid lines, and such). Does that still 
> > exist?
> 
> Yes. 
> 

Thanks.

> 
> 	Ethan
> 
> > Finally: To drop "solid|dashed" from terminal
> > specifications is a MAJOR breakage of backwards
> > compatibility. Should that not be made optional?
> > (At the very least, it should be included in the
> > list of "incompatible changes".)
> > 
> > > 
> > > for this.
> > > 
> > > Christoph
>