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

Re: problem building QT for v5

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

On 05/11/14 17:51, sfeam wrote:
>> Also noted this, that did not look too reassuring:
>> >
>> >In function 'snprintf',
>> >      inlined from 'get_data' at plot2d.c:712:12:
>> >/usr/include/bits/stdio2.h:65:3: warning: call to
>> >__builtin___snprintf_chk will always overflow destination buffer
> That is indeed an error. I wonder why I don't get the same error
> message when compiling here.
>
> 	thanks,
>
> 		Ethan
>

Note it's a warning , not an error. If you don't sit there watching 
closely or your hardware is fast you'll probably miss it.

/Peter.

Re: problem building QT for v5

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

On 05/11/14 17:51, sfeam wrote:
> The check for qt5 is done by looking for installation of the following
> modules:
>       Qt5Core Qt5Gui Qt5Network Qt5Svg Qt5PrintSupport
> 		
> You should be able to find what failed by looking in the configuration
> log file config.log.   I am guessing that even though you installed qt5
> you didn't pull one or more of those optional modules.

I didn't say I'd installed qt5 and I haven't. Gnuplot correctly detects 
qt4 but is looking in a temporary build directory.

./configure

   wxt terminal: yes
   Qt terminal: yes (qt4)


log:

configure:14155: checking for QT
configure:14163: $PKG_CONFIG --exists --print-errors "QtCore >= 4.5 
QtGui >= 4.5 QtNetwork >= 4.5 QtSvg >= 4.5"
configure:14166: $? = 0
configure:14181: $PKG_CONFIG --exists --print-errors "QtCore >= 4.5 
QtGui >= 4.5 QtNetwork >= 4.5 QtSvg >= 4.5"
configure:14184: $? = 0
configure:14260: result: yes
configure:14274: WARNING: The Qt terminal will use Qt4.
...

configure:16316: result:   wxt terminal: yes
configure:16326: result:   Qt terminal: yes (qt4)

...
pkg_cv_QT_CFLAGS='-DQT_SHARED -I/usr/include/qt4 
-I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui 
-I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtSvg  '
pkg_cv_QT_LIBS='-L/usr/lib/qt4 -lQtNetwork -lQtSvg -lQtGui -lQtCore  '

...

QT_CFLAGS='-DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore 
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtNetwork 
-I/usr/include/qt4/QtSvg  '
QT_LIBS='-L/usr/lib/qt4 -lQtNetwork -lQtSvg -lQtGui -lQtCore  '
....

UIC='/tmp/x11-libs/qt-core-4.8.2/work/qt-everywhere-opensource-src-4.8.2/bin/uic'


So the question remains, where is it digging this "UIC" thing from ?

Maybe whatever file it sources this from is incorrect.

Where should I look to see what it's doing?

Thx.

Re: problem building QT for v5

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

On Sunday, 11 May 2014 12:54:29 PM pl...@pi... wrote:
> Hi,
> 
> just tried to update to v5 and it barfed at the QT stage.
> 
> 
> 
> Making timestamp.h
> /tmp/x11-libs/qt-core-4.8.2/work/qt-everywhere-opensource-src-4.8.2/bin/uic 
> -o ui_QtGnuplotSettings.h qtterminal/QtGnuplotSettings.ui
> make[4]: 
> /tmp/x11-libs/qt-core-4.8.2/work/qt-everywhere-opensource-src-4.8.2/bin/uic: 
> Command not found
> make[4]: *** [ui_QtGnuplotSettings.h] Error 127

Those messages are obviously from qt4.8, not qt5.

Gnuplot's configure script will first try to find a qt5 installation.
If it can't, then it tries to find a qt4 installation.

> Where is configure digging this up from? It should presumably be looking 
> for something in the installed location not in the build structure.

The check for qt5 is done by looking for installation of the following
modules:
     Qt5Core Qt5Gui Qt5Network Qt5Svg Qt5PrintSupport
		
You should be able to find what failed by looking in the configuration
log file config.log.   I am guessing that even though you installed qt5
you didn't pull one or more of those optional modules.
 

