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

Time format data as a string?

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

I just used the time format in a plot.  It's nice, incorporating the 
date and time and all.  So thank you to whomever.

It did take me a bit to figure out though why something like this failed:

   set timefmt "%m/%d/%y %H:%M"
   plot "data" using 1:2

with data something like

03/03/16 11:30	23.5
03/03/16 11:45	24.8
...

It's because the datafile.c reading routine recognizes that first space 
as a delimiter such that field ':2' is actually 11 in both cases shown. 
  That's fine, as the following works:

   plot "data" using 1:3

and the documentation gives proper examples and all, if not explicitly 
stating.

However, it's a bit of a mental juxtaposition because the person 
scripting the code is thinking of the "03/03/16 11:30" as the "first" 
entry.  Now, gnuplot has string inputs, such as in energy_circles.dat of 
the demo subdirectory.  So, I'm wondering if the the date/time data 
entry could also accept a datafile string.  It shouldn't be too much of 
a C-code alteration.  For example, this might be the equivalent to the 
above:

   plot "data" using 1:2

with data

"03/03/16 11:30" 23.5
"03/03/16 11:45" 24.8
...

I tried that, and gnuplot doesn't allow it (no surprise, as it isn't 
documented to do so).  The way I see it, the user might be more inclined 
to think of date/time data in that fashion.

Dan

Re: a patch for giving limited number of points along a line

[KH.Moriyama <khm...@gm...>]

Hi, Ethan,

Thanks for reply.

> Could I ask you to upload your patch to the tracking page on
> SourceForge?
>
>         https://sourceforge.net/p/gnuplot/patches/

Sorry, I do not know how to upload a file there. But, you can
use the attached patch in anyway at your convenience.
I attach a modified patch to this mail for fix of the error message
in case of conflict with pointinterval, and the description
about "set ..." that was actually not correct.

> I will have a look at it in more detail, but as a first comment
> I think that randomizing the point placement is not a good idea.
> It makes the points jump around when you replot, zoom, or scroll.
> Also the output of a script would not be exactly reproducible.

Yes. I agree about that problem.
Maybe a better way is to add another parameter to set the
offset of the starting points or automatically change
the location of starting points according to the number of lines
plotted simultaneously. It seemed a little complicated.
The present way with the random number was simpler and so far
(for many years) I and some of my friends did not
have practical inconvenience.

mori

Re: a patch for giving limited number of points along a line

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

On Friday, 18 November, 2016 19:35:22 KH.Moriyama wrote:
> Hi.
> I am a long user of gnuplot but new to this ML.
> I want to inform about my patch. (the attached)

Could I ask you to upload your patch to the tracking page on
SourceForge?

	https://sourceforge.net/p/gnuplot/patches/

I will have a look at it in more detail, but as a first comment
I think that randomizing the point placement is not a good idea.
It makes the points jump around when you replot, zoom, or scroll.
Also the output of a script would not be exactly reproducible.

	Ethan

> 
> It adds a functionality "pointnumber" or "pn", which puts points
> along a line drawn by "linespoints" by given number of points.
> The result is similar to "pointinterval".
> But, it is more convenient because user can directly give
> the number of points appearing along a line without
> knowing the exact number of data points that makes the line.
> 
> The position starting to put points is moved randomly to avoid
> overstruck points.
> A negative number for the point number works as same as
> pointinterval, put spaces in the line at points.
> It returns error in case both "pi" and "pn" are specified.
> 
> I hope it is useful for everyone.
> 
> mori <khm...@gm...>

a patch for giving limited number of points along a line

[KH.Moriyama <khm...@gm...>]

Hi.
I am a long user of gnuplot but new to this ML.
I want to inform about my patch. (the attached)

It adds a functionality "pointnumber" or "pn", which puts points
along a line drawn by "linespoints" by given number of points.
The result is similar to "pointinterval".
But, it is more convenient because user can directly give
the number of points appearing along a line without
knowing the exact number of data points that makes the line.

The position starting to put points is moved randomly to avoid
overstruck points.
A negative number for the point number works as same as
pointinterval, put spaces in the line at points.
It returns error in case both "pi" and "pn" are specified.

I hope it is useful for everyone.

mori <khm...@gm...>

Re: several iterations in one plot result in sometimes missing/overwritten plots

[thse <t.s...@fz...>]

On Wed, Oct 26, 2016 at 11:40:33AM -0700, Ethan A Merritt wrote:

> But I also suspect that the "highest_iteration" check is not needed
> at all after the iteration mechanism was cleaned up last week.
> 
> Could you please test whether this test-patch causes any problems?
> If it doesn't then I think we can just get rid of highest_iteration.

No problems, it looks like "highest_iteration" is not needed.



--
View this message in context: http://gnuplot.10905.n7.nabble.com/several-iterations-in-one-plot-result-in-sometimes-missing-overwritten-plots-tp20412p20415.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: several iterations in one plot result in sometimes missing/overwritten plots

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

On Wednesday, 26 October, 2016 06:36:59 thse wrote:
> when using the "for" loop in a "plot" command several times, e.g.
> plot for [i=1:3] x-i, for [j=1:2] x-j-5
> the last "for" loop sets the internal variable "highest_iteration"
> in "plot2d.c" which results in missing plots when the preceding
> loops have more iterations.
> 
> example (the second plot shows the error):
> 
> reset
> set xrange [-10:10]
> set yrange [-10:10]
> plot for [i=1:3] x-i title "i=".i, for [j=1:3] x-j-5 title "j=".j
> pause -1
> plot for [i=1:3] x-i title "i=".i, for [j=1:2] x-j-5 title "j=".j
> 
> adding two lines to "plot2d.c" repairs this.
> 
> --- plot2d.c.orig       2016-09-28 00:00:09.000000000 +0200
> +++ plot2d.c    2016-10-26 16:40:50.238197804 +0200
> @@ -2966,11 +2966,13 @@
>         if (empty_iteration(plot_iterator) && this_plot) {
>             this_plot->plot_type = NODATA;
>         } else if (forever_iteration(plot_iterator) && (this_plot->plot_type
> == NODATA)) {
> +           if (plot_iterator->iteration > highest_iteration)
>             highest_iteration = plot_iterator->iteration;
>         } else if (forever_iteration(plot_iterator) && (this_plot->plot_type
> == FUNC)) {
>             int_error(NO_CARET,"unbounded iteration in function plot");
>         } else if (next_iteration(plot_iterator)) {
>             c_token = start_token;
> +           if (plot_iterator->iteration > highest_iteration)
>             highest_iteration = plot_iterator->iteration;
>             continue;
>         }

I will apply the patch since it clearly fixes a problem.

But I also suspect that the "highest_iteration" check is not needed
at all after the iteration mechanism was cleaned up last week.

Could you please test whether this test-patch causes any problems?
If it doesn't then I think we can just get rid of highest_iteration.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
--- gnuplot/src/plot2d.c	2016-09-27 15:00:09.000000000 -0700
+++ gnuplot-cvs/src/plot2d.c	2016-10-26 11:33:32.370040018 -0700
@@ -3335,10 +3337,8 @@ eval_plots()
 
 	    /* Iterate-over-plot mechanism */
 	    if (next_iteration(plot_iterator)) {
-		if (plot_iterator->iteration <= highest_iteration) {
 		    c_token = start_token;
 		    continue;
-		}
 	    }
 
 	    plot_iterator = cleanup_iteration(plot_iterator);
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

	Ethan

Re: several iterations in one plot result in sometimes missing/overwritten plots

[thse <t.s...@fz...>]

I uploaded the patch to sourceforge.



--
View this message in context: http://gnuplot.10905.n7.nabble.com/several-iterations-in-one-plot-result-in-sometimes-missing-overwritten-plots-tp20412p20413.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

several iterations in one plot result in sometimes missing/overwritten plots

[thse <t.s...@fz...>]

when using the "for" loop in a "plot" command several times, e.g.
plot for [i=1:3] x-i, for [j=1:2] x-j-5
the last "for" loop sets the internal variable "highest_iteration"
in "plot2d.c" which results in missing plots when the preceding
loops have more iterations.

example (the second plot shows the error):

reset
set xrange [-10:10]
set yrange [-10:10]
plot for [i=1:3] x-i title "i=".i, for [j=1:3] x-j-5 title "j=".j
pause -1
plot for [i=1:3] x-i title "i=".i, for [j=1:2] x-j-5 title "j=".j

adding two lines to "plot2d.c" repairs this.

