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

Re: rewriting history

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

On 11/19/13 16:24, Petr Mikulik wrote:
> There is no option to switch "history" between "compact" and "full"
> recording. That could be probably added...
>
> ---
> Petr Mikulik

that would be nice and presumably pretty trivial to just stop it doing 
the compacting.


If anyone can point me at the relevant code I will have a poke.

thx, Peter.

Re: rewriting history

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

>>>because history is forever being revised and compacted

Oh yes, that was my first contribution to gnuplot! In 90's, long 
synchrotron experiments, and gnuplot history with one "plot ...",
one "set log y", one "set nolog" a 50x "replot".

>> For this to be of most use to me I would like to have (at least options
>> on ) recording verbatim command history and history display without
>> numbers, which would make copying to a runnable script file less laborious.

It's already there exactly for the purpose you mention:
 	history quiet
see "help history".

There is no option to switch "history" between "compact" and "full" recording. 
That could be probably added...

---
Petr Mikulik

Re: rewriting history

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

On 11/19/2013 04:01 AM, pl...@pi... wrote:

> For this to be of most use to me I would like to have (at least options
> on ) recording verbatim command history and history display without
> numbers, which would make copying to a runnable script file less laborious.
>
> m2c, Peter.

A quick search shows the history issue was around the 2005/2006 time 
frame, so it will take a while to jog my memory on that one.  But, yes, 
I think suppressing the number was part of the mods I proposed.  Also, 
avoiding the "his !his" recursion.

Dan

Re: rewriting history

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

On 11/19/13 09:17, Daniel J Sebald wrote:
> On 11/19/2013 01:03 AM, pl...@pi... wrote:
>> On 11/19/13 07:05, Daniel J Sebald wrote:
>>> On 11/18/2013 02:58 PM, pl...@pi... wrote:
>>>> Hi,
>>>>
>>>> is there was way to stop gnuplot compacting history?
>>>
>>> Do you mean that the current command is not repeated in history if it
>>> matches the previous most recent command in the history buffer?
>>>
>>> My history looks pretty lengthy, but I do seem to recall a limit. Also,
>>> given it isn't recent history I can't look through it and conclude that
>>> it is complete.
>>
>> yes, it's a feature that dupes are eliminated. Just try repeating your
>> last plot command a few times. Only the last occurrence will appear in
>> history.
>>
>> I've been pulling my hair trying to work out why a fit command is
>> producing different results. Having an accurate record of my command
>> history would be an immense help.
>>
>> I'm currently having to cut and paste every command into a text file as
>> I go along which is a serious PITA.
>
> That's sort of my modus operandi, except I edit in a file and either
> select and copy with the center mouse button or save and load the file.
>   History is nice for tweaking commands and trial-and-error, but
> anything more than five commands deep is tough to edit.  Nonetheless,
> history modifications might be worthwhile.
>
> Dan
>
>
>>
>> Peter.
>>
>>
>>
>>>
>>>
>>>> While I realise this is done to save storage space somewhere, this is a
>>>> constant annoyance.
>>>>
>>>> I have an annoying problem where something keeps changing and I need to
>>>> track exactly what is happening.
>>>>
>>>> In a shell I would use the history command to see _exactly_ what I did
>>>> and in what order to see what I have changed. I can see a true
>>>> record of
>>>> my commands and repeat various parts of it until I reproduce and
>>>> understand the error.
>>>>
>>>> with gnuplot this does not seem possible because history is forever
>>>> being revised and compacted and no longer retains a useful record. In
>>>> fact "history" does not provide the command history. It's more like
>>>> recent favourites, that often saves some typing but it is not the
>>>> command history.
>>>>
>>>> I'm not that tight for space that I need to economise a few K. I'd much
>>>> rather save the few hours it's going to take me to find this problem
>>>> without a proper record of the commands I've issued to make the problem
>>>> repeatable.
>>>>
>>>> Is there a means of preventing gnuplot from compacting the command
>>>> history be removing dupes?
>>>
>>> I recall some years ago writing a history patch that allowed it to be
>>> configured in a couple ways: one being complete history, one being more
>>> condensed. I might still have that around if you are interested, but
>>> I'd have to search for it and I'm sure it has conflicting hunks by now.
>>>
>>> Dan
>>>
>>
>>
>