> ===
> 
> Also noted this, that did not look too reassuring:
> 
> In function 'snprintf',
>      inlined from 'get_data' at plot2d.c:712:12:
> /usr/include/bits/stdio2.h:65:3: warning: call to 
> __builtin___snprintf_chk will always overflow destination buffer

That is indeed an error. I wonder why I don't get the same error
message when compiling here.

	thanks,

		Ethan

problem building QT for v5

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

Hi,

just tried to update to v5 and it barfed at the QT stage.



Making timestamp.h
/tmp/x11-libs/qt-core-4.8.2/work/qt-everywhere-opensource-src-4.8.2/bin/uic 
-o ui_QtGnuplotSettings.h qtterminal/QtGnuplotSettings.ui
make[4]: 
/tmp/x11-libs/qt-core-4.8.2/work/qt-everywhere-opensource-src-4.8.2/bin/uic: 
Command not found
make[4]: *** [ui_QtGnuplotSettings.h] Error 127


It seems to be looking for something in a temporary build directory that 
gets cleaned out once it's installed.

Where is configure digging this up from? It should presumably be looking 
for something in the installed location not in the build structure.

this is probably not new because IIRC, I do not usually build it with qt 
anyway.

./configure --without-qt   ; went fine and installed.

===

Also noted this, that did not look too reassuring:

In function 'snprintf',
     inlined from 'get_data' at plot2d.c:712:12:
/usr/include/bits/stdio2.h:65:3: warning: call to 
__builtin___snprintf_chk will always overflow destination buffer


/Peter

Re: what is the use of "u" in tabulated output?

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

On Wednesday, 23 April 2014 09:06:15 PM pl...@pi... wrote:
> On 04/23/14 20:47, Ethan A Merritt wrote:
> >
> > On Sunday, 20 April, 2014 10:48:10 pl...@pi... wrote:
> >>    HI,
> >>
> >>
> >> I often use conditional using clauses to plot part of a range of data
> >>
> >> plot datafile using   (($1<=1995.55)?$1:NaN):(2*fcos1($1))
> >>
> >> I tried this when writing to a file specified with "set table"  and
> >> instead of cutting off the output, it appends garbage data with a "u".
> >>
> >> help table tells me this means "undefined"
> >>
> >> I see two problems here. I did not ask for undefined output , I
> >> specified NaN.
> >>
> >> Secondly , what is the possible use of "undefined" values in a data file?
> >>
> >> 1995.46  1.00914  i
> >> 1995.54  1.10947  i
> >> 1.98547e-81  4.74363e+170  u
> >> 3.75845e+174  7.52884e-24  u
> >> 0  2.122e-314  u
> >> 0  0  u
> >> 0  0  u
> >> 1.9771e+161  1.44402e+214  u
> >> -1.22337e-44  1.1735e-319  u
> >> 1.01887e+189  7.49746e+247  u
> >> 5.35166e+199  2.10124e+88  u
> >
> > I do not know what the original idea was,
> > nor do I know if there are existing scripts that depend on the 'u'.
> > It does seem pointless to write out total junk values as in your example.
> >
> > If it helps, version 5 has a new mode "with table" that does what you want.

As of yesterday, the version 5 code has been changed to store the actual input
values even if some value on the line is NaN, causing the whole line to be
marked "undefined".  Since the values are stored, they are available for 
output in a table.  Also they are available to be used in a "refresh" command.

I can't think of anything this would break, but it is definitely a change
in the version 4 behavior.

	Ethan

Re: 07-May-2014 Update on version 5 progress

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

--- On Thu, 2014/5/8, Tatsuro MATSUOKA wrote:

