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

Re: GTK+ 2 specific code inside wx terminal

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

On 5 January 2016 at 06:03, sfeam <sf...@us...> wrote:
> On Monday, 04 January 2016 09:58:36 PM Mojca Miklavec wrote:
>> On 4 January 2016 at 21:30, Ethan A Merritt wrote:
>> > On Monday, 04 January, 2016 11:53:37 Mojca Miklavec wrote:
>> >
>> >> Hi,
>> >>
>> >> I would like to ask for a bit of help with fixing some opportunistical
>> >> linking against GTK+ when wxWidgets is used:
>> >> https://trac.macports.org/ticket/50199
>> >>
>> >> The problem is that as soon as pkg-config finds GTK+ version 2 on the
>> >> system and if wxWidgets terminal is enabled, gnuplot links against
>> >> GTK2 even if no GTK code is being used at all. And if wxWidgets uses
>> >> GTK 3, compilation fails because gnuplot tries to call some functions
>> >> that no longer exist in GTK 3.
>> >
>> >
>> >
>> > We've had this conversation before.
>>
>> I'm sorry, I missed that.
>>
>> > The answer to that latter issue (gdk_window_foreign_new not in gtk3)
>> > is to configure with --disable-raise-console. Or if you could comment
>> > out or remove that section of code just for wxt since it obviously isn't
>> > going to work anyhow.
>>
>> I don't want to patch this (comment it out) just on MacPorts because
>> MacPorts doesn't provide GTK-based wxWidgets inside gnuplot.
>>
>> But it would be wise to provide "universal" patch that doesn't attempt
>> to use GTK 2 functions inside GTK 3 (I can try to help with that if
>> needed).
>>
>> > As to OSX + wxwidgets not requiring gtk at all, I would be happy
>> > to take a patch that sorted this out in the autoconf script.
>> > I suppose it would test the output of
>> >
>> > wx-config --query-toolkit
>> >
>> > What does that return on OSX?
>>
>> I have three different installations of wxWidgets:
>> - wxWidgets 3.0 built against Cocoa
>> - wxWidgets 3.0 built against GTK 3
>> - wxWidgets 2.8 built against GTK 2
>>
>> Here are the results:
>>
>> $ /path/to/wxWidgets/3.0/bin/wx-config --query-toolkit
>> osx_cocoa
>> $ /path/to/wxGTK/3.0/bin/wx-config --query-toolkit
>> gtk3
>> $ /path/to/wxGTK/2.8/bin/wx-config --query-toolkit
>> gtk2
>>
>> I assume you should only accept "gtk2".
>
> Why?  Do you know that gtk3 doesn't work?

Because I get
    error: use of undeclared identifier 'gdk_window_foreign_new'
when I use gtk3 (but you just said that you get the same problem with gtk2).

> Please try the attached patch for configure.ac

I'm confused. What about the fact that gdk_window_foreign_new()
doesn't seem to work at all?

Apart from that I like the first part of the patch with
    if test "${WX_TOOLKIT}" = gtk2 ; then
but I don't like this test for gtk+-2.0:
    PKG_CHECK_MODULES(GTK, [gtk+-2.0], have_gtk=yes, have_gtk=no)
even if gtk3 is known to be used.

In my opinion it should be
    if test "${WX_TOOLKIT}" = gtk2 ; then
        PKG_CHECK_MODULES(GTK, [gtk+-2.0], ..., ...)
        AC_DEFINE(...)
        WX_CXXFLAGS=...
        WX_LIBS=...
   elif test "${WX_TOOLKIT}" = gtk3 ; then
        PKG_CHECK_MODULES(GTK, [gtk+-3.0], ..., ...)
        AC_DEFINE(...)
        WX_CXXFLAGS=...
        WX_LIBS=...
   fi

Mojca

Re: GTK+ 2 specific code inside wx terminal

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

On Monday, 04 January 2016 09:58:36 PM Mojca Miklavec wrote:
> On 4 January 2016 at 21:30, Ethan A Merritt wrote:
> > On Monday, 04 January, 2016 11:53:37 Mojca Miklavec wrote:
> >
> >> Hi,
> >>
> >> I would like to ask for a bit of help with fixing some opportunistical
> >> linking against GTK+ when wxWidgets is used:
> >> https://trac.macports.org/ticket/50199
> >>
> >> The problem is that as soon as pkg-config finds GTK+ version 2 on the
> >> system and if wxWidgets terminal is enabled, gnuplot links against
> >> GTK2 even if no GTK code is being used at all. And if wxWidgets uses
> >> GTK 3, compilation fails because gnuplot tries to call some functions
> >> that no longer exist in GTK 3.
> >
> >
> >
> > We've had this conversation before.
> 
> I'm sorry, I missed that.
> 
> > The answer to that latter issue (gdk_window_foreign_new not in gtk3)
> > is to configure with --disable-raise-console. Or if you could comment
> > out or remove that section of code just for wxt since it obviously isn't
> > going to work anyhow.
> 
> I don't want to patch this (comment it out) just on MacPorts because
> MacPorts doesn't provide GTK-based wxWidgets inside gnuplot.
> 
> But it would be wise to provide "universal" patch that doesn't attempt
> to use GTK 2 functions inside GTK 3 (I can try to help with that if
> needed).
> 
> > As to OSX + wxwidgets not requiring gtk at all, I would be happy
> > to take a patch that sorted this out in the autoconf script.
> > I suppose it would test the output of
> >
> > wx-config --query-toolkit
> >
> > What does that return on OSX?
> 
> I have three different installations of wxWidgets:
> - wxWidgets 3.0 built against Cocoa
> - wxWidgets 3.0 built against GTK 3
> - wxWidgets 2.8 built against GTK 2
> 
> Here are the results:
> 
> $ /path/to/wxWidgets/3.0/bin/wx-config --query-toolkit
> osx_cocoa
> $ /path/to/wxGTK/3.0/bin/wx-config --query-toolkit
> gtk3
> $ /path/to/wxGTK/2.8/bin/wx-config --query-toolkit
> gtk2
> 
> I assume you should only accept "gtk2".