For this to be of most use to me I would like to have (at least options 
on ) recording verbatim command history and history display without 
numbers, which would make copying to a runnable script file less laborious.

m2c, Peter.

Re: rewriting history

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

On 11/19/13 07:05, Daniel J Sebald wrote:
> On 11/18/2013 02:58 PM, pl...@pi... wrote:
>> Hi,
>>
>> is there was way to stop gnuplot compacting history?
>
> Do you mean that the current command is not repeated in history if it
> matches the previous most recent command in the history buffer?
>
> My history looks pretty lengthy, but I do seem to recall a limit.  Also,
> given it isn't recent history I can't look through it and conclude that
> it is complete.

yes, it's a feature that dupes are eliminated.  Just try repeating your 
last plot command a few times. Only the last occurrence will appear in 
history.

I've been pulling my hair trying to work out why a fit command is 
producing different results. Having an accurate record of my command 
history would be an immense help.

I'm currently having to cut and paste every command into a text file as 
I go along which is a serious PITA.

Peter.



>
>
>> While I realise this is done to save storage space somewhere, this is a
>> constant annoyance.
>>
>> I have an annoying problem where something keeps changing and I need to
>> track exactly what is happening.
>>
>> In a shell I would use the history command to see _exactly_ what I did
>> and in what order to see what I have changed. I can see a true record of
>> my commands and repeat various parts of it until I reproduce and
>> understand the error.
>>
>> with gnuplot this does not seem possible because history is forever
>> being revised and compacted and no longer retains a useful record. In
>> fact "history" does not provide the command history. It's more like
>> recent favourites, that often saves some typing but it is not the
>> command history.
>>
>> I'm not that tight for space that I need to economise a few K.  I'd much
>> rather save the few hours it's going to take me to find this problem
>> without a proper record of the commands I've issued to make the problem
>> repeatable.
>>
>> Is there a means of preventing gnuplot from compacting the command
>> history be removing dupes?
>
> I recall some years ago writing a history patch that allowed it to be
> configured in a couple ways: one being complete history, one being more
> condensed.  I might still have that around if you are interested, but
> I'd have to search for it and I'm sure it has conflicting hunks by now.
>
> Dan
>

Re: rewriting history

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

On 11/19/2013 01:03 AM, pl...@pi... wrote:
> On 11/19/13 07:05, Daniel J Sebald wrote:
>> On 11/18/2013 02:58 PM, pl...@pi... wrote:
>>> Hi,
>>>
>>> is there was way to stop gnuplot compacting history?
>>
>> Do you mean that the current command is not repeated in history if it
>> matches the previous most recent command in the history buffer?
>>
>> My history looks pretty lengthy, but I do seem to recall a limit. Also,
>> given it isn't recent history I can't look through it and conclude that
>> it is complete.
>
> yes, it's a feature that dupes are eliminated. Just try repeating your
> last plot command a few times. Only the last occurrence will appear in
> history.
>
> I've been pulling my hair trying to work out why a fit command is
> producing different results. Having an accurate record of my command
> history would be an immense help.
>
> I'm currently having to cut and paste every command into a text file as
> I go along which is a serious PITA.

That's sort of my modus operandi, except I edit in a file and either 
select and copy with the center mouse button or save and load the file. 
  History is nice for tweaking commands and trial-and-error, but 
anything more than five commands deep is tough to edit.  Nonetheless, 
history modifications might be worthwhile.

Dan