> --- On Thu, 2014/5/8, Ethan A Merritt  wrote:
> 
> > I think that we are close to putting out a first release candidate
> > for version 5.   
> > 
> > Here is a summary of progress on the big items.
> > IMHO all are in an acceptable state for a release candidate.
> > 
> > Bold/Italic markup in enhanced text mode
> > ==============================
> > - some terminal-specific bugs reported and fixed
> > - not yet implemented for x11, aqua, ...
> > - Try it out: "test" command,  bolditalic.dem
> >     http://gnuplot.sourceforge.net/demo_svg_5.0/enhanced_utf8.html
> > 
> > Dash patterns under user control
> > ========================
> > - generic fallback to version 4 "linetype" dash patterns seems to work
> > - custom dash patterns not yet implemented for latex terminals, win, ...
> > - very little testing, so there are probably bugs
> > - Try it out: dashtypes.dem
> >     http://gnuplot.sourceforge.net/demo_canvas_5.0/dashtypes.html
> > 
> > Default line color sequence
> > ====================
> > - Three sequences are built in as "set colors {default|classic|podo}"
> > - As in version 4.6 this can be further customized via "set linetype"
> > - Should there be a built-in "monochrome" sequence that uses
> >   defined dash patterns and line widths instead of colors?
> > - Try it out: "test" command, any of the demos
> > 
> > Known issues (not serious enough to block release)
> > =====================================
> > - wxt and qt terminals don't work as nicely on OSX as on linux or windows
> > - the output from "set table' could use thorough revision
> > - the built-in sequence of dash patterns is not consistent across terminals
> > 
> > Unresolved
> > ========
> > - Back in 2004 STORE_WITH_LOG_AND_UPDATE_RANGE was changed
> >   to not store NaN or Inf values read from the input file.
> >   Furthermore no other data values on that same line are stored.
> >   This produces garbage output from "set table" and limits
> >   what changes you can make before issuing a "refresh" command. 
> >   See thread "what is the use of "u" in tabulated output?".
> > 
> >   Does anyone recall whether there was a specific problem in 2004 that
> >   led to this change?   Can we safely change [back] to storing x/y/z/etc
> >   data values even if the point is marked "undefined" because one of the
> >   values is NaN or Inf?
> > 
> >   My feeling is that it would be OK to make this change for 5.0-rc1 with the
> >   option of reverting it if unresolvable problems show up.
> > 
> >         Ethan
> 
> Very Nice! 
> 
> > Known issues (not serious enough to block release)
> > =====================================
> > - wxt and qt terminals don't work as nicely on OSX as on linux or windows
> 
> For mingw build, there is no way to build gnuplot with qt terminals.
> The config/mingw/Makefile should be modified.
> 

I found description for qt terminal in config/msvc/Makefile.
This is a good example.
The octave-3.8.1 ships qt-4 toolkit on MinGW.  I will try to modify config/mingw/Makefile for qt terminal build on MinGW platform if I will find time to do so.

Tatsuro

Re: 07-May-2014 Update on version 5 progress

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

--- On Thu, 2014/5/8, Ethan A Merritt  wrote:

> I think that we are close to putting out a first release candidate
> for version 5.   
> 
> Here is a summary of progress on the big items.
> IMHO all are in an acceptable state for a release candidate.
> 
> Bold/Italic markup in enhanced text mode
> ==============================
> - some terminal-specific bugs reported and fixed
> - not yet implemented for x11, aqua, ...
> - Try it out: "test" command,  bolditalic.dem
>     http://gnuplot.sourceforge.net/demo_svg_5.0/enhanced_utf8.html
> 
> Dash patterns under user control
> ========================
> - generic fallback to version 4 "linetype" dash patterns seems to work
> - custom dash patterns not yet implemented for latex terminals, win, ...
> - very little testing, so there are probably bugs
> - Try it out: dashtypes.dem
>     http://gnuplot.sourceforge.net/demo_canvas_5.0/dashtypes.html
> 
> Default line color sequence
> ====================
> - Three sequences are built in as "set colors {default|classic|podo}"
> - As in version 4.6 this can be further customized via "set linetype"
> - Should there be a built-in "monochrome" sequence that uses
>   defined dash patterns and line widths instead of colors?
> - Try it out: "test" command, any of the demos
> 
> Known issues (not serious enough to block release)
> =====================================
> - wxt and qt terminals don't work as nicely on OSX as on linux or windows
> - the output from "set table' could use thorough revision
> - the built-in sequence of dash patterns is not consistent across terminals
> 
> Unresolved
> ========
> - Back in 2004 STORE_WITH_LOG_AND_UPDATE_RANGE was changed
>   to not store NaN or Inf values read from the input file.
>   Furthermore no other data values on that same line are stored.
>   This produces garbage output from "set table" and limits
>   what changes you can make before issuing a "refresh" command. 
>   See thread "what is the use of "u" in tabulated output?".
> 
>   Does anyone recall whether there was a specific problem in 2004 that
>   led to this change?   Can we safely change [back] to storing x/y/z/etc
>   data values even if the point is marked "undefined" because one of the
>   values is NaN or Inf?
> 
>   My feeling is that it would be OK to make this change for 5.0-rc1 with the
>   option of reverting it if unresolvable problems show up.
> 
>         Ethan