Why?  Do you know that gtk3 doesn't work?

Please try the attached patch for configure.ac

    Ethan




> 
> (Please note that it is *possible* to build wxWidgets against GTK2, it
> just isn't the default configuration and it would rarely be used under
> any normal circumstances. We use it for software that didn't bother
> switching to wxWidgets 3.0 yet because wxWidgets 2.8 doesn't work
> natively on modern versions of OS X. So you should generally not use
> "if this is OS X", but rather check if "--query-toolkit" would return
> gtk2.)
> 
> Mojca

Re: GTK+ 2 specific code inside wx terminal

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

On Monday, 04 January, 2016 21:58:36 Mojca Miklavec wrote:
> On 4 January 2016 at 21:30, Ethan A Merritt wrote:
> > On Monday, 04 January, 2016 11:53:37 Mojca Miklavec wrote:
> >
> >> Hi,
> >>
> >> I would like to ask for a bit of help with fixing some opportunistical
> >> linking against GTK+ when wxWidgets is used:
> >> https://trac.macports.org/ticket/50199
> >>
> >> The problem is that as soon as pkg-config finds GTK+ version 2 on the
> >> system and if wxWidgets terminal is enabled, gnuplot links against
> >> GTK2 even if no GTK code is being used at all. And if wxWidgets uses
> >> GTK 3, compilation fails because gnuplot tries to call some functions
> >> that no longer exist in GTK 3.
> >
> >
> >
> > We've had this conversation before.
> 
> I'm sorry, I missed that.
> 
> > The answer to that latter issue (gdk_window_foreign_new not in gtk3)
> > is to configure with --disable-raise-console. Or if you could comment
> > out or remove that section of code just for wxt since it obviously isn't
> > going to work anyhow.
> 
> I don't want to patch this (comment it out) just on MacPorts because
> MacPorts doesn't provide GTK-based wxWidgets inside gnuplot.
> 
> But it would be wise to provide "universal" patch that doesn't attempt
> to use GTK 2 functions inside GTK 3 (I can try to help with that if
> needed).

Hmm.  As it turns out, it doesn't work for me with current GTK2 either
unless I enable deprecated API components.

My build script always disables raise-console, so I never noticed this before.  
When I enable raise-console I get:
wxterminal/wxt_gui.cpp:1537:51: error: ‘gdk_window_foreign_new’ was not declared in this scope
wxterminal/wxt_gui.cpp:3170:48: error: ‘GtkWidget’ has no member named ‘window’
wxterminal/wxt_gui.cpp:3183:47: error: ‘GtkWidget’ has no member named ‘window’

Those API components must have been deprecated at some 
point during the gtk2 release series.  I'll look into it.

	Ethan

> 
> > As to OSX + wxwidgets not requiring gtk at all, I would be happy
> > to take a patch that sorted this out in the autoconf script.
> > I suppose it would test the output of
> >
> > wx-config --query-toolkit
> >
> > What does that return on OSX?
> 
> I have three different installations of wxWidgets:
> - wxWidgets 3.0 built against Cocoa
> - wxWidgets 3.0 built against GTK 3
> - wxWidgets 2.8 built against GTK 2
> 
> Here are the results:
> 
> $ /path/to/wxWidgets/3.0/bin/wx-config --query-toolkit
> osx_cocoa
> $ /path/to/wxGTK/3.0/bin/wx-config --query-toolkit
> gtk3
> $ /path/to/wxGTK/2.8/bin/wx-config --query-toolkit
> gtk2
> 
> I assume you should only accept "gtk2".
> 
> (Please note that it is *possible* to build wxWidgets against GTK2, it
> just isn't the default configuration and it would rarely be used under
> any normal circumstances. We use it for software that didn't bother
> switching to wxWidgets 3.0 yet because wxWidgets 2.8 doesn't work
> natively on modern versions of OS X. So you should generally not use
> "if this is OS X", but rather check if "--query-toolkit" would return
> gtk2.)
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: GTK+ 2 specific code inside wx terminal

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

On 4 January 2016 at 21:30, Ethan A Merritt wrote:
> On Monday, 04 January, 2016 11:53:37 Mojca Miklavec wrote:
>
>> Hi,
>>
>> I would like to ask for a bit of help with fixing some opportunistical
>> linking against GTK+ when wxWidgets is used:
>> https://trac.macports.org/ticket/50199
>>
>> The problem is that as soon as pkg-config finds GTK+ version 2 on the
>> system and if wxWidgets terminal is enabled, gnuplot links against
>> GTK2 even if no GTK code is being used at all. And if wxWidgets uses
>> GTK 3, compilation fails because gnuplot tries to call some functions
>> that no longer exist in GTK 3.
>
>
>
> We've had this conversation before.

I'm sorry, I missed that.

