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

Re: Gnuplot version 5 release candidate

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

--- On Wed, 2014/5/21, Tait wrote:
> I don't see the windows binaries on SourceForge, but I did pull them
> from Tatsuro's site, and the default wxt terminal behaves oddly, now.
> When I load a script containing "set contour" and a plot or splot, the
> plot window does not appear until after I move the mouse. Without the
> "set contour", without the (s)plot, or when not from within a script,
> the plot displays immediately.
> 
> To try it out, create a script:
>     reset
>     set contour
>     plot x
> 
> then 'load "thatscript.gps"' from within gnuplot, without touching the
> mouse. No plot or plot window is displayed. As soon as the mouse
> moves, the window appears, with the plot as expected. The behavior is
> repeatable, for me. Does anybody else see this as well?
> 
> 
> Ethan A Merritt <sf...@us...> said (on 2014/05/19):
> > A source tarball for the version 5.0-rc1 release candidate 
> > is now publically accessible on SourceForge:...

Tait. Please confirm whether your operation works well on windows terminal.

I suspect that the change on 2014-01-04 is related to that you pointed out.
I have aware the phenomenon that all .dem on wxt terminal on windows does not work correctly. Shigeharu Takeno also pointed out that point in the private mail to me.

The change below perhaps related to the phenomena that you have met.
*************************************************************************
2014-01-04  Bastian Maerkisch  <bma...@we...>

	* src/win/wcommon.h src/win/wgdiplus.cpp|h src/win/wgnuplib.h
	src/win/wgraph.c src/win/resourc.h term/win.trm:  New (optional)
	variant of the windows terminal backend which draws using the GDI+ API
	whenever possible. This is much faster in some cases than the old
	backend which switches between GDI and GDI+ to support antialiasing
	and RGBA colors. Images are drawn using GDI since GDI+ always uses some
	sort of interpolation when scaling images. Enhanced text is currently
	still drawn using GDI. Adjacent polygons of the same color are merged
	in order to avoid "seams" between them caused by antialiasing. See also
	Bug #1096.

	* src/term_api.h src/graphics (plot_image_or_update_axes):  Wrap
	the fallback image output with term->layer() commands using
	TERM_LAYER_BEGIN_IMAGE and TERM_LAYER_END_IMAGE. This can be
	used by terminals to optimize output.

	* src/win/wgraph.c (drawgraph):  Move GDI image drawing code from
	drawgraph() to a new routine draw_image().

	* src/command.c src/fit.c|h src/plot.c|h src/term.c src/win/wgraph.c 
	src/win/winmain.c src/win/wtext.c term/win.trm:  Handle Ctrl-C
	asynchronously on Windows (GUI and console mode). This is done by
	setting ctrlc_flag and testing it in check_for_mouse_event(). Thus,
	scripts etc. can now finally be interrupted by pressing Ctrl-C in
	console mode gnuplot or Ctrl-Break in wgnuplot.

	* src/win/winmain.c (ConsoleGetch):  Remap Shift-Tab key-code in
	console mode, too.

***********************************************************************
The above change solves the CTRL+C issue on gnuplot on windows for a long term.
The change seems to be well on windows terminal but not be well on wxt terminal.

To confirm my assumption, I have to downgrade the cvs source but I have not tried yet.  

Please give me a little bit time to confirm that the change above is an origin of the fault on the wxt terminal.

Regards

Tatsuro

 

Re: Gnuplot version 5 release candidate

[Tait <gnu...@t4...>]

I don't see the windows binaries on SourceForge, but I did pull them
from Tatsuro's site, and the default wxt terminal behaves oddly, now.
When I load a script containing "set contour" and a plot or splot, the
plot window does not appear until after I move the mouse. Without the
"set contour", without the (s)plot, or when not from within a script,
the plot displays immediately.

To try it out, create a script:
    reset
    set contour
    plot x

then 'load "thatscript.gps"' from within gnuplot, without touching the
mouse. No plot or plot window is displayed. As soon as the mouse
moves, the window appears, with the plot as expected. The behavior is
repeatable, for me. Does anybody else see this as well?


Ethan A Merritt <sf...@us...> said (on 2014/05/19):
> A source tarball for the version 5.0-rc1 release candidate 
> is now publically accessible on SourceForge:...

Re: Gnuplot version 5 release candidate

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

On Tuesday, 20 May 2014 10:47:50 AM Christoph Bersch wrote:
> > It would be nice if someone would volunteer to fix the generation
> > of HTML documentation from the *.doc or *.tex or whatever.
> > It has not worked well for a long time.  That would make it easier
> > to provide links to specific online sections of the documentation
> > rather than pointing to the whole *pdf file.
> 
> Good point, I had also thought about this. How was the HTML  
> documentation of version 4.2 created, which is still online?

It was generated with an external tool called latex2html.
But that tool ceased to be developed or supported, so far as I 
can tell, and no longer works with current LaTeX installations.
Furthermore it didn't handle figures, or at least the commands
in gnuplot's Makefile didn't handle figures.

I have tried several possible replacements. The most promising
seems to be htlatex.  Supposedly it should do what we want, but
the default mode is not very satisfactory.