>
> Peter.
>
>
>
>>
>>
>>> While I realise this is done to save storage space somewhere, this is a
>>> constant annoyance.
>>>
>>> I have an annoying problem where something keeps changing and I need to
>>> track exactly what is happening.
>>>
>>> In a shell I would use the history command to see _exactly_ what I did
>>> and in what order to see what I have changed. I can see a true record of
>>> my commands and repeat various parts of it until I reproduce and
>>> understand the error.
>>>
>>> with gnuplot this does not seem possible because history is forever
>>> being revised and compacted and no longer retains a useful record. In
>>> fact "history" does not provide the command history. It's more like
>>> recent favourites, that often saves some typing but it is not the
>>> command history.
>>>
>>> I'm not that tight for space that I need to economise a few K. I'd much
>>> rather save the few hours it's going to take me to find this problem
>>> without a proper record of the commands I've issued to make the problem
>>> repeatable.
>>>
>>> Is there a means of preventing gnuplot from compacting the command
>>> history be removing dupes?
>>
>> I recall some years ago writing a history patch that allowed it to be
>> configured in a couple ways: one being complete history, one being more
>> condensed. I might still have that around if you are interested, but
>> I'd have to search for it and I'm sure it has conflicting hunks by now.
>>
>> Dan
>>
>
>

-- 

Dan Sebald
email: daniel(DOT)sebald(AT)ieee(DOT)org
URL: http://www(DOT)dansebald(DOT)com

Re: rewriting history

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

On 11/18/2013 02:58 PM, pl...@pi... wrote:
> Hi,
>
> is there was way to stop gnuplot compacting history?

Do you mean that the current command is not repeated in history if it 
matches the previous most recent command in the history buffer?

My history looks pretty lengthy, but I do seem to recall a limit.  Also, 
given it isn't recent history I can't look through it and conclude that 
it is complete.


> While I realise this is done to save storage space somewhere, this is a
> constant annoyance.
>
> I have an annoying problem where something keeps changing and I need to
> track exactly what is happening.
>
> In a shell I would use the history command to see _exactly_ what I did
> and in what order to see what I have changed. I can see a true record of
> my commands and repeat various parts of it until I reproduce and
> understand the error.
>
> with gnuplot this does not seem possible because history is forever
> being revised and compacted and no longer retains a useful record. In
> fact "history" does not provide the command history. It's more like
> recent favourites, that often saves some typing but it is not the
> command history.
>
> I'm not that tight for space that I need to economise a few K.  I'd much
> rather save the few hours it's going to take me to find this problem
> without a proper record of the commands I've issued to make the problem
> repeatable.
>
> Is there a means of preventing gnuplot from compacting the command
> history be removing dupes?

I recall some years ago writing a history patch that allowed it to be 
configured in a couple ways: one being complete history, one being more 
condensed.  I might still have that around if you are interested, but 
I'd have to search for it and I'm sure it has conflicting hunks by now.

Dan

rewriting history

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

Hi,

is there was way to stop gnuplot compacting history?

While I realise this is done to save storage space somewhere, this is a 
constant annoyance.

I have an annoying problem where something keeps changing and I need to 
track exactly what is happening.

In a shell I would use the history command to see _exactly_ what I did 
and in what order to see what I have changed. I can see a true record of 
my commands and repeat various parts of it until I reproduce and 
understand the error.

with gnuplot this does not seem possible because history is forever 
being revised and compacted and no longer retains a useful record. In 
fact "history" does not provide the command history. It's more like 
recent favourites, that often saves some typing but it is not the 
command history.

I'm not that tight for space that I need to economise a few K.  I'd much 
rather save the few hours it's going to take me to find this problem 
without a proper record of the commands I've issued to make the problem 
repeatable.

Is there a means of preventing gnuplot from compacting the command 
history be removing dupes?



      regards, Peter.

Re: New plotting style "with parallelaxes"

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