> The answer to that latter issue (gdk_window_foreign_new not in gtk3)
> is to configure with --disable-raise-console. Or if you could comment
> out or remove that section of code just for wxt since it obviously isn't
> going to work anyhow.

I don't want to patch this (comment it out) just on MacPorts because
MacPorts doesn't provide GTK-based wxWidgets inside gnuplot.

But it would be wise to provide "universal" patch that doesn't attempt
to use GTK 2 functions inside GTK 3 (I can try to help with that if
needed).

> As to OSX + wxwidgets not requiring gtk at all, I would be happy
> to take a patch that sorted this out in the autoconf script.
> I suppose it would test the output of
>
> wx-config --query-toolkit
>
> What does that return on OSX?

I have three different installations of wxWidgets:
- wxWidgets 3.0 built against Cocoa
- wxWidgets 3.0 built against GTK 3
- wxWidgets 2.8 built against GTK 2

Here are the results:

$ /path/to/wxWidgets/3.0/bin/wx-config --query-toolkit
osx_cocoa
$ /path/to/wxGTK/3.0/bin/wx-config --query-toolkit
gtk3
$ /path/to/wxGTK/2.8/bin/wx-config --query-toolkit
gtk2

I assume you should only accept "gtk2".

(Please note that it is *possible* to build wxWidgets against GTK2, it
just isn't the default configuration and it would rarely be used under
any normal circumstances. We use it for software that didn't bother
switching to wxWidgets 3.0 yet because wxWidgets 2.8 doesn't work
natively on modern versions of OS X. So you should generally not use
"if this is OS X", but rather check if "--query-toolkit" would return
gtk2.)

Mojca

Re: GTK+ 2 specific code inside wx terminal

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

On Monday, 04 January, 2016 11:53:37 Mojca Miklavec wrote:
> Hi,
> 
> I would like to ask for a bit of help with fixing some opportunistical
> linking against GTK+ when wxWidgets is used:
>     https://trac.macports.org/ticket/50199
> 
> The problem is that as soon as pkg-config finds GTK+ version 2 on the
> system and if wxWidgets terminal is enabled, gnuplot links against
> GTK2 even if no GTK code is being used at all. And if wxWidgets uses
> GTK 3, compilation fails because gnuplot tries to call some functions
> that no longer exist in GTK 3.

We've had this conversation before.
The answer to that latter issue (gdk_window_foreign_new not in gtk3)
is to configure with --disable-raise-console.  Or if you could comment
out or remove that section of code just for wxt since it obviously isn't
going to work anyhow.

As to OSX + wxwidgets not requiring gtk at all, I would be happy
to take a patch that sorted this out in the autoconf script.
I suppose it would test the output of 
   wx-config --query-toolkit

What does that return on OSX?


	Ethan

> 
> (I can move the ticket to the gnuplot tracker, but I maybe some
> autoconf or GTK guru could help a bit.)
> 
> Mojca
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

GTK+ 2 specific code inside wx terminal

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

Hi,

I would like to ask for a bit of help with fixing some opportunistical
linking against GTK+ when wxWidgets is used:
    https://trac.macports.org/ticket/50199

The problem is that as soon as pkg-config finds GTK+ version 2 on the
system and if wxWidgets terminal is enabled, gnuplot links against
GTK2 even if no GTK code is being used at all. And if wxWidgets uses
GTK 3, compilation fails because gnuplot tries to call some functions
that no longer exist in GTK 3.

(I can move the ticket to the gnuplot tracker, but I maybe some
autoconf or GTK guru could help a bit.)

Mojca

Re: bugs in tikz, metapost terminals

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

On Wed, 30 Dec 2015, Ethan Merritt wrote:

> This was apparently deliberate, according to a comment in
> gnuplot-tikz.lua, but I do not know why setting the flag in the lua
> script causes a problem.  As of today, the CVS version of the lua
> terminal treats "set term tikz mono" as if there were two separate
> commands: "set term tikz; set mono".  This is essentially the same as
> the postscript terminal now does.

Thanks, Ethan, that sounds good.

Allin Cottrell

> On Sat, Nov 28, 2015 at 9:43 AM, Allin Cottrell <cot...@wf...> wrote:
>> On Sat, 28 Nov 2015, sfeam wrote:
>>
>>> On Friday, November 27, 2015 01:59:52 PM Allin Cottrell wrote:
>>>>
>>>> In the first instance I'm just wondering if these issues are on
>>>> anyone's radar:
>>>>
>>>> * The tikz terminal doesn't respect the "mono" option; it produces
>>>> a color plot regardless.
>>>
>>>
>>> I am traveling and cannot test old versions of gnuplot, so I do not
>>> know if tikz mono used to work or not.   I do see that "set mono"
>>> works fine for the tikz terminal, so that is available as an alternative.
>>
>> I've now checked, and tikz mono used to work in 4.6.0.
>>
>> Allin Cottrell

Re: bugs in tikz, metapost terminals

[Ethan M. <eam...@gm...>]

This was apparently deliberate, according to a comment in
gnuplot-tikz.lua, but I do not know why setting the flag in the lua
script causes a problem.  As of today, the CVS version of the lua
terminal treats "set term tikz mono" as if there were two separate
commands: "set term tikz; set mono".  This is essentially the same as
the postscript terminal now does.