Very Nice! 

> Known issues (not serious enough to block release)
> =====================================
> - wxt and qt terminals don't work as nicely on OSX as on linux or windows

For mingw build, there is no way to build gnuplot with qt terminals.
The config/mingw/Makefile should be modified.

qt terminal also does not work on the Cygwin
http://sourceforge.net/p/gnuplot/bugs/1346/
On the Cygwin-64 qt terminal also does not work.

07-May-2014 Update on version 5 progress

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

I think that we are close to putting out a first release candidate
for version 5.   

Here is a summary of progress on the big items.
IMHO all are in an acceptable state for a release candidate.

Bold/Italic markup in enhanced text mode
==============================
- some terminal-specific bugs reported and fixed
- not yet implemented for x11, aqua, ...
- Try it out: "test" command,  bolditalic.dem
	http://gnuplot.sourceforge.net/demo_svg_5.0/enhanced_utf8.html

Dash patterns under user control
========================
- generic fallback to version 4 "linetype" dash patterns seems to work
- custom dash patterns not yet implemented for latex terminals, win, ...
- very little testing, so there are probably bugs
- Try it out: dashtypes.dem
	http://gnuplot.sourceforge.net/demo_canvas_5.0/dashtypes.html

Default line color sequence
====================
- Three sequences are built in as "set colors {default|classic|podo}"
- As in version 4.6 this can be further customized via "set linetype"
- Should there be a built-in "monochrome" sequence that uses
  defined dash patterns and line widths instead of colors?
- Try it out: "test" command, any of the demos

Known issues (not serious enough to block release)
=====================================
- wxt and qt terminals don't work as nicely on OSX as on linux or windows
- the output from "set table' could use thorough revision
- the built-in sequence of dash patterns is not consistent across terminals

Unresolved
========
- Back in 2004 STORE_WITH_LOG_AND_UPDATE_RANGE was changed
  to not store NaN or Inf values read from the input file.
  Furthermore no other data values on that same line are stored.
  This produces garbage output from "set table" and limits
  what changes you can make before issuing a "refresh" command. 
  See thread "what is the use of "u" in tabulated output?".

  Does anyone recall whether there was a specific problem in 2004 that
  led to this change?   Can we safely change [back] to storing x/y/z/etc
  data values even if the point is marked "undefined" because one of the
  values is NaN or Inf?

  My feeling is that it would be OK to make this change for 5.0-rc1 with the
  option of reverting it if unresolvable problems show up.

		Ethan

Fw: Re: Translation of setting window of qt terminal

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

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> From: Tatsuro MATSUOKA <tma...@ya...>
> Subject: Re: Translation of  setting window of qt terminal
> To: "Jérôme Lodewyck" <lod...@us...>
> Date: Wed, 07 May 2014 17:18:24 +0900
> 
> --- On Wed, 2014/5/7, Jérôme Lodewyck wrote:
> 
> > Hi,
> > 
> >     I think that gnuplot actually finds for an old version of the 
> > translation file. I guess a "make install" will solve the issue.
> > 
> > Regards,
> > 
> > Jérôme
> > 
> > 
> > Le 07/05/2014 04:11, Tatsuro MATSUOKA a écrit :
> > > Hello
> > >
> > > The translation of setting window of qt terminal was updated:
> > >
> > > 2014-05-05  Tatsuro MATSUOKA <tma...@ya...>
> > >
> > >     * src/qtterminal/po/qtgnuplot_ja.ts: Update translations
> > >
> > > I have built the latest snapshot of cvs source on Ubuntu 12.04 LTS 64 bit with qt terminal.
> > >
> > > Seeing setting window of qt terminal, the translation upadate is not refrelcted.
> > >
> > > Regards
> > >
> > > Taturo
> > >
> 
> As yo said, make install solved the problem.
> Thanks and sorry for the noise.
> 
> 