On Monday, 11 November 2013 08:41:50 AM pl...@pi... wrote:
> On 11/11/13 05:28, sfeam wrote:
> > Hi all,
> >
> > Please have a look at this patchset on SourceForge
> >      https://sourceforge.net/p/gnuplot/patches/646/
> >
> > or this demo output from the patched gnuplot
> >      http://gnuplot.sourceforge.net/demo_cvs/parallel.html
> >
> > Parallel axis plots are a way to explore or present correlated properties
> > of multidimensional data.  They are not so common, but that is partly
> > because not many plotting programs offer the option.   It has been a
> > requested feature in gnuplot for quite a while.
> >
> > Implementation was a bit tricky.   The obvious thing to do would be
> > to allocate new axis structures as needed so that there is no limit
> > on the number of parallel axes in the plot.  The problem is that all
> > of the macros and routines in gnuplot expect to pass or be handed
> > an index into the global axis_array[]  rather than a pointer to an
> > arbitrary axis structure.   That could be changed of course, but when
> > I started down that route it was obvious that it would require modifying
> > a very large number of lines of code.   So instead I spent some time
> > cutting down the memory impact of using static arrays, and then
> > increased the size of axis_array[] and its various parallel arrays like
> > axis_defaults[] and ticfmt[].   Currently the number of parallel axes
> > in a plot is limited to MAX_PARALLEL_AXES = MAX_NUM_VAR = 12.
> >
> > I think it's all working now, but your feedback and comments are most
> > welcome.    I wonder in particular about how to autogenerate a key or
> > other titles for this kind of plot.
> >
> > 	have fun with it,
> >
> > 		Ethan
> >
> 
> Interesting.
> 
> If people have been requesting it I suppose it's a known method of 
> presenting data. For me it's just a pretty pattern.
> 
> Maybe the demo needs a link to explaining what it is and how to read it.

There are links in the patch description on SourceForge.
The article in Wikipedia is decent:
   http://en.wikipedia.org/wiki/Parallel_coordinates

But yeah, the demo would be better if it used a real data set to illustrate
a significant feature;  it does say that in the demo text.   So contributions
of data would be welcome also.

	Ethan



> 
> Peter.
> 
> 
> 
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: New plotting style "with parallelaxes"

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

On 11/11/13 05:28, sfeam wrote:
> Hi all,
>
> Please have a look at this patchset on SourceForge
>      https://sourceforge.net/p/gnuplot/patches/646/
>
> or this demo output from the patched gnuplot
>      http://gnuplot.sourceforge.net/demo_cvs/parallel.html
>
> Parallel axis plots are a way to explore or present correlated properties
> of multidimensional data.  They are not so common, but that is partly
> because not many plotting programs offer the option.   It has been a
> requested feature in gnuplot for quite a while.
>
> Implementation was a bit tricky.   The obvious thing to do would be
> to allocate new axis structures as needed so that there is no limit
> on the number of parallel axes in the plot.  The problem is that all
> of the macros and routines in gnuplot expect to pass or be handed
> an index into the global axis_array[]  rather than a pointer to an
> arbitrary axis structure.   That could be changed of course, but when
> I started down that route it was obvious that it would require modifying
> a very large number of lines of code.   So instead I spent some time
> cutting down the memory impact of using static arrays, and then
> increased the size of axis_array[] and its various parallel arrays like
> axis_defaults[] and ticfmt[].   Currently the number of parallel axes
> in a plot is limited to MAX_PARALLEL_AXES = MAX_NUM_VAR = 12.
>
> I think it's all working now, but your feedback and comments are most
> welcome.    I wonder in particular about how to autogenerate a key or
> other titles for this kind of plot.
>
> 	have fun with it,
>
> 		Ethan
>

Interesting.

If people have been requesting it I suppose it's a known method of 
presenting data. For me it's just a pretty pattern.

Maybe the demo needs a link to explaining what it is and how to read it.

Peter.

New plotting style "with parallelaxes"

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

Hi all, 

Please have a look at this patchset on SourceForge
    https://sourceforge.net/p/gnuplot/patches/646/

or this demo output from the patched gnuplot
    http://gnuplot.sourceforge.net/demo_cvs/parallel.html

Parallel axis plots are a way to explore or present correlated properties
of multidimensional data.  They are not so common, but that is partly
because not many plotting programs offer the option.   It has been a
requested feature in gnuplot for quite a while.

Implementation was a bit tricky.   The obvious thing to do would be
to allocate new axis structures as needed so that there is no limit
on the number of parallel axes in the plot.  The problem is that all
of the macros and routines in gnuplot expect to pass or be handed
an index into the global axis_array[]  rather than a pointer to an
arbitrary axis structure.   That could be changed of course, but when
I started down that route it was obvious that it would require modifying
a very large number of lines of code.   So instead I spent some time
cutting down the memory impact of using static arrays, and then 
increased the size of axis_array[] and its various parallel arrays like
axis_defaults[] and ticfmt[].   Currently the number of parallel axes
in a plot is limited to MAX_PARALLEL_AXES = MAX_NUM_VAR = 12.