On Sat, Nov 28, 2015 at 9:43 AM, Allin Cottrell <cot...@wf...> wrote:
> On Sat, 28 Nov 2015, sfeam wrote:
>
>> On Friday, November 27, 2015 01:59:52 PM Allin Cottrell wrote:
>>>
>>> In the first instance I'm just wondering if these issues are on
>>> anyone's radar:
>>>
>>> * The tikz terminal doesn't respect the "mono" option; it produces
>>> a color plot regardless.
>>
>>
>> I am traveling and cannot test old versions of gnuplot, so I do not
>> know if tikz mono used to work or not.   I do see that "set mono"
>> works fine for the tikz terminal, so that is available as an alternative.
>
>
> I've now checked, and tikz mono used to work in 4.6.0.
>
> Allin Cottrell

Re: Arrow keys not working on qt terminal for Mac OS X

[Jun T. <tak...@kb...>]

I'm resending a patch which I sent about a year ago.

On Mac OS X, the Qt::KeypadModifier bit of event->modifiers() is
*always* set when the arrow keys are pressed, and the lines 
922/924/925/927 (not 965-968) of QtGnuplotScene.cpp are executed.

Last call for fixes to be included in release 5.0 patchlevel 2

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

I plan to release patchlevel 2 for gnuplot version 5 sometime next week.

A testing version can be downloaded from the "5.0 release candidates" folder
of the file download area on SourceForge

http://sourceforge.net/projects/gnuplot/files/gnuplot/5.0%20release%20candidates/gnuplot-testing-5.0.2.tar.gz/download

If you know of any version 5 issues that are have not already been addressed
in this incremental release, please raise them here. 

The list of fixes currently included is given in the NEWS file and listed below

Changes since 5.0.1
===================
* NEW support "set clip {one|two}" in 3D vector plots (splot ... with vectors)
* CHANGE post.trm treats lt -1 as double width only when drawing the plot border
* CHANGE distinguish between empty string variable and string constant ""
* CHANGE preserve full precision of samples generated by '+' or '++'
* CHANGE dumb terminal now handles UTF-8 characters
* CHANGE "plot for [i=1:n] foo=i, x*foo" generates n plots (comma is ignored)
* CHANGE accept '\r' as a terminator after console prompt (Windows only)
* CHANGE use the same arrowhead style in the key sample as in the plot itself
* CHANGE the command "set tics {front|back}" no longer affects grid lines also
* CHANGE allow "noautoscale" keyword for 2D function plots
* FIX dashtype labels in 'test' command were off by one
* FIX autocalculation of box widths in the presence of NaN data values
* FIX qt terminals dots were invisible
* FIX point and impulse colors in 3D binary plots
* FIX enable dashtype processing for epslatex terminal
* FIX clean handling of unexpected input commands or data found by fuzz-testing
* FIX many places where corrupt input commands or data could trigger a crash
* FIX aquaterm fill area with transparency
* FIX "offset 0" means "no offset" even in the case of log-scaled axes
* FIX handle formatted read from a datablock
* FIX "pause mouse" for wxt terminal (OSX, other single-threaded platforms)
* FIX 2-column data plots "with filledcurve y=<value>"
* FIX handling outliers in boxplot with categories (i.e. level in column 4)
* FIX inline input format in `splot` command
* FIX order-dependence of optional keywords for "set key" and "set obj polygon"
* FIX lua/tikz text placement errors on OSX 10.10.2 with lua5.3
* FIX B and L formats in gprintf()
* FIX bug parsing time input with format "%s" (extra fractional second)
* FIX incorrect average value in final bin of "smooth cnorm" calculation
* FIX handle log-scale y values when calculating monotonic cubic spline fit
* FIX "set clip points" was non-functional in version 5.0
* FIX regression in 5.0.1 that left extraneous '@' in title columnhead(N)
* FIX vertical placement of text fragments by cairo terminals
* FIX "set [*]axis rangelimited" applies to minor as well as major tics

Re: cvs wxt oddites

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

On 14/12/15 05:06, sfeam wrote:
> On Sunday, 13 December 2015 11:45:22 AM pl...@pi... wrote:
>> Oh man , what is happening to my favourite plotter?
>>
>> I just tired calling gnuplot from command line with  -p -e options.
>>
>> eg
>>
>> gnuplot -p -e " plot \"data.dat\" w l "
>>
>>
>> default qt terminal has lost all interactivity and stays stuck at the
>> size it opens by default.
>
> Works fine for me.
> Or rather, it works fine if I switch to a bash shell.  The syntax with
> backslashed double quotes is not accepted by my default shell.
>
>
>> 'replot on resize" option has no effect,  replot and auto buttons do not
>> change the aspect ration so I'm stuck with a square graph;  grid btn
>> does nothing.
>>
>> Since I can't zoom  P and N btns serve no purpose.
>>
>> OK , mouse cursor readout still works.
>>
>
> I see none of these problems here.
> What exactly have you changed since it was last working?
> If you say "everything", that's going to be hard to debug.
> Can we at least try to distinguish between a build-time problem
> and a run-time problem?
> Does your previous executable work if run on the "freshly installed Fedora 23"?
>
>
>> Adding "set term wxt; "  at the head of the plot expression:
>>
>>
>> Ironically wxt no longer crashed on resizing ;)
>> Mouse interaction allows resize/zoom ,  p and n in the window work but
>> all buttons on the middle section of the toolbar are greyed out.
>>
>> In that past I've cvs builds to be very reliable, what is happening here?
>>
>> This is a freshly installed Fedora 23, I don't think it's that oddball.
>>
>> No one else seeing this kind of problems?
>
> Nope.  But I'm not using Fedora.
> I gave up on it long ago because it is depressingly prone to shipping
> not-quite-working-yet bleeding edge versions of random stuff
> my code depends on.
>
>>    regards, Peter.
>
>