Translation of setting window of qt terminal

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

Hello

The translation of setting window of qt terminal was updated:

2014-05-05  Tatsuro MATSUOKA <tma...@ya...>

	* src/qtterminal/po/qtgnuplot_ja.ts: Update translations

I have built the latest snapshot of cvs source on Ubuntu 12.04 LTS 64 bit with qt terminal.

Seeing setting window of qt terminal, the translation upadate is not refrelcted.

Regards

Taturo

src/qtterminal/po/qtgnuplot_ja.ts: Update translations.

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

Hello

I have finished to check out the recent cvs source and found an item in ChangeLog.

2014-05-03  Ethan A Merritt 

	* src/qtterminal/po/qtgnuplot_ja.ts: Update translations.

I have privately sent a patch for src/qtterminal/po/qtgnuplot_ja.ts to Jérôme Lodewyck.
on On Tue, 2014/4/22.

The the update translation is different from mine.

See attached the patch.

The below the mail to Jérôme Lodewyck.
****************************************************************
> Thanks !
> 
> > "Rounded line ends"
> 
> This indicates whether all lines drawn by gnuplot are terminated by a straight 
> boundary or by half a circle. You can see by yourself by executing "test" in 
> gnuplot and check/uncheck the option in the configuration dialog of the Qt 
> terminal. Also, the rounded line ends (also called line caps) is explained in 
> figure 11 of https://svgwg.org/svg2-draft/painting.html
> 
> > "Mouse label"
> 
> The mouse label is the text label that shows the coordinatess of the mouse 
> cursor while moving the mouse cursor in the plot area. It is usually displayed 
> in the status bar of the plot window. In the configuration dialog box, this 
> label can be configured to be in the status bar, in the tool bar, in the plot 
> area, or no mouse label at all.
> 
> > "None"
> 
> This means that no mouse label is shown.

Thanks for the detailed explanation.  I have re-generate the patch.
Please make the previous patch to delete.

Tatsuro

Re: Much thicker lines by default

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

On Monday, 28 April 2014 02:34:01 PM Ethan A Merritt wrote:
> On Monday, 28 April, 2014 14:10:59 Dima Kogan wrote:
> > Ethan A Merritt <sf...@us...> writes:
> > 
> > > On Monday, 28 April, 2014 13:30:18 Dima Kogan wrote:
> > >> Hi.
> > >> 
> > >> The default line width appears to have been affected in a recent commit:
> > >> 
> > >>  https://github.com/gnuplot/gnuplot/commit/b6c8dbfc63387be9e0c84d0d7b9ba6f480e5da8b
> > >> 
> > >> The commit notes don't say anything about it, so I'm wondering if this
> > >> change wasn't intentional. Is nobody else seeing this?
> > >
> > > Do you mean lines in the "test" command?  Which terminal?
> > 
> > I just ran a few more tests. Only the x11 terminal appears to be
> > affected. This explains why nobody complained yet. To reproduce, plot
> > anything 'with lines' in x11. Or "plot x".

Here is what is going on.

1) For a long time gnuplot has used the special linetype -1 to
indicate a solid black line.  This has been a convenient way to 
guarantee getting a black line even if the normal terminal color
sequence does not include black.  Most places in the code refer
to this linetype as LT_BLACK.

2) Since lt -1 was also guaranteed to be a solid line whatever the
terminal dash pattern sequence, it seemed logical to also special
case this linetype as LT_SOLID for the purpose of supporting 
dashtypes.  So far so good.