> I already contacted the maintainer of gnuplotting.org, which has a  
> very nice version of the 4.6. documentation on  
> http://www.gnuplotting.org/manpage-gnuplot-4-6/. He sent me some  
> helpful command line stuff, but it still needs a lot of extra work.  
> I'll see if I can come up with a good script.

That site does look nicer than I get out of a default run of
htlatex.   It would be nicer yet if the index ran down the side
in a separate panel so that you can browse the index without
losing your current place.

	Ethan



> 
> Christoph
> 
> 

Re: Gnuplot version 5 release candidate

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

Zitat von Ethan A Merritt <sf...@us...>:

> On Saturday, 17 May, 2014 10:39:07 Christoph Bersch wrote:
>>
> The dashed/solid terminal options are no longer needed.
>
>> I  don't see, how currently the default linetypes can be switched between
>> dashed and solid-only.
>
> set for [i=1:N] linetype i solid	# set all to solid (this is the default)
> set for [i=1:N] linetype i dt i      # set each linetype to a  
> different dash pattern
>
>> That would be like the `color` and `monochrome`
>> options of the terminals. You can change the *default* linetypes to be
>> dashed or only solid, but you could in any case use `dashtype` to use
>> dashed lines even if the terminal option is set to `solid`.
>
> Exactly.   mono/color is also no longer needed, for much the same reason.
> There is a sample monochrome style file in .../share but your
> comment reminds me that the new command
>    set colorsequence {default|classic|podo}
> could have a keyword for
>    set colorsequence mono
> that does basically the same thing as the sample script.

Hmm, maybe it would make sense to have a similar option to switch the  
default linetypes between dashed and solid. Something like `set  
linetype dashed|solid`. Then one could change the line sequences with  
e.g.

     set linetype dashed
     set colorsequence mono

> It would be nice if someone would volunteer to fix the generation
> of HTML documentation from the *.doc or *.tex or whatever.
> It has not worked well for a long time.  That would make it easier
> to provide links to specific online sections of the documentation
> rather than pointing to the whole *pdf file.

Good point, I had also thought about this. How was the HTML  
documentation of version 4.2 created, which is still online?

I already contacted the maintainer of gnuplotting.org, which has a  
very nice version of the 4.6. documentation on  
http://www.gnuplotting.org/manpage-gnuplot-4-6/. He sent me some  
helpful command line stuff, but it still needs a lot of extra work.  
I'll see if I can come up with a good script.

Christoph

Re: Gnuplot version 5 release candidate

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

On Saturday, 17 May, 2014 10:39:07 Christoph Bersch wrote:
> Thanks for the RC!
> 
> Zitat von sfeam <sf...@us...>:
> >
> > If you have any last minute issues/requests/additions
> > please send them by the end of the week.  If you have
> > suggestions where to send announcements, send those too.
> 
> What happend to the `dashed` option of e.g. the cairo terminals?

The dashed/solid terminal options are no longer needed.

> I  don't see, how currently the default linetypes can be switched between  
> dashed and solid-only. 

set for [i=1:N] linetype i solid	# set all to solid (this is the default)
set for [i=1:N] linetype i dt i      # set each linetype to a different dash pattern

> That would be like the `color` and `monochrome`  
> options of the terminals. You can change the *default* linetypes to be  
> dashed or only solid, but you could in any case use `dashtype` to use  
> dashed lines even if the terminal option is set to `solid`.

Exactly.   mono/color is also no longer needed, for much the same reason.
There is a sample monochrome style file in .../share but your
comment reminds me that the new command
   set colorsequence {default|classic|podo}
could have a keyword for
   set colorsequence mono
that does basically the same thing as the sample script.

> Second, I would like to see a 'linetype variable' which, opposed to  
> `lc var`, changes all line properties: linecolor, dashtype and  
> pointtype. But that could also be added later.

I agree.

 
> > CHANGES
> > =======
> >
> 
> Here is missing, that `set style increment user` was removed.
> 
> I think, we should also organize a section on the homepage with  
> 'Migrating to 5.0', which contains simple examples showing how to  
> change and adapt old scripts.

There is a small section in the User Manual with examples of 
how to replace the deprecated syntax.

It would be nice if someone would volunteer to fix the generation
of HTML documentation from the *.doc or *.tex or whatever.
It has not worked well for a long time.  That would make it easier
to provide links to specific online sections of the documentation
rather than pointing to the whole *pdf file.

 
> 
> Christoph

Re: Gnuplot version 5 release candidate

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

A source tarball for the version 5.0-rc1 release candidate 
is now publically accessible on SourceForge:

    http://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.rc1/

Release Notes are here

    http://gnuplot.sourceforge.net/RELEASE_NOTES_5_0_rc1.text

Demos are here

    http://gnuplot.sourceforge.net/demo_5.0/
    http://gnuplot.sourceforge.net/demo_svg_5.0/
    http://gnuplot.sourceforge.net/demo_canvas_5.0/

	Ethan