OK, I have uninstalled cvs and installed distro pkg which gets me a 
gnuplot-qt ( not wxt )

I do now have a non hidden title bar.

gnuplot-wx pkg gets me a wxt version built against wxGTK 2.8.x

  gnuplot-wx              x86_64              5.0.1-2.fc23   fedora 
          753 k
  wxBase                  x86_64              2.8.12-19.fc23   fedora 
            595 k
  wxGTK                   x86_64              2.8.12-19.fc23   fedora 
            3.1 M

That much works, none of the oddities I've reported here seem to be 
happening.

Will have a fresh go at a fresh configure  and build of CVS when I have 
some more time.

Thanks.

Re: loop bug or feature?

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

On 13/12/15 16:56, Juhász Péter wrote:
>> plot[0:1.2]  for [ len=9000:7000:-50 ] s=0 \
>> >, "test_filter.out" u (1/$4):($5*1.5e08) w l tit " filter resp " \
>> >, "data-".sprintf("%d",len).".out" u (1/$4):5 w l  tit
>> >sprintf("%d",len).".out" \
>> >
> The plot and splot commands accept a comma-separated list of functions
> or datafiles (or variable assignments), and the for clause counts *per
> function/datafile*.
> So your command essentially sets s = 0 many times, then plots your two
> datafiles once.

Just for the record, since I pointed out that this was not correct and 
contrary to what I had reported, it seems there was a fix between 5.0 
and current cvs.

I have just installed the distro's 5.0 and indeed it does appear that 
s=0 makes a difference and is possible with is getting done n times. I 
only get the last data file plotted until I remove it. So Peter, you 
seem to be right in the case of 5.0

What I said related to recent CVS gnuplot and was also accurate.

Thx.

Re: cvs wxt oddites

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

On 14/12/15 05:06, sfeam wrote:
> On Sunday, 13 December 2015 11:45:22 AM pl...@pi... wrote:
>> Oh man , what is happening to my favourite plotter?
>>
>> I just tired calling gnuplot from command line with  -p -e options.
>>
>> eg
>>
>> gnuplot -p -e " plot \"data.dat\" w l "
>>
>>
>> default qt terminal has lost all interactivity and stays stuck at the
>> size it opens by default.
>
> Works fine for me.
> Or rather, it works fine if I switch to a bash shell.  The syntax with
> backslashed double quotes is not accepted by my default shell.
>
>
>> 'replot on resize" option has no effect,  replot and auto buttons do not
>> change the aspect ration so I'm stuck with a square graph;  grid btn
>> does nothing.
>>
>> Since I can't zoom  P and N btns serve no purpose.
>>
>> OK , mouse cursor readout still works.
>>
>
> I see none of these problems here.
> What exactly have you changed since it was last working?
> If you say "everything", that's going to be hard to debug.
> Can we at least try to distinguish between a build-time problem
> and a run-time problem?
> Does your previous executable work if run on the "freshly installed Fedora 23"?
>
>
>> Adding "set term wxt; "  at the head of the plot expression:
>>
>>
>> Ironically wxt no longer crashed on resizing ;)
>> Mouse interaction allows resize/zoom ,  p and n in the window work but
>> all buttons on the middle section of the toolbar are greyed out.
>>
>> In that past I've cvs builds to be very reliable, what is happening here?
>>
>> This is a freshly installed Fedora 23, I don't think it's that oddball.
>>
>> No one else seeing this kind of problems?
>
> Nope.  But I'm not using Fedora.
> I gave up on it long ago because it is depressingly prone to shipping
> not-quite-working-yet bleeding edge versions of random stuff
> my code depends on.
>
>>    regards, Peter.
>
>

Hi Ethan,

thanks for the reply.

I'm afraid it is rather a case of "everything".

I'd been using Gentoo for the last 15y which as was fast, worked well 
and reliably. Sadly the maintenance overhead was enormous every time I 
did an update. I may not have made a good choice in moving to Fedora, 
maybe. For the moment the only issues I'm getting are from gnuplot CVS 
builds.

I will backtrack to the distro's gnuplot as a starting point.

At least if I'm the only one seeing this kind of thing , there's a good 
chance I can fix it locally,

Thanks, Peter.

Re: cvs wxt oddites

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

On Sunday, 13 December 2015 11:45:22 AM pl...@pi... wrote:
> Oh man , what is happening to my favourite plotter?
> 
> I just tired calling gnuplot from command line with  -p -e options.
> 
> eg
> 
> gnuplot -p -e " plot \"data.dat\" w l "
> 
> 
> default qt terminal has lost all interactivity and stays stuck at the 
> size it opens by default.

Works fine for me.
Or rather, it works fine if I switch to a bash shell.  The syntax with 
backslashed double quotes is not accepted by my default shell.


> 'replot on resize" option has no effect,  replot and auto buttons do not 
> change the aspect ration so I'm stuck with a square graph;  grid btn 
> does nothing.
> 
> Since I can't zoom  P and N btns serve no purpose.
> 
> OK , mouse cursor readout still works.
> 