3) The glitch is that some of the oldest gnuplot terminals 
apparently treat lt -1  as a solid black _double thickness_ line.
This is true at least for x11 and postscript.  I have not yet
checked all the others.   So in revising the code to support
dashtypes, all the solid lines started being drawn with 
LT_SOLID, which for x11 and postscript is for some reason
drawn double thickness.

I see two possible fixes.

1) Change LT_SOLID to some other value.  The obvious value would
be linetype 1.  But this would mean you can never set a non-solid
dashpattern for linetype 1, so I don't like this idea.

2) Change x11 so that lt -1 is not drawn double thickness by default.
I don't see a problem there.   

What about postscript? The postscript code really does treat this
linetype differently, so there might be side effects from changing it
even aside from all those old postscript generating
gnuplot scripts out there that were written when lt -1 produced a 
thicker line.  On the other hand, unlike the x11 case the factor
of two in the default lt -1 linewidth does not affect any other
linetypes or linewidths.  So we could just leave it 


I'm leaning toward fix #2, either with or without making a 
change to postscript also.

	Ethan

Re: Much thicker lines by default

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

On Monday, 28 April, 2014 16:51:44 Dmitri A. Sergatskov wrote:
> On Mon, Apr 28, 2014 at 4:34 PM, Ethan A Merritt
> <merritt@u.washington.edu>wrote:
> 
> >
> > ! Default line widths
> >   gnuplot*axisWidth:   0
> >   gnuplot*line1Width:  1
> >
> > I'm not entirely clear whether width 0 is expected to be narrower than
> > width 1, but it's believable.   But that would only affect the "test"
> > command.
> >
> 
> 
> ​It appears to me that width 0 on x11 means 1 pixel, width 1 2 pixels,
> etc...
> So in the current version (​
> Version 5.0 patchlevel alpha    last modified 2014-04-28
> ​)
> 
> plot sin(x) lw 5
> 
> looks the same as
> 
> plot sin(x) lw 10
> on ​
> Version 4.6 patchlevel 5    last modified February 2014

I guess that the following command from any terminal in your current
session will restore the previous behaviour:

    echo "gnuplot*borderWidth: 1" | xrdb -merge

But I do not understand why this one linetype is now affecting all 
the others.  There has been no change to the code in either x11.trm
or gplt_x11.c, so this must be a case of a slightly different command
sequence from the core code revealing a bug that may have been
there for a long time.    Can anyone spot anything relevant?

	Ethan


> 
> ​Except the colors are also different -- why did this changed?
> 
> Dmitri.
> 

Re: Much thicker lines by default

[Dmitri A. S. <das...@gm...>]

On Mon, Apr 28, 2014 at 4:34 PM, Ethan A Merritt
<merritt@u.washington.edu>wrote:

>
> ! Default line widths
>   gnuplot*axisWidth:   0
>   gnuplot*line1Width:  1
>
> I'm not entirely clear whether width 0 is expected to be narrower than
> width 1, but it's believable.   But that would only affect the "test"
> command.
>


​It appears to me that width 0 on x11 means 1 pixel, width 1 2 pixels,
etc...
So in the current version (​
Version 5.0 patchlevel alpha    last modified 2014-04-28
​)

plot sin(x) lw 5

looks the same as

plot sin(x) lw 10
on ​
Version 4.6 patchlevel 5    last modified February 2014

​Except the colors are also different -- why did this changed?

Dmitri.
-- 
​

Re: Much thicker lines by default

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

On Monday, 28 April, 2014 14:10:59 Dima Kogan wrote:
> Ethan A Merritt <sf...@us...> writes:
> 
> > On Monday, 28 April, 2014 13:30:18 Dima Kogan wrote:
> >> Hi.
> >> 
> >> The default line width appears to have been affected in a recent commit:
> >> 
> >>  https://github.com/gnuplot/gnuplot/commit/b6c8dbfc63387be9e0c84d0d7b9ba6f480e5da8b
> >> 
> >> The commit notes don't say anything about it, so I'm wondering if this
> >> change wasn't intentional. Is nobody else seeing this?
> >
> > Do you mean lines in the "test" command?  Which terminal?
> 
> I just ran a few more tests. Only the x11 terminal appears to be
> affected. This explains why nobody complained yet. To reproduce, plot
> anything 'with lines' in x11. Or "plot x".