I think it's all working now, but your feedback and comments are most
welcome.    I wonder in particular about how to autogenerate a key or 
other titles for this kind of plot.  

	have fun with it,

		Ethan 

Re: Should 'splot' and 'plot' treat NaN data differently?

[Dima K. <gn...@di...>]

sfeam <sf...@us...> writes:

> On Tuesday, 29 October 2013 10:20:27 PM Dima Kogan wrote:
>> Ethan A Merritt <sf...@us...> writes:
>
> As shown in the imageNaN demo, if you use "failsafe" image mode
> then gnuplot can work around the lack of alpha channel support by
> simply not drawing that pixel at all.  That works for your test case also.
>
> So no, I don't think there is a bug.

OK. Thanks again.

Re: Should 'splot' and 'plot' treat NaN data differently?

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

On Tuesday, 29 October 2013 10:20:27 PM Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > On Monday, 28 October, 2013 23:32:10 Dima Kogan wrote:
> >>
> >> I'm not against either of these behaviors, but I think them being
> >> different is a bug. Thoughts?
> >
> > Look for a fix soon.
> 
> Hi Ethan. I tested the code after your commit, and it appears to fix the
> issue. Thank you very much.
> 
> I'm now seeing another related, but new problem. The coloring of the
> +inf/-inf is now the same in every configuration I tested (black,
> yellow). The coloring of the nan, however can vary.
> 
> I looked at 3 different terminals: x11, wxt, qt. For each, I ran the
> test script posted earlier in this thread. I did a 2d plot, an splot
> with 'set view map' and an splot with a 3d view. The colors of the nan
> were as follows:
> 
> |     | splot, view map | splot, 3d view | plot        |
> |-----+-----------------+----------------+-------------|
> | x11 | ** black **     | white          | ** black ** |
> | wxt | white           | white          | white       |
> | qt  | white           | white          | white       |
> 
> Here "white" really means "transparent". A quick glance suggests there
> may be a bug in the x11 terminal. What do you think?

As you say, it's supposed to be transparent.
But x11 doesn't do transparency, so transparent pixels come
out as black in image/rgbimage mode.

As shown in the imageNaN demo, if you use "failsafe" image mode
then gnuplot can work around the lack of alpha channel support by
simply not drawing that pixel at all.  That works for your test case also.

So no, I don't think there is a bug.

	Ethan



> 
> Thanks again.
> 
> dima
> 
> 
> ------------------------------------------------------------------------------
> Android is increasing in popularity, but the open development platform that
> developers love is also attractive to malware creators. Download this white
> paper to learn more about secure code signing practices that can help keep
> Android apps secure.
> http://pubads.g.doubleclick.net/gampad/clk?id=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: Should 'splot' and 'plot' treat NaN data differently?

[Dima K. <gn...@di...>]

Ethan A Merritt <sf...@us...> writes:

> On Monday, 28 October, 2013 23:32:10 Dima Kogan wrote:
>>
>> I'm not against either of these behaviors, but I think them being
>> different is a bug. Thoughts?
>
> Look for a fix soon.

Hi Ethan. I tested the code after your commit, and it appears to fix the
issue. Thank you very much.

I'm now seeing another related, but new problem. The coloring of the
+inf/-inf is now the same in every configuration I tested (black,
yellow). The coloring of the nan, however can vary.

I looked at 3 different terminals: x11, wxt, qt. For each, I ran the
test script posted earlier in this thread. I did a 2d plot, an splot
with 'set view map' and an splot with a 3d view. The colors of the nan
were as follows:

|     | splot, view map | splot, 3d view | plot        |
|-----+-----------------+----------------+-------------|
| x11 | ** black **     | white          | ** black ** |
| wxt | white           | white          | white       |
| qt  | white           | white          | white       |

Here "white" really means "transparent". A quick glance suggests there
may be a bug in the x11 terminal. What do you think?