I see none of these problems here.
What exactly have you changed since it was last working?
If you say "everything", that's going to be hard to debug.
Can we at least try to distinguish between a build-time problem
and a run-time problem?
Does your previous executable work if run on the "freshly installed Fedora 23"?


> Adding "set term wxt; "  at the head of the plot expression:
> 
> 
> Ironically wxt no longer crashed on resizing ;)
> Mouse interaction allows resize/zoom ,  p and n in the window work but 
> all buttons on the middle section of the toolbar are greyed out.
> 
> In that past I've cvs builds to be very reliable, what is happening here?
> 
> This is a freshly installed Fedora 23, I don't think it's that oddball.
>
> No one else seeing this kind of problems?

Nope.  But I'm not using Fedora.
I gave up on it long ago because it is depressingly prone to shipping
not-quite-working-yet bleeding edge versions of random stuff
my code depends on.
 
>   regards, Peter.

Re: loop bug or feature?

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

On 13/12/15 16:56, Juhász Péter wrote:
> On Sun, 2015-12-13 at 15:14 +0000, pl...@pi... wrote:
>> Hi,
>>
>>
>> I need to plot a series of data files and one reference file.
>>
>>
>> here I get all the data files and one test plot
>>
>> plot[0:1.2] for [ len=9000:7000:-50 ] s=0 \
>> , "data-".sprintf("%d",len).".out" u (1/$4):5 w l tit
>> sprintf("%d",len).".out" \
>> , "test_filter.out" u (1/$4):($5*1.5e08) w l tit " filter resp " \
>>
>>
>> but this way around I get the test plot n time and only the last data
>> file plotted.
>>
>>
>> plot[0:1.2]  for [ len=9000:7000:-50 ] s=0 \
>> , "test_filter.out" u (1/$4):($5*1.5e08) w l tit " filter resp " \
>> , "data-".sprintf("%d",len).".out" u (1/$4):5 w l  tit
>> sprintf("%d",len).".out" \
>>
>
> The plot and splot commands accept a comma-separated list of functions
> or datafiles (or variable assignments), and the for clause counts *per
> function/datafile*.
> So your command essentially sets s = 0 many times, then plots your two
> datafiles once.

No so , reread what I reported. In both cases I got multiple but 
different plots.

>
> If you omit that s=0 from your first command (it seems to be superfluous
> anyway), it will do what you want. You might want to reindent the
> command to show that the for clause belongs to a specific datafile, not
> the entire command:
>
> plot[0:1.2] \
> for [ len=9000:7000:-50 ] "data-".sprintf("%d",len).".out" u (1/$4):5 w
> l tit sprintf("%d",len).".out", \
> "test_filter.out" u (1/$4):($5*1.5e08) w l tit " filter resp"
>
>


Firstly the s=0 syntactically superfluous but it's a trick I use make 
all following lines have the same format ( beginning with a comma; end 
in escape char  ) , this means I can change line order or add/remove 
lines without tiresome editing for syntax.

>>
>>
>> gnuplot> help for
>>
>>    The `plot`, `splot`, `set` and `unset` commands may optionally contain an
>>    iteration for clause.  This has the effect of executing the basic command
>>    multiple times, each time re-evaluating any expressions that make use
>> of the
>>    iteration control variable.
>>
>>
>
> This section does not mention the fact that the for clause affects just
> one element of the plot list, however, the "help for loops" subtopic
> does:

Ah indeed:

"The scope of an iteration ends at the next comma or the end of the command,
  whichever comes first. "

So this explains why the s=0 does not affect it. There is not yet any 
substitution so there's not yet question of stopping at the " next" comma .

This does explain the difference in my two results which are then 
consistent with the help description.

There probably should at least be a "see loops" . I did "more" until the 
end of help on 'for' but since I had found the description of syntax I 
was seeking,  I did not go into the subtopics.

Many thanks for the reply, Peter.

>
>
>   This will plot one curve, sin(3x), because iteration ends at the comma
>         plot for [i=1:3] j=i, sin(j*x)
>   This will plot three curves because there is no comma after the
> definition of j
>         plot for [i=1:3] j=i sin(j*x)
>
>
>>
>> This does not seem consistent with what happens.
>>
>> regards, Peter.
>>
>>
>>
>>
>
> Peter Juhasz
>
>
>
>

Re: loop bug or feature?

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

On Sun, 2015-12-13 at 15:14 +0000, pl...@pi... wrote:
> Hi,
> 
> 
> I need to plot a series of data files and one reference file.
> 
> 
> here I get all the data files and one test plot
> 
> plot[0:1.2] for [ len=9000:7000:-50 ] s=0 \
> , "data-".sprintf("%d",len).".out" u (1/$4):5 w l tit
> sprintf("%d",len).".out" \
> , "test_filter.out" u (1/$4):($5*1.5e08) w l tit " filter resp " \
> 
> 
> but this way around I get the test plot n time and only the last data
> file plotted.
> 
> 
> plot[0:1.2]  for [ len=9000:7000:-50 ] s=0 \
> , "test_filter.out" u (1/$4):($5*1.5e08) w l tit " filter resp " \
> , "data-".sprintf("%d",len).".out" u (1/$4):5 w l  tit
> sprintf("%d",len).".out" \
> 

The plot and splot commands accept a comma-separated list of functions
or datafiles (or variable assignments), and the for clause counts *per
function/datafile*.
So your command essentially sets s = 0 many times, then plots your two
datafiles once.