On Wednesday, 14 May, 2014 22:44:25 sfeam wrote:
> 
> A 5.0.rc1 tarball a a draft set of Release Notes are now on SourceForge
> in a "staging area" of the Files section.
> (I'm not quite sure how that works, but I think for the first
> 3 days it is only visible if you are on some list of developers.
> Unfortunately I don't know exactly where that list is so I don't
> know how many of you are on it.)
> 
> On Saturday either the tarball will automagically become visible to
> everyone or I will manually move it if that fails.
> 
> Next Monday, if nothing has gone wrong, I will send announcements
> to various places.

Re: cross, x and star points

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

On Saturday, 17 May 2014 11:38:52 PM Jonathan Thornburg wrote:
> On Sat, May 17, 2014 at 12:22:51PM +0200, Karl-Friedrich Ratzsch wrote:
> > Pointtype 3 in most terminals (emf being the notable exception)
> > is just a superposition of pt 1+2, so it completely hides them if
> > put at the same position. I've looked at an old plot of mine,
> > and thought "i know these points should be at the same position,
> > but are two of them even there?"
> 
> A related problem: if we define coordinates so that pointtype 1
> (+ sign) has line segments running from (-1,0) to (+1,0) and
> (0,-1) to (0,+1), then pointtype 2 (x sign) has line segments
> running from (-1,-1) to (+1,+1) and (-1,+1) to (+1,-1).  In other
> words, the line segments for pointtype 2 are sqrt(2) times as long
> as the arms for pointtype 1, so pointtype 2 looks sqrt(2) times bigger.
> 
> The result is that if I want to use both point-type 1 and 2 and have
> the symbols look the same size arms (==> line segments the same length)
> then I need to specify
>   plot ... with points pointtype 1 pointsize 1.000, \
>        ... with points pointtype 2 pointtype 0.707
> 
> This makes gnuplot scripts a bit less readable.
> 
> Unfortunately it's hard to fix this in a backwards-compatible way.
> I suppose we could introduce new point types (maybe use negative
> numbers??) scaled so that the maximum radius of any ink from the
> point center is always the same.  Or add a new 'set' option to toggle
> the current vs a sqrt(2)-times-smaller definition of the "x" points
> (types 2 and 3).
> 
> Neither of these reqlly qualifies as an *elegant* solution.  Does
> anyone have better ideas?

You have many options for handling point symbols now.

All of the original symbols drawn with simple vectors
look crude compared to using proper symbol glyphs.

Have a look at 
   http://gnuplot.sourceforge.net/demo_cvs/lines_arrows.html 

		Ethan

Re: cross, x and star points

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

On Sat, May 17, 2014 at 12:22:51PM +0200, Karl-Friedrich Ratzsch wrote:
> Pointtype 3 in most terminals (emf being the notable exception)
> is just a superposition of pt 1+2, so it completely hides them if
> put at the same position. I've looked at an old plot of mine,
> and thought "i know these points should be at the same position,
> but are two of them even there?"

A related problem: if we define coordinates so that pointtype 1
(+ sign) has line segments running from (-1,0) to (+1,0) and
(0,-1) to (0,+1), then pointtype 2 (x sign) has line segments
running from (-1,-1) to (+1,+1) and (-1,+1) to (+1,-1).  In other
words, the line segments for pointtype 2 are sqrt(2) times as long
as the arms for pointtype 1, so pointtype 2 looks sqrt(2) times bigger.

The result is that if I want to use both point-type 1 and 2 and have
the symbols look the same size arms (==> line segments the same length)
then I need to specify
  plot ... with points pointtype 1 pointsize 1.000, \
       ... with points pointtype 2 pointtype 0.707

This makes gnuplot scripts a bit less readable.

Unfortunately it's hard to fix this in a backwards-compatible way.
I suppose we could introduce new point types (maybe use negative
numbers??) scaled so that the maximum radius of any ink from the
point center is always the same.  Or add a new 'set' option to toggle
the current vs a sqrt(2)-times-smaller definition of the "x" points
(types 2 and 3).

Neither of these reqlly qualifies as an *elegant* solution.  Does
anyone have better ideas?

ciao,

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

cross, x and star points

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

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hi,</div>

<div>&nbsp;</div>

<div>Ethan asked for old annoyances in gp that could be changed with 5.0 some time ago, and was just remembered of one that&acute;s been bugging me for years from time to time.</div>

<div>&nbsp;</div>

<div>Pointtype 3 in most terminals (emf being the notable exception) is just a superposition of pt 1+2, so it completely hides them if put at the same position. I&acute;ve looked at an old plot of mine, and thought &quot;i know these points should be at the same position, but are two of them even there?&quot;</div>

<div>&nbsp;</div>

<div>So a six-arm star would add to logical plot clarity, plus it&acute;s less ink on the paper (improving optical clarity) , plus vector graphic files would be (marginally) smaller.</div>

<div>Drawback would be bad looks without antialiasing.</div>

<div>&nbsp;</div>

<div>Any opinions on this? Should it be done, and if yes for 5.0.0?</div>

<div>&nbsp;</div>

<div>Best, Karl</div>

<div>&nbsp;</div>