Thanks again.

dima

Re: Should 'splot' and 'plot' treat NaN data differently?

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

On Monday, 28 October, 2013 23:32:10 Dima Kogan wrote:
> Hi.
> 
> I'm plotting some binary data 'with image' (using the most recent
> gnuplot in the repo). The data has a few NaN and a few Inf values in it.
> I'm seeing that these points are rendered differently between
> otherwise-identical 'plot' and 'splot' plots.
> 
> I'm attaching a sample data file that has some NaNs. The command I'm
> using to plot is
> 
>  set view map
>  splot '/tmp/inconsistent_nan.dat' binary array=(155,5) format="%float" with image
> 
> The 'plot' command is identical except using 'plot' instead of 'splot'.
> 
> At full zoom-out, the 'splot' draws NaN in white, -inf in black and +inf
> in yellow. The colors autoscale, so these mappings were done by drawing
> -inf with the lowest-range color, +inf with the highest-range color, and
> nan as transparent.
> 
> The 'splot' version just sets the infs and the nans to 0. This lies in
> the middle of the range for this dataset, so the rendering is roughly
> red.
> 
> I'm not against either of these behaviors, but I think them being
> different is a bug. Thoughts?

The demo file "imageNaN.dem" shows that the handling is the same
in 2D and 3D for at least some cases.    Your example must hit some
other code path.....

Yup. Simple bug failing to handle the case where the color information 
is in column 4 rather than column 3.   

Look for a fix soon.

	Ethan

Should 'splot' and 'plot' treat NaN data differently?

[Dima K. <gn...@di...>]

Hi.

I'm plotting some binary data 'with image' (using the most recent
gnuplot in the repo). The data has a few NaN and a few Inf values in it.
I'm seeing that these points are rendered differently between
otherwise-identical 'plot' and 'splot' plots.

I'm attaching a sample data file that has some NaNs. The command I'm
using to plot is

 set view map
 splot '/tmp/inconsistent_nan.dat' binary array=(155,5) format="%float" with image

The 'plot' command is identical except using 'plot' instead of 'splot'.

At full zoom-out, the 'splot' draws NaN in white, -inf in black and +inf
in yellow. The colors autoscale, so these mappings were done by drawing
-inf with the lowest-range color, +inf with the highest-range color, and
nan as transparent.

The 'splot' version just sets the infs and the nans to 0. This lies in
the middle of the range for this dataset, so the rendering is roughly
red.

I'm not against either of these behaviors, but I think them being
different is a bug. Thoughts?

dima

wxWidgets on Mac fail to work again

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

Hi,

just to let you know: gnuplot fails to work with wxWidgets 3.0.0-rc1
on Mac (it worked with 2.9.5). I filed a ticket and I hope that the
issue will be resolved before the official release of wxWidgets 3.0.0.
I strongly suspect one specific commit (which kind-of-solved another
problem I had) might be the culprit, but I didn't test anything yet.

Someone mentioned a workaround: to move the Mac hack from within
wxtApp::OnInit() to some place before that, but I didn't test if that
has any influence and it makes most sense to wait for a response from
wxWidgets developers. (There is a chance that gnuplot will need a
slight modification.)

I first saw a bug report from a user on Mavericks [10.9] (where it
crashes), but I'm kind-of-able to reproduce the problem on Lion [10.7]
where it simply fails to initialize.

Luckily gnuplot still supports enough other terminals (where MacPorts
doesn't yet support Qt 5 and Qt 4 doesn't compile on 10.9, AquaTerm
has limited functionality and Apple is slowly phasing out X11).

Mojca

Re: Does anyone or anything use these files?

[Hans-Bernhard B. <HBB...@t-...>]

On 24.10.2013 20:58, Ethan A Merritt wrote:
> Are these files used on any currently supported platform?
>
>    term/pc.trm