--- plot2d.c.orig       2016-09-28 00:00:09.000000000 +0200
+++ plot2d.c    2016-10-26 16:40:50.238197804 +0200
@@ -2966,11 +2966,13 @@
        if (empty_iteration(plot_iterator) && this_plot) {
            this_plot->plot_type = NODATA;
        } else if (forever_iteration(plot_iterator) && (this_plot->plot_type
== NODATA)) {
+           if (plot_iterator->iteration > highest_iteration)
            highest_iteration = plot_iterator->iteration;
        } else if (forever_iteration(plot_iterator) && (this_plot->plot_type
== FUNC)) {
            int_error(NO_CARET,"unbounded iteration in function plot");
        } else if (next_iteration(plot_iterator)) {
            c_token = start_token;
+           if (plot_iterator->iteration > highest_iteration)
            highest_iteration = plot_iterator->iteration;
            continue;
        }



--
View this message in context: http://gnuplot.10905.n7.nabble.com/several-iterations-in-one-plot-result-in-sometimes-missing-overwritten-plots-tp20412.html
Sent from the Gnuplot - Dev mailing list archive at Nabble.com.

Re: pre-release Testing tarball for version 5.0.5

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

On Tue, Oct 11, 2016 at 5:07 AM, Frantisek Kluknavsky <fkl...@re...>
wrote:

> On 07/10/16 06:03, Dmitri A. Sergatskov wrote:
> ...
> > ​Fedora 25 provided gnuplot 4.0.2  and it has the same problem.​
> ...
>
> Just to avoid confusion:
> Fedora 25 has gnuplot 5.0.3 built with qt5.
> Fedora 24 has gnuplot 5.0.3 built with qt4.
> Fedora 23 has gnuplot 5.0.1.
>
>
>
​I could not believe i typed that. I meant "gnuplot 5.0.3"

Dmitri.
-- 
 ​

Re: pre-release Testing tarball for version 5.0.5

[Frantisek K. <fkl...@re...>]

On 07/10/16 06:03, Dmitri A. Sergatskov wrote:
...
> ​Fedora 25 provided gnuplot 4.0.2  and it has the same problem.​
...

Just to avoid confusion:
Fedora 25 has gnuplot 5.0.3 built with qt5.
Fedora 24 has gnuplot 5.0.3 built with qt4.
Fedora 23 has gnuplot 5.0.1.

Re: gnuplot 5.0 not recognizing aqua term on macOS

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

On 11 October 2016 at 04:00, Daniel J Sebald wrote:
> On 10/10/2016 08:50 PM, Brian Weitzner wrote:
>> Hello,
>>
>> I recently upgraded my machine to macOS Sierra, and reinstalled gnuplot
>> and aqua term via macports. Upon launching gnuplot, I get the following
>> message:
>
> You said "installed", so I'm guessing you didn't run a build.

Due to a somewhat weird licence of gnuplot there are no binaries
available, so gnuplot must have been built from source on his machine.

> If you
> ran a build, one could look at the config.log file to see why the
> terminal was not compiled (and then for example make sure the necessary
> libraries/utilities are present on your new system).

Indeed, please provide config.log from the gnuplot's build directory.