<div>&nbsp;</div></div></body></html>

Re: Gnuplot version 5 release candidate

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

Thanks for the RC!

Zitat von sfeam <sf...@us...>:
>
> If you have any last minute issues/requests/additions
> please send them by the end of the week.  If you have
> suggestions where to send announcements, send those too.

What happend to the `dashed` option of e.g. the cairo terminals? I  
don't see, how currently the default linetypes can be switched between  
dashed and solid-only. That would be like the `color` and `monochrome`  
options of the terminals. You can change the *default* linetypes to be  
dashed or only solid, but you could in any case use `dashtype` to use  
dashed lines even if the terminal option is set to `solid`.

Second, I would like to see a 'linetype variable' which, opposed to  
`lc var`, changes all line properties: linecolor, dashtype and  
pointtype. But that could also be added later.


> CHANGES
> =======
>

Here is missing, that `set style increment user` was removed.


I think, we should also organize a section on the homepage with  
'Migrating to 5.0', which contains simple examples showing how to  
change and adapt old scripts.


Christoph

Re: Windows and Cygwin binaries for ver 5.0-rc1

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

--- On Thu, 2014/5/15, Tatsuro MATSUOKA wrote:
> The cvs version of gnuplot, version information is bumped to 5.0.rc1.
> 
> I have just uploaded Windows and Cygwin binaries for ver 5.0-rc1.
> 
> Windows
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

I founded that the pango related flaw and prepared an archive files collection of pango modules related dll  files. Do not forget install  "pango.modules.zip".

Tatsuro 

Gnuplot version 5 release candidate

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

Today I have updated the version info in the CVS source to version 5.0.rc1

A 5.0.rc1 tarball a a draft set of Release Notes are now on SourceForge
in a "staging area" of the Files section.
(I'm not quite sure how that works, but I think for the first
3 days it is only visible if you are on some list of developers.
Unfortunately I don't know exactly where that list is so I don't
know how many of you are on it.)

On Saturday either the tarball will automagically become visible to
everyone or I will manually move it if that fails.

Next Monday, if nothing has gone wrong, I will send announcements
to various places.

If you have any last minute issues/requests/additions
please send them by the end of the week.  If you have
suggestions where to send announcements, send those too.

I append a copy of the draft Release Notes.

    happy gnuplotting!

		Ethan



		GNUPLOT VERSION 5.0.rc1 RELEASE NOTES
		=====================================

We are happy to announce a release candidate for gnuplot version 5. 
Version 5 will be a major release with significant new capabilities
and enhancements compared to previous gnuplot versions.

MAJOR NEW FEATURES
==================

* The dot/dash pattern of a line can now be controlled independently
  from other properties using the keyword "dashtype".

* Text markup now supports bold and italic font settings in addition to
  the subscript, superscript, font size and other options previously
  provided by the "enhanced text" mode.  This mode is now the default.

* Command scripts may place in-line data in a named data block for
  repeated plotting.

* RGB colors can include an alpha-channel for transparency.
  E.g. SEETHRUBLU = (0xDD << 24) + (0x0 << 16) + (0x0 << 8) + (0xFF)
       set linetype N linecolor rgb SEETHRUBLU

* Bit shift operators << and >> (used in above example)

* Secondary axes (x2, y2) can be locked to the primary axis via a mapping
  function.  In the simplest case this guarantees that the primary and
  secondary axis ranges are identical.  In the general case it allows you
  to define a non-linear axis, something that previously was only possible
  for the special case of log scaling.

* The "import" command attaches a user-defined function name to a 
  function provided by an extenal shared object (i.e. a plugin).

* Previous commands in the history list of an interactive session can be
  reexecuted by number.  For example "history !5" will reexecute the 
  command numbered 5 in the list reported by "history".

* New plot styles "with parallelaxes", labeled contours.

* New coordinate system (Degrees, Minutes, Seconds) "set xdata geographic".

* Hypertext labels in the interactive terminals including web display
  using the HTML canvas or svg terminals.

Many other additions are described in the "New Features" section of the
documentation.


CHANGES
=======

Gnuplot development assigns very high priority to backward compatibility
with earlier versions.  For example any command script that worked in
version 4.0 is expected to continue to work for all version 4 releases
including the most recent one (4.6.5).  However changes introduced in
version 5 can affect the operation of some version 4 scripts. 

A brief summary of potentially incompatible changes is given here.

* Earlier versions of gnuplot used the keyword "linetype" to mean both
  the color and the solid/dot/dash pattern of a line.  Version 5 has
  separate keywords "linecolor" and "dashtype".  You can assign any
  desired color and a dash pattern to any linetype.  The program now
  uses a default set of 8 linetypes, all solid.  You can change these
  or add new linetypes as you please, or include the desired color or
  dash pattern directly in a plot command.  You do not need to change
  the current terminal or terminal mode in order to used dashed lines.

* The handling of input data containing NaN, Inf, inconsistent number of
  data columns, or other unexpected content has changed. See documentation
  under "missing" for examples and figures. 