If you omit that s=0 from your first command (it seems to be superfluous
anyway), it will do what you want. You might want to reindent the
command to show that the for clause belongs to a specific datafile, not
the entire command:

plot[0:1.2] \
for [ len=9000:7000:-50 ] "data-".sprintf("%d",len).".out" u (1/$4):5 w
l tit sprintf("%d",len).".out", \
"test_filter.out" u (1/$4):($5*1.5e08) w l tit " filter resp "
 

> 
> 
> gnuplot> help for
> 
>   The `plot`, `splot`, `set` and `unset` commands may optionally contain an
>   iteration for clause.  This has the effect of executing the basic command
>   multiple times, each time re-evaluating any expressions that make use
> of the
>   iteration control variable.
> 
> 

This section does not mention the fact that the for clause affects just
one element of the plot list, however, the "help for loops" subtopic
does:


 This will plot one curve, sin(3x), because iteration ends at the comma
       plot for [i=1:3] j=i, sin(j*x)
 This will plot three curves because there is no comma after the
definition of j
       plot for [i=1:3] j=i sin(j*x)


> 
> This does not seem consistent with what happens.
> 
> regards, Peter.
> 
> 
> 
> 

Peter Juhasz

loop bug or feature?

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

Hi,


I need to plot a series of data files and one reference file.


here I get all the data files and one test plot

plot[0:1.2] for [ len=9000:7000:-50 ] s=0 \
, "data-".sprintf("%d",len).".out" u (1/$4):5 w l tit
sprintf("%d",len).".out" \
, "test_filter.out" u (1/$4):($5*1.5e08) w l tit " filter resp " \


but this way around I get the test plot n time and only the last data
file plotted.


plot[0:1.2]  for [ len=9000:7000:-50 ] s=0 \
, "test_filter.out" u (1/$4):($5*1.5e08) w l tit " filter resp " \
, "data-".sprintf("%d",len).".out" u (1/$4):5 w l  tit
sprintf("%d",len).".out" \



gnuplot> help for

  The `plot`, `splot`, `set` and `unset` commands may optionally contain an
  iteration for clause.  This has the effect of executing the basic command
  multiple times, each time re-evaluating any expressions that make use
of the
  iteration control variable.



This does not seem consistent with what happens.

regards, Peter.

Re: cvs wxt oddites

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

Oh man , what is happening to my favourite plotter?

I just tired calling gnuplot from command line with  -p -e options.

eg

gnuplot -p -e " plot \"data.dat\" w l "


default qt terminal has lost all interactivity and stays stuck at the 
size it opens by default.

'replot on resize" option has no effect,  replot and auto buttons do not 
change the aspect ration so I'm stuck with a square graph;  grid btn 
does nothing.

Since I can't zoom  P and N btns serve no purpose.

OK , mouse cursor readout still works.


Adding "set term wxt; "  at the head of the plot expression:


Ironically wxt no longer crashed on resizing ;)
Mouse interaction allows resize/zoom ,  p and n in the window work but 
all buttons on the middle section of the toolbar are greyed out.

In that past I've cvs builds to be very reliable, what is happening here?

This is a freshly installed Fedora 23, I don't think it's that oddball.

No one else seeing this kind of problems?

  regards, Peter.

cvs wxt oddites

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

Hi,

1.
to recap an ugly crash issue, wxt falls on its arse during resize if the 
'redraw during resize' option is active. Seems fine with this disabled.

2.
If I change desktop and return to a desktop containing a wxt the window 
frame draws but the content remains a grey rectangle until the it put 
the mouse over it. With this LXDE it is configured to git the window 
focus on mouseover. I assume it is this event that finally causes a 
redraw of the contents.

3.
Whenever I do a replot or autorescale from the toolbar I get something 
like this:


(gnuplot:31404): GLib-CRITICAL **: Source ID 17656 was not found when 
attempting to remove it

(gnuplot:31404): GLib-CRITICAL **: Source ID 25138 was not found when 
attempting to remove it

Further investigation showed this to be related to the toolbar widgets 
not the redraw.

If I do refresh or set auto from gnuplot terminal, no error. However, if 
I then take the mouse into the toolbar over a button there is no change 
to the visible state of the button. If I then leave the button without 
pressing it I get that GLib-CRITICAL again.

It seems that the highlight square that normally gets shown when you 
hover a button is not getting created after replot or set auto has been 
called. When the button next changes state gnuplot tries to free up a 
glyph that was never created and hence GLib-CRITICAL.

This not a big issue but I wondered whether reviewing what is happening 
( or not ) during redraw may give a clue to the crash during automatic 
redrawing. That is a big messy regression.


4.
I have a  plot that has y range [0:7000] in auto. If I then scroll the 
plot downward one notch  using mouse scrollwheel, fine. If I then scroll 
back to the original position the y axis tick labels all get 13 trailing 
zeros after the decimal point !

I had not updated cvs for some time , so I cannot give a good indication 
when these regressions happened.

regards, Peter.

Re: Expecting support for multiple keys and multiple files.

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

> <1>.  Multiple keys
> ...
> set key 1 top right
> set key 2 bottom left
> plot 'data' key 1, '' key 1, '' key 2, '' key 2
> 
> Thus, if I have many legends and there's no space to put them together, 
> I can divide them into two groups
> "key 1" and "key 2" and put them at different places.

Don't labels (as in, "help set label") offer a more flexible and
comprehensive solution to this problem?