This is still used by the almost-functional config/makefile.wc, which 
builds a 32-bit DOS version of gnuplot using the OpenWatcom internal 
graphics library (a facsimile of Microsoft C's <graph.h>).  I managed to 
revive that port with only minor tweaks to copies of config/makefile.wc 
and config/config.wc.  Still works inside a DOSBOX session.

My vote would be to keep this for now.  I might even check in the 
changes needed to make it useful again.

>    src/corplot.c

That purports to be for something called a Corona 325 graphics engine, 
which must have died along with the 16-bit Microsoft C build on DOS.

>    src/corgraph.asm
>    src/hrcgraph.asm
>    src/pcgraph.asm

Only the discontinued 16-bit DOS build using Microsoft C used those.

These latter 4 can thus go away.  There's nothing left using them.

Does anyone or anything use these files?

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

The distribution package for gnuplot includes several files that I think
are historical remnants.   They appear to be relevant only to 16-bit DOS
variants that gnuplot no longer supports.

But I'm not sure.

Are these files used on any currently supported platform?

  term/pc.trm 
  src/corplot.c 
  src/corgraph.asm
  src/hrcgraph.asm  
  src/pcgraph.asm

If not, I don't see any reason to include them in the distribution tarballs.

	thanks for any insight,

		Ethan

Re: underscore in text

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

On Tuesday, 22 October 2013 06:45:10 PM pl...@pi... wrote:
> On 10/21/13 23:36, Ethan A Merritt wrote:
> > On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote:
> >> I'm wondering when this changed, and whether the change was intentional:
> >> it used to be that if you did, say,
> >>
> >> set title 'Under_score'
> >>
> 
> inspired by this discussion to use enhanced , I just found out that 
> clicking on legend text in wxt no longer toggles line with this option on.

Sounds like a bug.  An equivalent bug was fixed for the qt terminal
a while ago.  I didn't realize wxt suffered from the same.

	Ethan

> 
> unsetting it restores line toggle.
> 
>   set termoption noenhanced
> 
> Is that intended
> 
> Peter.
> 
> 
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: underscore in text

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

On 10/21/13 23:36, Ethan A Merritt wrote:
> On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote:
>> I'm wondering when this changed, and whether the change was intentional:
>> it used to be that if you did, say,
>>
>> set title 'Under_score'
>>

inspired by this discussion to use enhanced , I just found out that 
clicking on legend text in wxt no longer toggles line with this option on.


unsetting it restores line toggle.

  set termoption noenhanced

Is that intended

Peter.

4.6.4 announce link on gnuplot.info is dead

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

Hello, 

I tried the announce link for the latest version from the gnuplot.info
page, but it gave me an error page:

An error has been encountered in accessing this page.

1. Server: gnuplot.info
2. URL path: /announce_4.6.4.txt
3. Error notes: NONE
4. Error type: 404
5. Request method: GET
6. Request query string: NONE
7. Time: 2013-10-22 20:43:51 UTC (1382474631) 
...

The links for 4.6.3 and the rest work.

Peter Juhasz

Re: underscore in text

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

On Monday, 21 October, 2013 19:41:20 Allin Cottrell wrote:
> On Mon, 21 Oct 2013, Ethan A Merritt wrote:
> 
> > On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote:
> >> I'm wondering when this changed, and whether the change was intentional:
> >> it used to be that if you did, say,
> >>
> >> set title 'Under_score'
> >>
> >> then (at least when using the wxt and x11 terminals) the text came out
> >> shown, with an underscore. Now (recent CVS[*]) The underscore produces a
> >> subscript 's' (in wxt and x11).
> >
> > Recent cvs defaults to enhanced text mode.
> 
> Ah, I see.
> 
> For my personal use of gnuplot I wouldn't have a problem with using 
> the "noenhanced" keyword if I wanted a literal underscore. The 
> practical issue is that gnuplot is used as the plotting engine for 
> other programs and that, in general, the names of variables that 
> could be plotted might well contain underscores; and the names of 
> variables can easily find their way into titles.

Do those programs never use enhanced text mode?
If they do, then this conflict already existed.
If not, then wouldn't it be relatively painless for them to specify
"noenhanced" when selecting a terminal?  I imagine they already
have a standard set of properties that they use for terminal selection.

	Ethan




> 
> If this change goes into "production", coders (such as myself) who 
> make "third-party" use of gnuplot will have to be careful to 
> modulate gnuplot titling commands per version.
> 
> > The motivation for the change was to support "prettier" default formats for
> > axis tic labels.  The new default format " %h" produces, for example,
> > 1.2 x 10^6     as a label rather than   1.2e06
> > See discussion here:
> >     https://sourceforge.net/p/gnuplot/patches/637/
> > and here
> >     https://sourceforge.net/mailarchive/message.php?msg_id=31498730
> >
> > It seemed kind of pointless to change the default format without also
> > enabling the enhanced text mode needed to produce it.
> 
> OK. Pity the screenshots referenced in the text don't seem to be 
> available. But on this matter I'm not fully persuaded in favor of 
> the (more verbose and therefore more likely to cause interference in 
> tighly tic'd plots) "1.2 x 10^6" versus "1.2e06". As you say in that 
> exchange, "ugliness" in tic labels is mostly a matter of 
> inconsistency (or excessive population of zeros).
> 
> > What would you prefer?
> > Revert the change in default terminal setting?
> > Revert the default state of just the "set title" command?
> > More obvious warnings that something has changed?
> > Some other combination?
> 
> Well, I don't want to stand in the way of progress ;-) I think I 
> have to experiment a bit before offering an opinion.
> 
> Allin Cottrell

Re: underscore in text

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

On Mon, 21 Oct 2013, Ethan A Merritt wrote:

> On Monday, 21 October, 2013 16:19:48 Allin Cottrell wrote:
>> I'm wondering when this changed, and whether the change was intentional:
>> it used to be that if you did, say,
>>
>> set title 'Under_score'
>>
>> then (at least when using the wxt and x11 terminals) the text came out
>> shown, with an underscore. Now (recent CVS[*]) The underscore produces a
>> subscript 's' (in wxt and x11).
>
> Recent cvs defaults to enhanced text mode.

Ah, I see.

For my personal use of gnuplot I wouldn't have a problem with using 
the "noenhanced" keyword if I wanted a literal underscore. The 
practical issue is that gnuplot is used as the plotting engine for 
other programs and that, in general, the names of variables that 
could be plotted might well contain underscores; and the names of 
variables can easily find their way into titles.

If this change goes into "production", coders (such as myself) who 
make "third-party" use of gnuplot will have to be careful to 
modulate gnuplot titling commands per version.

> The motivation for the change was to support "prettier" default formats for
> axis tic labels.  The new default format " %h" produces, for example,
> 1.2 x 10^6     as a label rather than   1.2e06
> See discussion here:
>     https://sourceforge.net/p/gnuplot/patches/637/
> and here
>     https://sourceforge.net/mailarchive/message.php?msg_id=31498730
>
> It seemed kind of pointless to change the default format without also
> enabling the enhanced text mode needed to produce it.

OK. Pity the screenshots referenced in the text don't seem to be 
available. But on this matter I'm not fully persuaded in favor of 
the (more verbose and therefore more likely to cause interference in 
tighly tic'd plots) "1.2 x 10^6" versus "1.2e06". As you say in that 
exchange, "ugliness" in tic labels is mostly a matter of 
inconsistency (or excessive population of zeros).

> What would you prefer?
> Revert the change in default terminal setting?
> Revert the default state of just the "set title" command?
> More obvious warnings that something has changed?
> Some other combination?

Well, I don't want to stand in the way of progress ;-) I think I 
have to experiment a bit before offering an opinion.

Allin Cottrell

Re: underscore in text

[Jonathan T. <jt...@as...>]

On Mon, 21 Oct 2013, Ethan A Merritt wrote:
> Recent cvs defaults to enhanced text mode.
[[...]]
> I would have thought that underscores in user-supplied titles and labels
> were more likely to be intended as subscripts than literals, but I could be wrong.
> 
> What would you prefer?
> Revert the change in default terminal setting?
> Revert the default state of just the "set title" command?
> More obvious warnings that something has changed?
> Some other combination?

I was (am) under the impression that strings in "double quotes" use
enhanced mode if it's enabled, while strings in 'single quotes' never
use enhanced mode.  Is this correct?

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"