* Time coordinates are stored internally as the number of seconds relative
  to the standard unix epoch 1-Jan-1970.  Earlier versions of gnuplot used
  a different epoch internally (1-Jan-2000). This change resolves
  inconsistencies introduced when time in seconds was generated externally.
  The epoch convention used by a particular gnuplot installation can be
  determined using the command `print strftime("%F",0)`.
  Time is now stored to at least millisecond precision.

* The "reverse" keyword (e.g. "set xrange [*:*] reverse") now affects only
  autoscaling.  It has no effect on explicit ranges. 
  "set xrange [0:1] reverse" is _not_ the same as "set xrange [1:0]".

* Options to the "fit" command are now given by "set fit ..." rather than
  by setting environmental variables.  Fit can handle up to MAX_NUM_VAR
  independent variables (currently 12).  Variables other than the first
  two (x, y) have been dissociated from axis names.
  E.g. "set urange [U1:U2]" has no effect on fitting.  Use the command
  "set dummy ..." to assign names to fit variables 3 ... 12.

* The function `timecolumn(N,"timeformat")` now has 2 parameters.
  Because the required second parameter is not associated with a particular
  data axis, this allows using the `timecolumn` function to read time data
  for reasons other than specifying the x or y coordinate.

* The `call` command is implemented by providing a set of variables ARGC,
  ARG0, ..., ARG9. ARG0 holds the name of the script file being executed.
  ARG1 to ARG9 are string variables and thus may either be referenced directly
  or expanded as macros, e.g. @ARG1.  The older convention for referencing
  call parameters as tokens $0 ... $9 is deprecated.

* "unset xrange" (and other axis ranges) restores the default range.

* "unset terminal" restores the original terminal of the current session.



		 NOTES TO PACKAGERS AND TESTERS 
		===============================

Configuration options for interactive use
-----------------------------------------

The 5.0 source code supports three primary cross-platform output modes
in addition to several platform-specific modes.

1) Qt
   The qt terminal supports interactive display with menu-driven
   output to png, svg or pdf.  The final 5.0 release may also support
   scripted output to these same file formats but this is not present
   in rc1.  If either Qt4 or Qt5 is detected by the configure script,
   this will be the default terminal.  It is now the fastest and most
   full-featured interactive terminal option.
   To disable this terminal:
      ./configure --without-qt
   To force use of Qt4 even if Qt5 is present:
      ./configure --with-qt=qt4

2) Cairo/pango/wxWidgets
   This set of terminals includes
   - pngcairo, pdfcairo, epscairo, and cairolatex for output to a file
   - wxt for interactive display
   All of these will be built by default if the configuration script finds
   the required libcairo, libpango, libcairo, libwxgtk, and related
   support libraries
   To disable these terminals:
       ./configure --without-cairo
       ./configure --with-cairo --disable-wxt

3) X11 (the "classic" interactive interface)
   This used to be the preferred interactive interface, but the newer
   wxt and qt terminals offer nicer output and a wider range of features.


Options for output to files
---------------------------

Of course the terminals (output modes) present in previous gnuplot versions
are also still available. These include, among many more obscure options:
- png/jpeg/gif output via libgd
- PostScript
- Many flavors of TeX/LaTeX output, including TikZ and ConTeXt
- Bitmapped output to support many older devices (e.g. HP deskjet, epson,
  seiko printers, pbm bitmapped graphics files) is available if needed
  but is no longer configured in by default.
      ./configure --with-bitmap-terminals

Options for generating interactive plots for web display
--------------------------------------------------------

- Mouseable output for display on the web can be created using either 
  the canvas terminal (HTML5 2D canvas element) or the svg terminal.
  Both allow zooming, toggling plot elements on/off, and user-scriptable
  hot keys.

Online demo plots
-----------------

Demo plots illustrating new and old features are online at

	http://gnuplot.sourceforge.net/demo_5.0/


		          OTHER NOTES
		===============================

Installation
------------

You can download a source tarball for gnuplot version 5.0.rc1 from the 
gnuplot development site on SourceForge.

	http://sourceforge.net/project/showfiles.php?group_id=2055

Installation instructions are available in the source itself; the short
version for linux/unix-like systems is to unpack the tarball and then
build it:
		cd gnuplot-5.0.rc1 ; ./configure ; make
test it:
		make check
install it:
		make install

Pay careful attention to the output of the ./configure script.
It may indicate that some output drivers have been omitted because the
necessary support libraries were not found.  In general you need to have
previously installed the "*-devel-*" versions of these libraries. 


Known issues
------------

- Mac OSX ships with a terminal input library that appears to be GNU
libreadline, but isn't really.  The program tries to cope with this, but
you may get better results by configuring gnuplot to use either its own
built-in readline routines or the real GNU libreadline.

- The gnuplot build system is not very good at figuring out where to find
or install LaTeX-related files.  This can affect use of the new lua/tikz
and ConTeXt terminals.

- You can configure support for both wxt and qt into the same gnuplot
executable, but only one of these two output modes can be used in any
given gnuplot session.


Support
-------
Please report all bugs and installation problems to the bug tracker
on SourceForge:

	http://sourceforge.net/tracker/?group_id=2055&atid=102055