> <2>. Multiple files
> 
> Columns from different files can be calculated together. e.g. I have two 
> files that have the same format, say, 100 row of (x, y) data, named 
> 'file1' and 'file2'. Now I want to plot the different between y columns 
> from the two files.
> 
> plot 'file1' using 1:($2-column('file2',2)) with lp

There's more that goes into selecting data from a file than merely a
filename and column. Consider "every" and "using", for example,
which are tied with a line, not with a file. This request would
almost seem to demand a cached "virtual column" data structure that
could be populated with arbitrary combinations of
file(s)/every/using/timefmt/etc. and then be given to plot as a
source.

On the other hand, facilities already exist outside of gnuplot to
combine columns from multiple files (e.g. paste, col, or even awk,
bash, perl/python/etc). Small, separate tools are free from the
constraints of gnuplot's syntax and data structures. Languages have
the power to implement any transformation possible, not just a small
handful of pre-imagined example scenarios. And gnuplot can even
invoke these outside utilities, inline, with the plot command via
the "plot '<command'" syntax. I can't see a way to combine multiple
files into a single line without syntactic complexity, hard-to-test
(and hard-to-maintain) combinations of keywords, and backward-
compatibility-breaking changes. Especially when there's
already an existing solution, it doesn't seem worth it.

Re: C++ in gnuplot

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

[Oops, keep forgetting to CC: the list]

Am 10.12.2015 um 13:50 schrieb Mojca Miklavec:
> On 10 December 2015 at 00:28, Hans-Bernhard Bröker wrote:
>> Am 09.12.2015 um 19:35 schrieb Mojca Miklavec:

>>>>> but the program crashes anyway (on exit at least) if I don't compile
>>>>> it against libc++ (rather than libstdc++).

>> "Crashes" is rather a small amount of information.  Could you dig a little
>> deeper, preferrably using the debugger?

> ... and then I remembered that crashes are logged. So I'm attaching
> it. But I don't know if anyone can make anything out of it except that
> maybe something was wrong with the thread management?

Hmmm... so let's see

	Exception Type:  EXC_BAD_ACCESS (SIGSEGV)

so most likely an invalid pointer.  The call sequence triggering it is,
at the top end:

19  gnuplot_qt                    	0x000000010a85a2dc main + 912

That's the top-level call from gnuplot_qt's main() into Qt:

	application.exec();

This may have to be brought to the attention of the Qt5 people, but it
seems like the Qt event loop is still trying to process things after
they're no longer there.

Re: C++ in gnuplot

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

On 10 December 2015 at 00:28, Hans-Bernhard Bröker wrote:
> Am 09.12.2015 um 19:35 schrieb Mojca Miklavec:
>
>>>> but the program crashes anyway (on exit at least) if I don't compile
>>>> it against libc++ (rather than libstdc++).
>
> "Crashes" is rather a small amount of information.  Could you dig a little
> deeper, preferrably using the debugger?

I had a full stack trace, but I felt it was too long for the mailing
list and discarded it. Now I tried to reproduce it and it no longer
crashes, so I'm unable to send more information until I figure out
what exactly triggers the crash.

... and then I remembered that crashes are logged. So I'm attaching
it. But I don't know if anyone can make anything out of it except that
maybe something was wrong with the thread management?

Mojca

Re: C++ in gnuplot

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

On 10 December 2015 at 13:04, Jun T. wrote:
> On 2015/12/10, at 18:44, Mojca Miklavec wrote:
>
>> The other question is whether adding "std::" prefix would break the
>> functionality for someone else.
>
> If you add std:: then does it compile with Qt4?

Yes. It does for me. But I'm not claiming that it will continue to
work everywhere (with every compiler on every platform).

Google returns some relevant discussions:
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48891
- https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60407
- https://bugs.webkit.org/show_bug.cgi?id=59249

Mojca

Re: C++ in gnuplot

[Jun T. <tak...@kb...>]

On 2015/12/10, at 18:44, Mojca Miklavec <moj...@gm...> wrote:

> The other question is whether adding "std::" prefix would break the
> functionality for someone else.

If you add std:: then does it compile with Qt4?

Re: C++ in gnuplot

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

On 10 December 2015 at 09:40, Jun T. wrote:
> On 2015/12/09, at 19:41, Mojca Miklavec wrote:
>> qtterminal/qt_conversion.cpp:129:9: error: use of undeclared
>> identifier 'isnan'; did you mean 'std::isnan'?
>>                                if (isnan(*image))
>>                                    ^~~~~
>>                                    std::isnan
>>
>> which I can fix by changing isnan to std::isnan,
>
> If I set
>     export CC=clang CXX=clang++
>     export CXXFLAGS='-std=c++11 -stdlib=libc++'
> then I don't need to modify any source files (OS X 10.8, Qt5).
>
> Do you get the isnan error even with this CXXFLAGS?

Probably not. I also don't get that error if I link against Qt 4. But
if I use libc++ (which I might have to do eventually), I also need
properly compiled wxWidgets (and hopefully nothing else).

So I would like to understand whether I *need to* use libc++ or not.
Most probably I will have to, but I'm not yet 100% sure.

(Just to make it clear: I'm not trying to solve my own problem. I need
to fix this inside a package manage that provides gnuplot, so it has
to work for everyone.)

The other question is whether adding "std::" prefix would break the
functionality for someone else.

> BTW, how did you install Qt5?

With MacPorts. (And I have no alternative [other than maybe fixing Qt5
in MacPorts] because I'm packaging gnuplot for that.)

Mojca