I can see only one relevant change.  The linetype selected for the line
samples in "test" changed from LT_AXIS to LT_SOLID.   The default X11
settings for those are
! Default line widths
  gnuplot*axisWidth:   0
  gnuplot*line1Width:  1

I'm not entirely clear whether width 0 is expected to be narrower than
width 1, but it's believable.   But that would only affect the "test" command.

I don't see anything in that patchset that would affect normal plotting,
so that part remains unexplained.  I find it odd that it would hit only the
X11 terminal.  I guess we'll find out if people report anything similar for
other terminals.

	Ethan

Re: Much thicker lines by default

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

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

> On Monday, 28 April, 2014 13:30:18 Dima Kogan wrote:
>> Hi.
>> 
>> The default line width appears to have been affected in a recent commit:
>> 
>>  https://github.com/gnuplot/gnuplot/commit/b6c8dbfc63387be9e0c84d0d7b9ba6f480e5da8b
>> 
>> The commit notes don't say anything about it, so I'm wondering if this
>> change wasn't intentional. Is nobody else seeing this?
>
> Do you mean lines in the "test" command?  Which terminal?

I just ran a few more tests. Only the x11 terminal appears to be
affected. This explains why nobody complained yet. To reproduce, plot
anything 'with lines' in x11. Or "plot x".

dima

Re: Much thicker lines by default

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

On Monday, 28 April, 2014 13:30:18 Dima Kogan wrote:
> Hi.
> 
> The default line width appears to have been affected in a recent commit:
> 
>  https://github.com/gnuplot/gnuplot/commit/b6c8dbfc63387be9e0c84d0d7b9ba6f480e5da8b
> 
> The commit notes don't say anything about it, so I'm wondering if this
> change wasn't intentional. Is nobody else seeing this?

Do you mean lines in the "test" command?  Which terminal?

> dima

Re: Mouse position-to-clipboard UI

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

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

> On Saturday, 26 April 2014 10:51:20 PM Dima Kogan wrote:
>> Hi.
>> 
>> Currently you can use the '1' and '2' keys to change the format of the
>> status line in the interactive terminals. You can separately use '3' and
>> '4' to change the format of the string that gets copied to the clipboard
>> on a double-click.
>> 
>> This is somewhat confusing, expecially because there's no user feedback
>> at ALL to the '3' and '4' keys. At its most basic, it'd be good to know
>> which clipboard format we just switched to. I propose something even
>> simpler, however: how would we all feel about getting rid of '3' and '4'
>> entirely, and to let the clipboard format to be the same as the status
>> line format? Then the user feedback is clear, and we have less invisible
>> state?
>
> Fine with me.

OK. Here's a patch the removes that logic. (Apologies for the
double-email, Ethan. I forgot the Cc the list the last time)

Much thicker lines by default

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

Hi.

The default line width appears to have been affected in a recent commit:

 https://github.com/gnuplot/gnuplot/commit/b6c8dbfc63387be9e0c84d0d7b9ba6f480e5da8b

The commit notes don't say anything about it, so I'm wondering if this
change wasn't intentional. Is nobody else seeing this?

dima

Re: Adding normalise to gnuplot

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

On Monday, 28 April, 2014 11:59:27 Jon Gjengset wrote:
> > >> However, if you want to do this sort of thing it does not require a
> > >> patch to gnuplot, just use a function.
> > >>
> > >> max(x) =(if (x>biggest)?biggest=max:(x))
> > >> biggest=-1e-134; plot datafile 1:max($2)
> > >> plot datafile 1:($2/biggest)
> > >
> > > Ah, of course, why didn't I think of that?!
> > 
> > Thats also somthing which can be done with the stats command:
> > 
> > stats datafile using 2
> > plot datafile using 1:($2/STATS_max)
> 
> Actually, there is one use-case not covered by these approaches, and
> that is when doing a "live" plot where replot is called repeatedly and
> the underlying datafile changes. In these situations (unless I'm
> mistaken), STATS_MAX/biggest won't be recomputed, and so the scaling
> will be incorrect. A smoothing filter would continue to work in this
> case. Any thoughts on how rescaling on replot might be achieved without
> a patch?