There is also an gnuplot discussion forum on usenet group

	comp.graphics.apps.gnuplot


Development
-----------
Gnuplot development is quite active. The development branch on SourceForge
contains preliminary implementations of many new features.  Following the
release of gnuplot 5.0, the development branch will be identified as 
version 5.1.  Feedback and contributions of code are very welcome.

Windows and Cygwin binaries for ver 5.0-rc1

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

The cvs version of gnuplot, version information is bumped to 5.0.rc1.

I have just uploaded Windows and Cygwin binaries for ver 5.0-rc1.

Windows
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Cygwin
http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Tatsuro

Re: gnuplot 5.0 alpha (CVS) for Windows

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

--- On Wed, 2014/5/14, Tatsuro MATSUOKA wrote:
> Hello
> 
> I have uploaded the recent cvs snapshot of gnuplot for windows: 
> http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/
> 
> Note: 
> As I wrote in the page this binaries no longer work on Windows XP because the old msvcrt.dll does not have entry to vsnprinft_s.
> 
> I have confirmed the binary works on windows 7 and 8.
> I do not have windows Vista PC so that I do not know the whether binaries work on windows Vista or not.
> 
> If someone check whether the binaries work on Vista, please let me know the results.

I have found some flaws in the binaries and just corrected them.

Tatsuro

gnuplot 5.0 alpha (CVS) for Windows

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

Hello

I have uploaded the recent cvs snapshot of gnuplot for windows: 
http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Note: 
As I wrote in the page this binaries no longer work on Windows XP because the old msvcrt.dll does not have entry to vsnprinft_s.

I have confirmed the binary works on windows 7 and 8.
I do not have windows Vista PC so that I do not know the whether binaries work on windows Vista or not.

If someone check whether the binaries work on Vista, please let me know the results.

Regards

Tatsuro

Re: depricated syntax warning eating input buffer

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

On 05/12/14 17:06, sfeam wrote:
>
> On Monday, 12 May 2014 08:42:55 AM pl...@pi... wrote:
>> Hi,
>>
>> using gnuplot v5 built yesterday I find the fit "Deprecated syntax"
>> warning breaks input.
>>
>>
>> I linux primary buffer ( mouse 3 click to paste ) to copy data from a
>> text as input to gnuplot's special filename '-'
>>
>>
>> fit [0:fit_end] f_peak2(x) '-' using 1:2 via FWHM2,a
>> #4 3.5
>> 10 3.47 # 3.5
>> 25 3.79  #4.43
>> 50  4.45  #6.78
>> #100 11.755  # 60.9+56.65
>> #100 11.21
>> 200 4.48 #21.96
>> e
>>
>> Instead of just printing the warning and plotting as it did with 4.6 it
>> looses the rest of the input after the "fit" command and sits there with
>> the data input prompt.
>
> I seriously doubt that this has anything to do with printing or
> not printing a warning message.  I have seen similar failure to
> paste inline data from the mouse buffer even for simple plots
> without any involvement of "fit".  I don't know when or why
> it occurs.  If you can pin down a point where it changed, perhaps
> by bisecting builds from old CVS, then maybe we can figure out
> how to avoid this failure.
>
> 	Ethan
>
>