(I'm unable to reproduce the problem.)

Mojca

Re: gnuplot 5.0 not recognizing aqua term on macOS

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

On 10/10/2016 08:50 PM, Brian Weitzner wrote:
> Hello,
>
> I recently upgraded my machine to macOS Sierra, and reinstalled gnuplot
> and aqua term via macports. Upon launching gnuplot, I get the following
> message:

You said "installed", so I'm guessing you didn't run a build.  If you 
ran a build, one could look at the config.log file to see why the 
terminal was not compiled (and then for example make sure the necessary 
libraries/utilities are present on your new system).  Otherwise, you'll 
have to contact the person who build the executable for some help.

Does "help term" list the aqua terminal?  (I'm guessing not, but doesn't 
hurt to check.)

Dan



> Unknown or ambiguous terminal name 'aqua'
>
> G N U P L O T
> Version 5.0 patchlevel 4    last modified 2016-07-21
>
> Copyright (C) 1986-1993, 1998, 2004, 2007-2016
> Thomas Williams, Colin Kelley and many others
>
> gnuplot home: http://www.gnuplot.info
> faq, bugs, etc:   type "help FAQ"
> immediate help:   type "help"  (plot window: hit 'h')
>
> Terminal type set to ‘unknown'
>
> And then, of course, plotting doesn’t work. (WARNING: Plotting with an
> 'unknown' terminal. No output will be generated. Please select a
> terminal with 'set terminal’.) I’m a bit stumped as to how to proceed
> from here, and this is kind of a showstopper for me. Any ideas?
>
> --
> Brian D. Weitzner
> WRF Innovation Postdoctoral Fellow
> Institute for Protein Design
> University of Washington
> Seattle, Washington 98185
> http://www.ipd.uw.edu
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

-- 

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

gnuplot 5.0 not recognizing aqua term on macOS

[Brian W. <bri...@gm...>]

Hello,

I recently upgraded my machine to macOS Sierra, and reinstalled gnuplot and aqua term via macports. Upon launching gnuplot, I get the following message:

Unknown or ambiguous terminal name 'aqua'

	G N U P L O T
	Version 5.0 patchlevel 4    last modified 2016-07-21 

	Copyright (C) 1986-1993, 1998, 2004, 2007-2016
	Thomas Williams, Colin Kelley and many others

	gnuplot home:     http://www.gnuplot.info <http://www.gnuplot.info/>
	faq, bugs, etc:   type "help FAQ"
	immediate help:   type "help"  (plot window: hit 'h')

Terminal type set to ‘unknown'

And then, of course, plotting doesn’t work. (WARNING: Plotting with an 'unknown' terminal. No output will be generated. Please select a terminal with 'set terminal’.) I’m a bit stumped as to how to proceed from here, and this is kind of a showstopper for me. Any ideas?

-- 
Brian D. Weitzner
WRF Innovation Postdoctoral Fellow
Institute for Protein Design 
University of Washington
Seattle, Washington 98185
http://www.ipd.uw.edu <http://www.ipd.uw.edu/>

Re: Unwanted line toggle on mouse click events

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

On Sunday, 09 October 2016 12:26:27 PM pl...@pi... wrote:
> Hi,
> 
> I have noticed a small  defect in toggling line visibility from the 
> keybox: it can interfere with other mouse functionality.
> 
> It seems that any mouse click event : left , right or middle will toggle 
> visibility if it happens on a active part of the legend. This result in 
> two things in the case fo right-mouse and 3rd-button / scroll-wheel 
> click events.

Fixed in January 2016 for both 5.0 and 5.1
The fix first appeared in a release version in 5.0.3 (Feb 2016)

	Ethan



> 
> 3rd button will stamp mouse coords on top of the legend at the same time 
> as greying the legend and toggling the line. I doubt that either result 
> is that useful.
> 
> A right click as the first point in selecting a new zoom for the plot 
> also triggers the line toggle. I think in this case it is fair to assume 
> that user did not intend to do both and the result is undesirable.
> 
> 
> The obvious fix would seem to be only triggering the line toggle on 
> left-button clicks.
> 
> This defect was seen on qt-terminal on 5.0.1. I have not tested other 
> terminals.
> 
> Is this the way it is intended to work , an oversight or a possible bug 
> on this terminal ?
> 
> Best regards. Peter.
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Release 5.0.5 (version 5.0 patchlevel 5)

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

Source tarball for version 5.0.5 is now available on SourceForge

Release notes:
	 http://gnuplot.sourceforge.net/ReleaseNotes_5_0_5.html

                GNUPLOT Version 5.0.5 Release Notes
                ===================================

Gnuplot version 5.0 was initially released in January 2015.
Please see the NEWS and ChangeLog files for a complete list of bug fixes
and minor changes accummulated since then.

These release notes are for version 5.0 patchlevel 5 (5.0.5).
This release contains bug-fixes, a few changes back-ported from the
development version, and a few new features.

Release Notes date: 10-Oct-2016

This patchlevel 5.0.5 incremental release includes
==================================================

* NEW allow filename completion for system commands and pipes (backport from 5.1)
* NEW option to plot with labels {rotate variable}
* NEW command "set minussign"
* NEW stats command "name" option now accepts "columnheader" or "columnheader(N)"
* NEW command option "set colorbox invert"
* CHANGE qt terminal force selection of outline font rather than bitmap font
* CHANGE post terminal simplex/duplex output depends on PostScript level setting
* CHANGE improved autoscaling of plot "with boxes"
* CHANGE qt terminal sets TERM_POLYGON_PIXELS to avoid aliasing artifacts
* CHANGE all stats and fit commands skip header records if "autotitle columnhead"
* FIX Do not confuse EOF with 8-bit character 0x177 (E.g. in Cyrillic encodings).
* FIX use blank line rather than 'u' flag in "set table" output of smoothed data
* FIX order dependence of "fillcolor" keyword in plot commands
* FIX svg - better vertical justification of rotated text
* FIX wxt - file export widget correctly handles inactive plots
* FIX qt - preserve leading and trailing whitespace in enhanced text strings
* FIX various bugs affecting matrix data plotted "with image"

NOTABLE NEW FEATURES IN PATCHLEVEL 5.0.5
========================================

New command "set minussign" uses unicode character U+2122 "MINUS SIGN" rather
than an ascii hyphen when formatting numerical output.

Unwanted line toggle on mouse click events

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

Hi,

I have noticed a small  defect in toggling line visibility from the 
keybox: it can interfere with other mouse functionality.

It seems that any mouse click event : left , right or middle will toggle 
visibility if it happens on a active part of the legend. This result in 
two things in the case fo right-mouse and 3rd-button / scroll-wheel 
click events.

3rd button will stamp mouse coords on top of the legend at the same time 
as greying the legend and toggling the line. I doubt that either result 
is that useful.

A right click as the first point in selecting a new zoom for the plot 
also triggers the line toggle. I think in this case it is fair to assume 
that user did not intend to do both and the result is undesirable.


The obvious fix would seem to be only triggering the line toggle on 
left-button clicks.

This defect was seen on qt-terminal on 5.0.1. I have not tested other 
terminals.

Is this the way it is intended to work , an oversight or a possible bug 
on this terminal ?

Best regards. Peter.

Gnuplot 5.x vs. 4.x: persist option

[Achim G. <Str...@ne...>]

I've just realized that the persist feature has lost some functionality
in the transition from 4.x to 5.x.  I've tried both the Qt and X11
terminal, they behave the same in that respect.

$ gnuplot -p -e 'plot sin(x)'

With 4.x, resizing the window after the gnuplot main process has exited
will fit the existing plot to the window.  That doesn't work with 5.x
anymore, it seems to try to keep the aspect ratio of the plot.

Is there an option I've not found that re-enables that feature or is
that a regression that could be fixed?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: pre-release Testing tarball for version 5.0.5

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

On Fri, Oct 7, 2016 at 12:12 AM, sfeam <sf...@us...> wrote:

>
> > ​I recompiled against qt-4.8.7 and it works fine (no crash).
>
> If it's just the Qt version that is at issue, I will probably run into it
> myself
> eventually.  But it may be a while before I have a system with Qt > 5.6
>
> I suppose it would be informative if you could rule out wayland or the
> gnome desktop.  Can you run the problematic gnuplot executable
> under an alternative window manager (Xfce or LXDE  etc)?
>

​It works fine on Plasma  or Gnome/X11 so Wayland is suspect,
but a counterargument is that e.g. octave-gui built on the same computer
against the same Qt-5.7.0 runs fine -- e.g. the file selection windows on
its qscintilla component works just fine. ​

​I filed bugzilla report on fedora -- may be something comes out of it.
​https://bugzilla.redhat.com/show_bug.cgi?id=1382576



>         Ethan
>
>
​Dmitri.
​

Re: pre-release Testing tarball for version 5.0.5

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

On Thursday, 06 October 2016 11:16:15 PM Dmitri A. Sergatskov wrote:
> On Thu, Oct 6, 2016 at 9:46 PM, sfeam <sf...@us...> wrote:
> 
> > On Thursday, 06 October 2016 05:45:19 PM Dmitri A. Sergatskov wrote:
> > > On Sun, Oct 2, 2016 at 1:51 PM, sfeam <sf...@us...>
> > wrote:
> > >
> > > > If no last-minute problems are found, I plan to release gnuplot 5.0.5
> > > > (version 5.0 patchlevel 5) in a week or so.
> > >
> > > ​On gnome/Wayland (Fedora 25 alpha)
> > > qt terminal crashes if I select "Export to PDF" or "Export to SVG":
> > >
> >
> > Definitely not something that's going to get fixed before release of 5.0.5
> > but if you open a bug tracker item we will try to deal with it.
> >
> > It would probably help to know what versions of qt, etc.
> >
> >
> ​I recompiled against qt-4.8.7 and it works fine (no crash).

If it's just the Qt version that is at issue, I will probably run into it myself
eventually.  But it may be a while before I have a system with Qt > 5.6

I suppose it would be informative if you could rule out wayland or the
gnome desktop.  Can you run the problematic gnuplot executable
under an alternative window manager (Xfce or LXDE  etc)?

	Ethan

Re: pre-release Testing tarball for version 5.0.5

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

On Thu, Oct 6, 2016 at 9:46 PM, sfeam <sf...@us...> wrote:

> On Thursday, 06 October 2016 05:45:19 PM Dmitri A. Sergatskov wrote:
> > On Sun, Oct 2, 2016 at 1:51 PM, sfeam <sf...@us...>
> wrote:
> >
> > > If no last-minute problems are found, I plan to release gnuplot 5.0.5
> > > (version 5.0 patchlevel 5) in a week or so.
> >
> > ​On gnome/Wayland (Fedora 25 alpha)
> > qt terminal crashes if I select "Export to PDF" or "Export to SVG":
> >
>
> Definitely not something that's going to get fixed before release of 5.0.5
> but if you open a bug tracker item we will try to deal with it.
>
> It would probably help to know what versions of qt, etc.
>
>
​I recompiled against qt-4.8.7 and it works fine (no crash).

Dmitri.
-- 
​

Re: pre-release Testing tarball for version 5.0.5

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

On Thu, Oct 6, 2016 at 9:46 PM, sfeam <sf...@us...> wrote:

> On Thursday, 06 October 2016 05:45:19 PM Dmitri A. Sergatskov wrote:
> > On Sun, Oct 2, 2016 at 1:51 PM, sfeam <sf...@us...>
> wrote:
> >
> > > If no last-minute problems are found, I plan to release gnuplot 5.0.5
> > > (version 5.0 patchlevel 5) in a week or so.
> >
> > ​On gnome/Wayland (Fedora 25 alpha)
> > qt terminal crashes if I select "Export to PDF" or "Export to SVG":
> >
>
> Definitely not something that's going to get fixed before release of 5.0.5
> but if you open a bug tracker item we will try to deal with it.
>

​Sure.​



>
> It would probably help to know what versions of qt, etc.
>
>
​This was Qt5.7.0



>  > (gnuplot_qt:20095): Gdk-WARNING **: gdkwindow-x11.c:5554 drawable is
> not a
> > native X11 window
> > Error: plot window (gnuplot_qt) not responding - will restart
>
> That seems really odd, because why would gnuplot_qt be calling into a
> gdk/gtk library?   As built here, the gnuplot_qt executable does not
> contain a symbol
> entry for gdkwindow-x11, although the wxt/cairo code in the main gnuplot
> executable
> does.  Furthermore, the pkg-config files for Qt 5.4.2 do not list any gdk
> library requirements.
> Has this changed in a newer version of Qt?
>
>
​I am guessing here, but I think that message is from Gnome desktop. The
crash happens
while qt  was trying to pop up the file selection window (after clicking on
"Export to PDF").​


> > (The same happens with earlier versions).
>
> Do you mean earlier versions of gnuplot run on Fedora 25,
> or do you mean earlier versions of Fedora, or what exactly?
>
>
​Fedora 25 provided gnuplot 4.0.2  and it has the same problem.​


>         Ethan
>
> >
> > Dmitri.
> > --
>
>
​Dmitri.
-- 
​

Re: pre-release Testing tarball for version 5.0.5

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

On Thursday, 06 October 2016 05:45:19 PM Dmitri A. Sergatskov wrote:
> On Sun, Oct 2, 2016 at 1:51 PM, sfeam <sf...@us...> wrote:
> 
> > If no last-minute problems are found, I plan to release gnuplot 5.0.5
> > (version 5.0 patchlevel 5) in a week or so.
> 
> ​On gnome/Wayland (Fedora 25 alpha)
> qt terminal crashes if I select "Export to PDF" or "Export to SVG":
>

Definitely not something that's going to get fixed before release of 5.0.5
but if you open a bug tracker item we will try to deal with it.

It would probably help to know what versions of qt, etc.

 > (gnuplot_qt:20095): Gdk-WARNING **: gdkwindow-x11.c:5554 drawable is not a
> native X11 window
> Error: plot window (gnuplot_qt) not responding - will restart

That seems really odd, because why would gnuplot_qt be calling into a
gdk/gtk library?   As built here, the gnuplot_qt executable does not contain a symbol
entry for gdkwindow-x11, although the wxt/cairo code in the main gnuplot executable
does.  Furthermore, the pkg-config files for Qt 5.4.2 do not list any gdk library requirements.
Has this changed in a newer version of Qt?
 
> (The same happens with earlier versions).

Do you mean earlier versions of gnuplot run on Fedora 25,
or do you mean earlier versions of Fedora, or what exactly?

	Ethan

> 
> Dmitri.
> --

Re: pre-release Testing tarball for version 5.0.5

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

On Sun, Oct 2, 2016 at 1:51 PM, sfeam <sf...@us...> wrote:

> If no last-minute problems are found, I plan to release gnuplot 5.0.5
> (version 5.0 patchlevel 5) in a week or so.
>


​On gnome/Wayland (Fedora 25 alpha)
qt terminal crashes if I select "Export to PDF" or "Export to SVG":

(gnuplot_qt:20095): Gdk-WARNING **: gdkwindow-x11.c:5554 drawable is not a
native X11 window
Error: plot window (gnuplot_qt) not responding - will restart

(The same happens with earlier versions).

Dmitri.
--

Re: compiling on 32-bit mingw

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

Am 03.10.2016 um 10:37 schrieb Bastian Märkisch:
> Sigh. MinGW32 is falling behind rather seriously. IPrintDialogCallback
> and friends have been part of the API since Windows 2000 Pro according
> to MSDN. Mingw32 is currently also lacking support for several other
> "modern" APIs like Direct2D, DirectWrite and touch, which gnuplot might
> use in the near future. This is also not the only development
> environment with that problem: OpenWatcom's library is seriously out of
> date, too.

I think you're misinterpreting the symptoms there.  I don't have MinGW32 
installed anymore, but at least OpenWatcom has no actual problem with 
current gnuplot sources.

The only stumbling stone has been that the definition of WINVER in our 
source trees has been broken: it's not seen where it's needed.  The 
definition in "syscfg.h" doesn't do us any good for sources that don't 
include syscfg.h.

> Btw. Mingw64 and MSVC2015 compile gnuplot just fine

As does OW as of right now.

Re: compiling on 32-bit mingw

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

On Mon, 3 Oct 2016, Bastian Märkisch wrote:

> Am 03.10.2016 um 10:53 schrieb Mojca Miklavec:
>> On 3 October 2016 at 10:37, Bastian Märkisch wrote:
>>> Sigh. MinGW32 is falling behind rather seriously. IPrintDialogCallback
>>> and friends have been part of the API since Windows 2000 Pro according
>>> to MSDN. Mingw32 is currently also lacking support for several other
>>> "modern" APIs like Direct2D, DirectWrite and touch, which gnuplot might
>>> use in the near future. This is also not the only development
>>> environment with that problem: OpenWatcom's library is seriously out of
>>> date, too.
>>>
>>> To fix compilation with MinGW32 for now, we could add the old code back
>>> along with a number of #ifdef's, or extract the missing definitions from
>>> MSDN and add them to the our code (easily around 100 lines), or #ifdef
>>> out the affected code and functionality.
>>>
>>> Btw. Mingw64 and MSVC2015 compile gnuplot just fine.
>>
>> This is not my area of expertise, but isn't MinGW-w64 a suitable
>> replacement for MinGW32?
>>
>> I kind-of gave up on the original MinGW32, in particular in the area
>> of cross-compiling. MinGW-w64 seems much better supported and more
>> up-to-date (not to even mention the ability to create 64-bit
>> binaries).
>>
>> It would be one thing to exclude everyone without MSVC. That would be
>> a bit sad. But I don't find it problematic to ask *developers* (the
>> few people who actually know how to compile under Windows and how to
>> get all the dependencies working) to switch to a different OpenSource
>> toolchain, in particular if supporting the "old" toolchain causes
>> additional headaches and more ugly code.
>>
>> If gnuplot compiles fine under MinGW-w64, I don't see any reason to
>> use ugly workarounds in the code just for the sake of supporting an
>> alternative tool that lags behind.
>>
>> Mojca
>>
>
> Agreed. Except that MinGW32 was the recommended toolchain until 
> recently. So we shouldn't give up too quickly.
> Allin, aren't you using Mingw64 for 64bit builds already?

Yes, I am. And I could build a 32-bit toolchain under Mingw64. My 
observation was not really intended as a complaint, rather a query 
as to whether mingw32 is still considered a supported build target.

One other related observation: src/win/wprinter.c has

#include <OCIdl.h>

This header will not be found on mingw, but it is found OK if named
as ocidl.h.

Allin Cottrell