Not precisely what you ask for, but very close to it

set autoscale noextend
set yrange [0:1]
set ytics .1
set datafile volatile

plot FOO axes x1y2 with line
set y2range[GPVAL_DATA_Y2_MIN:GPVAL_DATA_Y2_DATA_MAX]
refresh
pause -1

This doesn't actually rescale the data, but it maps the values against
the range [0:1] along the y axis.   There would be a flash of data using
the previous scale before the "refresh" remaps and redraws it.

	Ethan

Re: Adding normalise to gnuplot

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

> >> However, if you want to do this sort of thing it does not require a
> >> patch to gnuplot, just use a function.
> >>
> >> max(x) =(if (x>biggest)?biggest=max:(x))
> >> biggest=-1e-134; plot datafile 1:max($2)
> >> plot datafile 1:($2/biggest)
> >
> > Ah, of course, why didn't I think of that?!
> 
> Thats also somthing which can be done with the stats command:
> 
> stats datafile using 2
> plot datafile using 1:($2/STATS_max)

Actually, there is one use-case not covered by these approaches, and
that is when doing a "live" plot where replot is called repeatedly and
the underlying datafile changes. In these situations (unless I'm
mistaken), STATS_MAX/biggest won't be recomputed, and so the scaling
will be incorrect. A smoothing filter would continue to work in this
case. Any thoughts on how rescaling on replot might be achieved without
a patch?

Re: Mouse position-to-clipboard UI

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

On Saturday, 26 April 2014 10:51:20 PM Dima Kogan wrote:
> Hi.
> 
> Currently you can use the '1' and '2' keys to change the format of the
> status line in the interactive terminals. You can separately use '3' and
> '4' to change the format of the string that gets copied to the clipboard
> on a double-click.
> 
> This is somewhat confusing, expecially because there's no user feedback
> at ALL to the '3' and '4' keys. At its most basic, it'd be good to know
> which clipboard format we just switched to. I propose something even
> simpler, however: how would we all feel about getting rid of '3' and '4'
> entirely, and to let the clipboard format to be the same as the status
> line format? Then the user feedback is clear, and we have less invisible
> state?

Fine with me.

	Ethan

> 
> dima
> 
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Mouse position-to-clipboard UI

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

Hi.

Currently you can use the '1' and '2' keys to change the format of the
status line in the interactive terminals. You can separately use '3' and
'4' to change the format of the string that gets copied to the clipboard
on a double-click.

This is somewhat confusing, expecially because there's no user feedback
at ALL to the '3' and '4' keys. At its most basic, it'd be good to know
which clipboard format we just switched to. I propose something even
simpler, however: how would we all feel about getting rid of '3' and '4'
entirely, and to let the clipboard format to be the same as the status
line format? Then the user feedback is clear, and we have less invisible
state?

dima

Backward compatibility of command abbreviations

[Karl-Friedrich R. <mai...@gm...>]

Hi,

i noticed today that in gp50, the abbreviation

	set termo

no longer works as it used to do in gp46, at least "termopt" needs
to be given. I coudn´t find another example.

The help says that "..in most cases unambiguous abbreviations ...
are permissible." How is it decided if they´re allowed? Hardcoded
minimum commands?

Best, Karl

Re: Adding normalise to gnuplot

[<us...@be...>]

Zitat von Jon Gjengset <jo...@th...>:

>>
>> However, if you want to do this sort of thing it does not require a
>> patch to gnuplot, just use a function.
>>
>> max(x) =(if (x>biggest)?biggest=max:(x))
>> biggest=-1e-134; plot datafile 1:max($2)
>> plot datafile 1:($2/biggest)
>
> Ah, of course, why didn't I think of that?!

Thats also somthing which can be done with the stats command:

stats datafile using 2
plot datafile using 1:($2/STATS_max)

Christoph