Well nothing seems to want to play now :(

last nights CVS , 4.6.5 and my old 4.5 cvs all produce this error now.

  G N U P L O T
         Version 4.6 patchlevel 5    last modified February 2014
         Build System: Linux i686


G N U P L O T
         Version 4.5 patchlevel 0    last modified 2012-01-17
         Build System: Linux i686

G N U P L O T
         Version 5.0 patchlevel alpha    last modified 2014-05-10



However, I have found a work around. If I paste the fit command , then 
in a separate operation paste the data it takes it.




BTW when it fails I need to enter two "e" lines to clear it.
Whatever is on the first line gets ignored and a new prompt for data.

  fit [fit_min:fit_end] f2(x) '-' using 1:2 via m2,c2
fit: Deprecated syntax. Consider using the 'noerror' option, see `help fit`.
input data ('e' ends) > e
input data ('e' ends) > e
          Read 1 points
          Skipped 1 points outside range [x=50:200]
          No data to fit



You are correct , nothing to do with the error message, adding "noerror" 
to comply does not get rid of the problem.


In passing the new keyword "noerror" is not clear and does not scan. It 
sounds like a option to suppress errors or error reporting.

noerrordata would be clearer.

If something like that could used instead, anyone using the relatively 
new feature as "noerror" would still be OK because it  would be an 
unambiguous abbreviation.

my2c.

Why was this needed, can't it just default to that anyway?  yet another 
verbose option to remember before fit will even work at all.



Peter.

Re: depricated syntax warning eating input buffer

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

On Monday, 12 May 2014 08:42:55 AM pl...@pi... wrote:
> Hi,
> 
> using gnuplot v5 built yesterday I find the fit "Deprecated syntax" 
> warning breaks input.
> 
> 
> I linux primary buffer ( mouse 3 click to paste ) to copy data from a 
> text as input to gnuplot's special filename '-'
> 
> 
> fit [0:fit_end] f_peak2(x) '-' using 1:2 via FWHM2,a
> #4 3.5
> 10 3.47 # 3.5
> 25 3.79  #4.43
> 50  4.45  #6.78
> #100 11.755  # 60.9+56.65
> #100 11.21
> 200 4.48 #21.96
> e
> 
> Instead of just printing the warning and plotting as it did with 4.6 it 
> looses the rest of the input after the "fit" command and sits there with 
> the data input prompt.

I seriously doubt that this has anything to do with printing or
not printing a warning message.  I have seen similar failure to 
paste inline data from the mouse buffer even for simple plots
without any involvement of "fit".  I don't know when or why
it occurs.  If you can pin down a point where it changed, perhaps
by bisecting builds from old CVS, then maybe we can figure out
how to avoid this failure.

	Ethan

Re: out of data CVS instructions

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

--- On Mon, 2014/5/12, pl...@pi...  wrote:
> Hi,
> 
> current instruction for CVS build inform that it will produce 4.3 when 
> in fact it gives 5.0 !!
> 
> http://www.gnuplot.info/development/#DownloadCVS
> 
> http://gnuplot.sourceforge.net/development/index.html
> 
> Downloading sources from the CVS repository
> Up-to-date source code of gnuplot (development version of gnuplot, 
> series 4.3) resides at SourceForge group gnuplot (group_id=2055). 
> Download of sources requires program cvs (not ftp!), which is available 
> for every platform. Execute the following commands:
> 
>    cvs -d:pserver:ano...@gn...:/cvsroot/gnuplot 
> login
>    cvs -z3 
> -d:pserver:ano...@gn...:/cvsroot/gnuplot co -P 
> gnuplot
> 
> 
> It would also be useful if (somewhere) there were instructions to get 
> source for stable 4.6 as well as 5.0 "head" .
> 
> Due to the bug breaking input from std-in, I need to revert ot 4.6 . 
> Finding out where source code for this is available seem to require some 
> work :(
> 
> Peter.

Why do you need to use cvs to get stable sources?
The stable sources can be obtained from the gnuplot sourceforge site:
http://sourceforge.net/projects/gnuplot/files/gnuplot/

However, date specified update can be made:
$ cd gnuplot; cvs update -D -d '2014-03-15'


Tatsuro

out of data CVS instructions

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

Hi,

current instruction for CVS build inform that it will produce 4.3 when 
in fact it gives 5.0 !!

http://www.gnuplot.info/development/#DownloadCVS

http://gnuplot.sourceforge.net/development/index.html

Downloading sources from the CVS repository
Up-to-date source code of gnuplot (development version of gnuplot, 
series 4.3) resides at SourceForge group gnuplot (group_id=2055). 
Download of sources requires program cvs (not ftp!), which is available 
for every platform. Execute the following commands:

   cvs -d:pserver:ano...@gn...:/cvsroot/gnuplot 
login
   cvs -z3 
-d:pserver:ano...@gn...:/cvsroot/gnuplot co -P 
gnuplot


It would also be useful if (somewhere) there were instructions to get 
source for stable 4.6 as well as 5.0 "head" .

Due to the bug breaking input from std-in, I need to revert ot 4.6 . 
Finding out where source code for this is available seem to require some 
work :(

Peter.

Re: depricated syntax warning eating input buffer

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

On 05/12/14 08:42, pl...@pi... wrote:
>
> Hi,
>
> using gnuplot v5 built yesterday I find the fit "Deprecated syntax"
> warning breaks input.
>
>
> I linux primary buffer ( mouse 3 click to paste ) to copy data from a
> text as input to gnuplot's special filename '-'
>
>
> fit [0:fit_end] f_peak2(x) '-' using 1:2 via FWHM2,a
> #4 3.5
> 10 3.47 # 3.5
> 25 3.79  #4.43
> 50  4.45  #6.78
> #100 11.755  # 60.9+56.65
> #100 11.21
> 200 4.48 #21.96
> e
>
> Instead of just printing the warning and plotting as it did with 4.6 it
> looses the rest of the input after the "fit" command and sits there with
> the data input prompt.
>
>
> gnuplot> fit [0:fit_end] f_peak2(x) '-' using 1:2 via FWHM2,a
> fit: Deprecated syntax. Consider using the 'noerror' option, see `help fit`.
> input data ('e' ends) >
>
>
> I assume the intention was for it to work as before, just with the
> warning printed.
>
>
> /Peter.
>

Yes, this is breaking some software that uses gnuplot for output, too.

Peter

depricated syntax warning eating input buffer

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

Hi,

using gnuplot v5 built yesterday I find the fit "Deprecated syntax" 
warning breaks input.


I linux primary buffer ( mouse 3 click to paste ) to copy data from a 
text as input to gnuplot's special filename '-'


fit [0:fit_end] f_peak2(x) '-' using 1:2 via FWHM2,a
#4 3.5
10 3.47 # 3.5
25 3.79  #4.43
50  4.45  #6.78
#100 11.755  # 60.9+56.65
#100 11.21
200 4.48 #21.96
e

Instead of just printing the warning and plotting as it did with 4.6 it 
looses the rest of the input after the "fit" command and sits there with 
the data input prompt.


gnuplot> fit [0:fit_end] f_peak2(x) '-' using 1:2 via FWHM2,a
fit: Deprecated syntax. Consider using the 'noerror' option, see `help fit`.
input data ('e' ends) >


I assume the intention was for it to work as before, just with the 
warning printed.


/Peter.

gnuplot 5.0 alpha (cvs) cygwin (32 and 64 bit) binaries

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

Hello

I have prepared gnuplot 5.0 alpha (cvs) cygwin (32 and 64 bit) binaries and uploaded on the web site:

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Enjoy

Tatsuro

Re: problem building QT for v5

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

On 05/11/2014 12:21 PM, pl...@pi... wrote:
> On 05/11/14 18:52, sfeam wrote:
[skip]
>>> Maybe whatever file it sources this from is incorrect.
>>> Where should I look to see what it's doing?
>>
>> Your pkg-config is apparently returning some garbage location.
>> Look for a file on your system named QtCore.pc and check what
>> it contains.  E.g.
>>
>> [1] locate QtCore.pc
>>       /usr/lib/pkgconfig/QtCore.pc
>> [2] cat /usr/lib/pkgconfig/QtCore.pc
>>       ...
>>
>>
>
> Thanks QtCore.pc contains the same incorrect (build) location .
>
> /usr/lib/qt4 exists but does not have bin or bin/uic..

What platform and architecture are you running on?  I'm running 64 bit 
so get:

config.log:LRELEASE='/usr/lib64/qt4/bin/lrelease'
config.log:MOC='/usr/lib64/qt4/bin/moc'
config.log:RCC='/usr/lib64/qt4/bin/rcc'
config.log:UIC='/usr/lib64/qt4/bin/uic'

Perhaps there are some directory remnants of an old qt4 on your system 
and the actual qt4 is installed elsewhere.

Dan

Re: problem building QT for v5

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

On 05/11/14 18:52, sfeam wrote:
>
> On Sunday, 11 May 2014 06:18:53 PM pl...@pi... wrote:
>> 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.
>
> I misunderstood your introduction:
>   "just tried to update to v5 and it barfed at the QT stage."
>
>> 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 ?
>
> It asks pkg-config, which is supposed to announce where things have
> been installed on your machine.  The key lines are these:
>        QT4LOC=`$PKG_CONFIG --variable=exec_prefix QtCore`
>        UIC=`$PKG_CONFIG --variable=uic_location QtCore`
>        MOC=`$PKG_CONFIG --variable=moc_location QtCore`
>        RCC=`$PKG_CONFIG --variable=rcc_location QtCore`
>        LRELEASE=`$PKG_CONFIG --variable=lrelease_location QtCore`
>        AC_MSG_WARN([The Qt terminal will use Qt4.])
>
> If I run this command here I get:
> [1] pkg-config --variable=uic_location QtCore
>      /usr/lib/qt4/bin/uic
>
>> Maybe whatever file it sources this from is incorrect.
>> Where should I look to see what it's doing?
>
> Your pkg-config is apparently returning some garbage location.
> Look for a file on your system named QtCore.pc and check what
> it contains.  E.g.
>
> [1] locate QtCore.pc
>      /usr/lib/pkgconfig/QtCore.pc
> [2] cat /usr/lib/pkgconfig/QtCore.pc
>      ...
>
>

Thanks QtCore.pc contains the same incorrect (build) location .

/usr/lib/qt4 exists but does not have bin or bin/uic..


It would have been interesting to test gnuplot's qt terminal but I don't 
have time to chase this down now.

Thanks for the the help. At least I  have an up to the minute gnuplot 
build now.

/Peter.

Re: problem building QT for v5

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

On Sunday, 11 May 2014 06:18:53 PM pl...@pi... wrote:
> 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.

I misunderstood your introduction:
 "just tried to update to v5 and it barfed at the QT stage."

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

It asks pkg-config, which is supposed to announce where things have
been installed on your machine.  The key lines are these:
      QT4LOC=`$PKG_CONFIG --variable=exec_prefix QtCore`
      UIC=`$PKG_CONFIG --variable=uic_location QtCore`
      MOC=`$PKG_CONFIG --variable=moc_location QtCore`
      RCC=`$PKG_CONFIG --variable=rcc_location QtCore`
      LRELEASE=`$PKG_CONFIG --variable=lrelease_location QtCore`
      AC_MSG_WARN([The Qt terminal will use Qt4.])

If I run this command here I get:
[1] pkg-config --variable=uic_location QtCore
    /usr/lib/qt4/bin/uic

> Maybe whatever file it sources this from is incorrect.
> Where should I look to see what it's doing?

Your pkg-config is apparently returning some garbage location.
Look for a file on your system named QtCore.pc and check what
it contains.  E.g.

[1] locate QtCore.pc
    /usr/lib/pkgconfig/QtCore.pc
[2] cat /usr/lib/pkgconfig/QtCore.pc
    ...