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

Re: File dialog in wxt does not work

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

On Fri, 19 Sep 2014, Philipp K. Janert wrote:

> On Fri, 19 Sep 2014 13:58:45 -0700
> Ethan A Merritt <sf...@us...> wrote:
>
>> On Friday, 19 September, 2014 13:31:50 Philipp K. Janert wrote:
>>>
>>> One other thing - the "file" dialog (top left)
>>> in the wxt terminal does "nothing" for me (either
>>> in iceWM or in Mate). When I click it, nothing
>>> happens.
>>
>> It copies the window content into the desktop clipboard.
>> In KDE you can see it as a small thumbnail in the klipper menu.
>> Whether IceWM or Mate provide a similar tool to retrieve it, I can't
>> say.
>>
>> If you run some other program (Gimp?  Powerpoint? soffice?) that
>> supports cut-and-paste using the clipboard, you can then import the
>> image using ctrl-V or middle-click or whatever you have configured
>> for "paste from clipboard".
>
> Works! Thanks for the hint.
>
> I expected a "file dialog" to pop up, so that
> I could save the graph as a (say) PDF. (As it
> works under Qt.)
>
> The functionality is nice, but the user-interface
> might be rather confusing for people. (I doubt I
> am the only one who expected a file dialog.)

The icon at the top left is supposed to represent "copy" and a 
clipboard, and its tooltip says "Copy the plot to clipboard". I'm
not sure why one would expect a "file dialog".

Allin Cottrell

Re: File dialog in wxt does not work

[Philipp K. J. <ja...@ie...>]

[snip]

> > The functionality is nice, but the user-interface
> > might be rather confusing for people. (I doubt I
> > am the only one who expected a file dialog.)
> 
> The icon at the top left is supposed to represent "copy" and a 
> clipboard, and its tooltip says "Copy the plot to clipboard". I'm
> not sure why one would expect a "file dialog".

Answer: because that's what is in the top-left corner
of menus, almost universally. (Eg, among many others,
gnuplot's own wxt terminal.)

The icon is too small and to unspecific to send a 
strong message, either way. And I admit that I did
not wait for the tooltip.

I mean, once you know what's it doing, it's no 
problem, but otherwise, it's not at all obvious.

> 
> Allin Cottrell

Re: File dialog in wxt does not work

[Philipp K. J. <ja...@ie...>]

On Fri, 19 Sep 2014 13:58:45 -0700
Ethan A Merritt <sf...@us...> wrote:

> On Friday, 19 September, 2014 13:31:50 Philipp K. Janert wrote:
> > 
> > One other thing - the "file" dialog (top left)
> > in the wxt terminal does "nothing" for me (either
> > in iceWM or in Mate). When I click it, nothing
> > happens.
> 
> It copies the window content into the desktop clipboard.
> In KDE you can see it as a small thumbnail in the klipper menu.
> Whether IceWM or Mate provide a similar tool to retrieve it, I can't
> say.  
> 
> If you run some other program (Gimp?  Powerpoint? soffice?) that
> supports cut-and-paste using the clipboard, you can then import the
> image using ctrl-V or middle-click or whatever you have configured
> for "paste from clipboard".

Works! Thanks for the hint.

I expected a "file dialog" to pop up, so that
I could save the graph as a (say) PDF. (As it
works under Qt.)

The functionality is nice, but the user-interface 
might be rather confusing for people. (I doubt I
am the only one who expected a file dialog.)

> 
> 	Ethan
> 

Re: Once more: Qt Terminal (no output)

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

On Friday, 19 September, 2014 13:25:05 Philipp K. Janert wrote:
> On Sun, 15 Jun 2014 20:41:22 -0700
> sfeam <sf...@us...> wrote:
> 
> I wanted to re-raise this issue: when using the
> Qt terminal, I simply don't get a plot window, 
> using my preferred window mgr.
> 
> set t qt
> plot sin(x)
> 
> does "nothing" - control returns to the gnuplot
> command, but no window appears.
> 
> I finally got around to trying it out with a
> different window manager (Mate - which is the
> default for my distro, which is Mint), and now
> everything works just fine.
> 
> So, the problem is apparently somewhere between
> gnuplot, qt, and iceWM (and possibly my iceWM 
> configurations!).
> 
> How does one make progress on something like this? ;-)

I suggest creating a new account on the machine, one that
has never been used previously so that all desktop settings
are in the default state.  Log in to the clean account under
IceWM and see if the problem is gone.  If so then you can
try to compare the default settings to your customized settings
to see if there is a relevant change.

	Ethan



> 
> 
> > On Sunday, 15 June 2014 06:36:18 PM you wrote:
> > > On Sun, 15 Jun 2014 18:22:17 -0700
> > > sfeam <sf...@us...> wrote:
> > > 
> > > > On Sunday, 15 June 2014 06:18:50 PM Philipp K. Janert wrote:
> > > > > On Sun, 15 Jun 2014 16:55:26 -0700
> > > > > Ethan Merritt <merritt@u.washington.edu> wrote:
> > > > > 
> > > > > > On Sunday, 15 June 2014 04:47:14 PM Philipp K. Janert wrote:
> > > > > > > 
> > > > > > > I can now build and run gnuplot5 rc1 with Qt,
> > > > > > > but when I try to use the qt terminal, I do
> > > > > > > not get an output window. I also do not seem
> > > > > > > to get an error message - just nothing happens.
> > > > > > > 
> > > > > > > I have no problem using either wxt or x11.
> > > > > > > 
> > > > > > > Is this known behavior?
> > > > > > 
> > > > > > Nope.
> > > > > > 
> > > > > > If you run "top" or "ps" in another terminal do you see
> > > > > > gnuplot_qt? Do you see any evidence of font-config or some
> > > > > > other system utility eating up time?
> > > > > 
> > > > > Both gnuplot and gnuplot_qt are running
> > > > > (according to ps), but neither is consuming
> > > > > significant resources (according to top).
> > > > > 
> > > > > My window manager is iceWM (for what it's
> > > > > worth).
> > > > > 
> > > > > The gnuplot "output" is sent to "STDOUT".
> > > > > 
> > > > > "show terminal" says:
> > > > > 	terminal type is qt 0 font "Sans,9"
> > > > > 
> > > > > Anything I should try to get more info?
> > > > 
> > > > 
> > > > use ps to gid the pid of gnuplot_qt.
> > > > Let's say it's 12345.
> > > > 
> > > > gdb -p 12345
> > > > gdb> where
> > > > 
> > > 
> > > gdb required me to be root to attach to process.
> > 
> > Really?  That is very strange.
> > When you see the gnuplot_qt process in ps or top, 
> > does it belong to you or does it belong to root?
> > (the process itself, not the file).
> > If it belongs to root then I think that might
> > actually be the problem, although I don't know
> > how it would get into that state.
> > 
> > Conversely, I suppose you could try running the program
> > as root to see if the same problem occurs.
> > 
> > > The output is below:
> > > 
> > > (skipping many lines)
> > > 
> > > Reading symbols
> > > from /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqsvg.so...(no
> > > debugging symbols found)...done. Loaded symbols
> > > for /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqsvg.so
> > > 0x00007faf6f701f7d in poll () from /lib/x86_64-linux-gnu/libc.so.6
> > > 
> > > (gdb) where #0  0x00007faf6f701f7d in poll ()
> > > from /lib/x86_64-linux-gnu/libc.so.6 #1  0x00007faf6ecd46a4 in ?? ()
> > > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2  0x00007faf6ecd47ac
> > > in g_main_context_iteration ()
> > > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3  0x00007faf70443b0c
> > > in
> > > QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
> > > () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4
> > > 0x00007faf703fdb6b in
> > > QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
> > > from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5
> > > 0x00007faf70403301 in QCoreApplication::exec() ()
> > > from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6
> > > 0x000000000040d4be in main (argc=1, argv=<optimized out>) at
> > > qtterminal/gnuplot_qt.cpp:78
> > 
> > Bah. That tells me nothing useful.
> > It got stuck too deep in the qt library code for me to pin it down to
> > anything particular that gnuplot did.
> > 
> > I don't think I'm going to be able to help much.
> > I've never seen anything like this when using Qt with gnuplot
> > or any other program for that matter.  Is there a Mint help forum
> > you could ask in?
> > 
> > 	Ethan
> > 
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
-- 
Ethan A Merritt
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: File dialog in wxt does not work

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

On Friday, 19 September, 2014 13:31:50 Philipp K. Janert wrote:
> 
> One other thing - the "file" dialog (top left)
> in the wxt terminal does "nothing" for me (either
> in iceWM or in Mate). When I click it, nothing
> happens.

It copies the window content into the desktop clipboard.
In KDE you can see it as a small thumbnail in the klipper menu.
Whether IceWM or Mate provide a similar tool to retrieve it, I can't say.  

If you run some other program (Gimp?  Powerpoint? soffice?) that supports 
cut-and-paste using the clipboard, you can then import the image
using ctrl-V or middle-click or whatever you have configured
for "paste from clipboard".

	Ethan

Re: Once more: Qt Terminal (no output)

[Philipp K. J. <ja...@ie...>]

On Sun, 15 Jun 2014 20:41:22 -0700
sfeam <sf...@us...> wrote:

I wanted to re-raise this issue: when using the
Qt terminal, I simply don't get a plot window, 
using my preferred window mgr.

set t qt
plot sin(x)

does "nothing" - control returns to the gnuplot
command, but no window appears.

I finally got around to trying it out with a
different window manager (Mate - which is the
default for my distro, which is Mint), and now
everything works just fine.

So, the problem is apparently somewhere between
gnuplot, qt, and iceWM (and possibly my iceWM 
configurations!).

How does one make progress on something like this? ;-)


> On Sunday, 15 June 2014 06:36:18 PM you wrote:
> > On Sun, 15 Jun 2014 18:22:17 -0700
> > sfeam <sf...@us...> wrote:
> > 
> > > On Sunday, 15 June 2014 06:18:50 PM Philipp K. Janert wrote:
> > > > On Sun, 15 Jun 2014 16:55:26 -0700
> > > > Ethan Merritt <merritt@u.washington.edu> wrote:
> > > > 
> > > > > On Sunday, 15 June 2014 04:47:14 PM Philipp K. Janert wrote:
> > > > > > 
> > > > > > I can now build and run gnuplot5 rc1 with Qt,
> > > > > > but when I try to use the qt terminal, I do
> > > > > > not get an output window. I also do not seem
> > > > > > to get an error message - just nothing happens.
> > > > > > 
> > > > > > I have no problem using either wxt or x11.
> > > > > > 
> > > > > > Is this known behavior?
> > > > > 
> > > > > Nope.
> > > > > 
> > > > > If you run "top" or "ps" in another terminal do you see
> > > > > gnuplot_qt? Do you see any evidence of font-config or some
> > > > > other system utility eating up time?
> > > > 
> > > > Both gnuplot and gnuplot_qt are running
> > > > (according to ps), but neither is consuming
> > > > significant resources (according to top).
> > > > 
> > > > My window manager is iceWM (for what it's
> > > > worth).
> > > > 
> > > > The gnuplot "output" is sent to "STDOUT".
> > > > 
> > > > "show terminal" says:
> > > > 	terminal type is qt 0 font "Sans,9"
> > > > 
> > > > Anything I should try to get more info?
> > > 
> > > 
> > > use ps to gid the pid of gnuplot_qt.
> > > Let's say it's 12345.
> > > 
> > > gdb -p 12345
> > > gdb> where
> > > 
> > 
> > gdb required me to be root to attach to process.
> 
> Really?  That is very strange.
> When you see the gnuplot_qt process in ps or top, 
> does it belong to you or does it belong to root?
> (the process itself, not the file).
> If it belongs to root then I think that might
> actually be the problem, although I don't know
> how it would get into that state.
> 
> Conversely, I suppose you could try running the program
> as root to see if the same problem occurs.
> 
> > The output is below:
> > 
> > (skipping many lines)
> > 
> > Reading symbols
> > from /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqsvg.so...(no
> > debugging symbols found)...done. Loaded symbols
> > for /usr/lib/x86_64-linux-gnu/qt5/plugins/imageformats/libqsvg.so
> > 0x00007faf6f701f7d in poll () from /lib/x86_64-linux-gnu/libc.so.6
> > 
> > (gdb) where #0  0x00007faf6f701f7d in poll ()
> > from /lib/x86_64-linux-gnu/libc.so.6 #1  0x00007faf6ecd46a4 in ?? ()
> > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #2  0x00007faf6ecd47ac
> > in g_main_context_iteration ()
> > from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3  0x00007faf70443b0c
> > in
> > QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>)
> > () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #4
> > 0x00007faf703fdb6b in
> > QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) ()
> > from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #5
> > 0x00007faf70403301 in QCoreApplication::exec() ()
> > from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #6
> > 0x000000000040d4be in main (argc=1, argv=<optimized out>) at
> > qtterminal/gnuplot_qt.cpp:78
> 
> Bah. That tells me nothing useful.
> It got stuck too deep in the qt library code for me to pin it down to
> anything particular that gnuplot did.
> 
> I don't think I'm going to be able to help much.
> I've never seen anything like this when using Qt with gnuplot
> or any other program for that matter.  Is there a Mint help forum
> you could ask in?
> 
> 	Ethan
> 

File dialog in wxt does not work

[Philipp K. J. <ja...@ie...>]

One other thing - the "file" dialog (top left)
in the wxt terminal does "nothing" for me (either
in iceWM or in Mate). When I click it, nothing
happens.

(By contrast, the file dialog did work in the qt 
dialog under Mate, when I tried it.)

Is this known behavior?

Best,

		Ph.

Fw: windows terminal line style settings

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

----- Forwarded Message -----
> From: Tatsuro MATSUOKA 
> To: bmaerkisch
> Cc: 
> Date: 2014/9/19, Fri 22:20
> Subject: Re: windows terminal line style settings
> 
> 
> 
> 
> 
> ----- Original Message -----
>>  From: Bastian Märkisch
>>  To: gnuplot beta list 
>>  Cc: 
>>  Date: 2014/9/19, Fri 19:10
>>  Subject: windows terminal line style settings
>> 
>> T he windows terminal currently supports user-defined linetypes, which 
>>  are stored in wgnuplot.ini and can be edited using a dialog box. This 
>>  feature has become redundant by version 5's capability to change 
>>  linetypes in a terminal independent way. Also version 5 defaults to 
>>  overwrite linetypes on start with a new color scheme anyway. Hence any 
>>  change via wgnuplot.ini won't be visible.
>>  Consequently, I propose to remove this feature of the windows terminal. 
>>  What are your opinions on this?
>> 
>>     Bastian
>> 
>> 
> ------------------------------------------------------------------------------
>>  Slashdot TV.  Video for Nerds.  Stuff that Matters.
>> 
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>>  _______________________________________________
>>  gnuplot-beta mailing list
>>  gnu...@li...
>>  Membership management via: 
>>  https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> 
> 
> I agree with your proposal.
> 
> Tatsuro
> 

windows terminal line style settings

[Bastian M. <bma...@we...>]

The windows terminal currently supports user-defined linetypes, which 
are stored in wgnuplot.ini and can be edited using a dialog box. This 
feature has become redundant by version 5's capability to change 
linetypes in a terminal independent way. Also version 5 defaults to 
overwrite linetypes on start with a new color scheme anyway. Hence any 
change via wgnuplot.ini won't be visible.
Consequently, I propose to remove this feature of the windows terminal. 
What are your opinions on this?

   Bastian

Re: Minor knit pick: errors

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

On 09/17/14 22:27, Ethan A Merritt wrote:
> Nevertheless I agree that the error message might more accurately say
> "Cannot find or open file" rather than "unreadable file".
>
> 	Ethan

That would seem to cover it. I was not expecting this to be more 
complicated than changing a strong.

  Peter.

Re: Minor knit pick: errors

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

On Wednesday, 17 September, 2014 21:07:58 pl...@pi... wrote:
> On 09/17/14 20:15, Ethan A Merritt wrote:
> >
> > On Wednesday, 17 September, 2014 11:33:40 pl...@pi... wrote:
> >> Hi,
> >>
> >> it is not very helpful that gnuplot  does not distinguish between
> >> non-existent files and files it cannot parse for plotting.
> >>
> >>    warning: Skipping unreadable file ......
> >>
> >> Whenever I get this I have to try to work out whether there is a typo or
> >> come other error in the path specifier or whether there are some header
> >> lines or other formatting problems with data in a file  that it is able
> >> to find.
> >
> > Could you be more specific?
> > I get several different errors.  It is true that "unreadable" can be misleading
> > for a file that doesn't exist at all, but in the case of formatting problems
> > in the file "Bad data on line X" seems clear enough.
> >
> > gnuplot> plot 'notthere.dat'
> >           warning: Skipping unreadable file "notthere.dat"
> >           No data in plot
> >
> > gnuplot> plot 'readprotected.dat'
> >           warning: Skipping unreadable file "readprotected.dat"
> >           No data in plot
> >
> > gnuplot> plot 'emptyfile.dat'
> >           warning: Skipping data file with no valid points
> >                               ^
> >           x range is invalid
> >
> > gnuplot> plot '/bin/true'
> >                ^
> >           Bad data on line 1 of file /bin/true
> >
> >
> >> since these must be quite different error conditions as far as where and
> >> how they are trapped in the code, some distinction would be very helpful
> >> in saving time finding the problem.
> >>
> >>
> >> Regards, Peter.
> >
> >
> 
> Thanks you are correct. The data errors are clear enough.
> 
> What causes confusion is that missing files are reported like the fiile 
> has been found but  there's a problem reading it.
> 
> Clearly "unreadable" needs to be changed to something more explicit if 
> it's a file not found error., perhaps also with something more explicit 
> if it is a read access problem since "unreadable" sounds like it has 
> been opened but can not be read as data.
> 
> My guess is that someone historically has got an error with an 'open 
> with read access' command  and tried to use a generic error msg that 
> covers all bases.

It's more complicated than that, since it can also fail if your
"set loadpath" string is bad, or the path length becomes too long,
or a network access times out, etc, etc.

Furthermore the routine loadpath_fopen() tries to find the file
in multiple places, and may fail several times with various errors
before either succeeding or giving up.  So you can't just echo back
every error that occurs on an fopen()  command.

I'm not opposed to more explicit error messages if you want to work
on a patch to implement it, but it will take more than just adding 
int_warn(NO_CARET, strerrorr(errno)) at some single place.

Nevertheless I agree that the error message might more accurately say
"Cannot find or open file" rather than "unreadable file".

	Ethan

> While this is technically correct, it is the not the most helpful 
> solution in a situation where it is imperative to find out where the 
> problem lies to fix it.
> 
> 
> .Peter.
> 

Re: Minor knit pick: errors

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

On 09/17/14 20:15, Ethan A Merritt wrote:
>
> On Wednesday, 17 September, 2014 11:33:40 pl...@pi... wrote:
>> Hi,
>>
>> it is not very helpful that gnuplot  does not distinguish between
>> non-existent files and files it cannot parse for plotting.
>>
>>    warning: Skipping unreadable file ......
>>
>> Whenever I get this I have to try to work out whether there is a typo or
>> come other error in the path specifier or whether there are some header
>> lines or other formatting problems with data in a file  that it is able
>> to find.
>
> Could you be more specific?
> I get several different errors.  It is true that "unreadable" can be misleading
> for a file that doesn't exist at all, but in the case of formatting problems
> in the file "Bad data on line X" seems clear enough.
>
> gnuplot> plot 'notthere.dat'
>           warning: Skipping unreadable file "notthere.dat"
>           No data in plot
>
> gnuplot> plot 'readprotected.dat'
>           warning: Skipping unreadable file "readprotected.dat"
>           No data in plot
>
> gnuplot> plot 'emptyfile.dat'
>           warning: Skipping data file with no valid points
>                               ^
>           x range is invalid
>
> gnuplot> plot '/bin/true'
>                ^
>           Bad data on line 1 of file /bin/true
>
>
>> since these must be quite different error conditions as far as where and
>> how they are trapped in the code, some distinction would be very helpful
>> in saving time finding the problem.
>>
>>
>> Regards, Peter.
>
>

Thanks you are correct. The data errors are clear enough.

What causes confusion is that missing files are reported like the fiile 
has been found but  there's a problem reading it.

Clearly "unreadable" needs to be changed to something more explicit if 
it's a file not found error., perhaps also with something more explicit 
if it is a read access problem since "unreadable" sounds like it has 
been opened but can not be read as data.

My guess is that someone historically has got an error with an 'open 
with read access' command  and tried to use a generic error msg that 
covers all bases.

While this is technically correct, it is the not the most helpful 
solution in a situation where it is imperative to find out where the 
problem lies to fix it.


.Peter.

Re: Minor knit pick: errors

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

On Wednesday, 17 September, 2014 11:33:40 pl...@pi... wrote:
> Hi,
> 
> it is not very helpful that gnuplot  does not distinguish between 
> non-existent files and files it cannot parse for plotting.
> 
>   warning: Skipping unreadable file ......
> 
> Whenever I get this I have to try to work out whether there is a typo or 
> come other error in the path specifier or whether there are some header 
> lines or other formatting problems with data in a file  that it is able 
> to find.

Could you be more specific?
I get several different errors.  It is true that "unreadable" can be misleading
for a file that doesn't exist at all, but in the case of formatting problems
in the file "Bad data on line X" seems clear enough.

gnuplot> plot 'notthere.dat'
         warning: Skipping unreadable file "notthere.dat"
         No data in plot

gnuplot> plot 'readprotected.dat'
         warning: Skipping unreadable file "readprotected.dat"
         No data in plot

gnuplot> plot 'emptyfile.dat'
         warning: Skipping data file with no valid points
                             ^
         x range is invalid

gnuplot> plot '/bin/true'
              ^
         Bad data on line 1 of file /bin/true


> since these must be quite different error conditions as far as where and 
> how they are trapped in the code, some distinction would be very helpful 
> in saving time finding the problem.
> 
> 
> Regards, Peter.

Minor knit pick: errors

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

Hi,

it is not very helpful that gnuplot  does not distinguish between 
non-existent files and files it cannot parse for plotting.

  warning: Skipping unreadable file ......

Whenever I get this I have to try to work out whether there is a typo or 
come other error in the path specifier or whether there are some header 
lines or other formatting problems with data in a file  that it is able 
to find.


since these must be quite different error conditions as far as where and 
how they are trapped in the code, some distinction would be very helpful 
in saving time finding the problem.


Regards, Peter.

Re: volunteers to fix some minor bugs in the lua/tikz terminal?

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

On Monday, 15 September 2014 09:27:24 PM Christoph Bersch wrote:
> Hi,
> 
> Am 02.09.2014 22:18, schrieb Ethan A Merritt:
> >
> > (2)
> > The linetype LT_NODRAW (defined as -3 in term_api.h) is supposed
> > to indicate that this line is not drawn at all.  When applied to a fill area
> > it is supposed to indicate that no fill is present (i.e. 100% transparent).
> > The lua code is treating this the same as LT_BACKGROUND, which is
> > suppoed to mean "draw this line in the background color".
> > It is true that if you are drawing directly onto the background these both
> > come out the same.   But if you draw a new line on top of a dark area,
> > say a previous filled area, then they most certainly are not the same.
> 
> the more I look through the code, the more confused I get concerning the 
> handling of LT_BACKGROUND, LT_NODRAW and FS_EMPTY:
> 
> * According to comments in many terminal drivers, FS_EMPTY is handled as 
> if it should be filled with background color. However, I didn't manage 
> to get any plot command which actually delivers the FS_EMPTY style to 
> the terminal driver. Do you have an example?

I wish I could say that all the intersecting features, code, and terminal
support followed some grand plan that had been well designed and laid out
in advance.  The addition of fill styles, including FS_EMPTY, came before
any of the rest.  It was a top-down design:  the top level data structures
and syntax came first, terminal support got added later one at a time.
So yeah, it could be that FS_EMPTY is implemented entirely in the core
code and none of the terminals ever sees that flag.

> I would expect the FS_EMPTY call to be handled like LT_NODRAW, i.e. no 
> fillarea should be drawn at all.

Yes.


> * Based on your description above (LT_NODRAW applied to a fill area), I 
> constructed the following script:
> 
> set object rectangle from graph 0,0 to graph 1,1 fc rgb 'red' fs solid
> set object polygon from graph 0.2,0.2 to graph 0.5,0.2 to graph 0.6, 0.7 
> fs solid fc lt -3
> 
> plot x
> 
> That however fails on all terminals I tested and always draws a white 
> polygon (tested cairo terminals, qt, svg, lua).

Remember that until relatively recently there was no clear distinction
between "linetype" and "line color".  The idea that "background"
can be a color rather than a terminal property was introduced, I think,
in version 4.2.

In version 5 I hope we have managed to disentangle linetype from color.
So "fillcolor bgnd" makes sense because "background" is a color.
But "fillcolor LT_NODRAW" does not, although I suppose if is accepted at
all then background color is the most logical thing to get.


Getting back to the lua terminal, my concern was specifically with
term->linetype(LT_NODRAW) followed by a series of term->vector()
commands.  Several places in the core code now emit this sequence in
order to "not draw" pieces of a surface or grid.  Arguably this should
be changed in the core code rather than individual terminals, but at
the moment it depends on the terminal itself knowing to turn the vector
commands into move commands when the current linetype is LT_NODRAW.

	Ethan

Re: volunteers to fix some minor bugs in the lua/tikz terminal?

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

Hi,

Am 02.09.2014 22:18, schrieb Ethan A Merritt:
>
> (2)
> The linetype LT_NODRAW (defined as -3 in term_api.h) is supposed
> to indicate that this line is not drawn at all.  When applied to a fill area
> it is supposed to indicate that no fill is present (i.e. 100% transparent).
> The lua code is treating this the same as LT_BACKGROUND, which is
> suppoed to mean "draw this line in the background color".
> It is true that if you are drawing directly onto the background these both
> come out the same.   But if you draw a new line on top of a dark area,
> say a previous filled area, then they most certainly are not the same.

the more I look through the code, the more confused I get concerning the 
handling of LT_BACKGROUND, LT_NODRAW and FS_EMPTY:

* According to comments in many terminal drivers, FS_EMPTY is handled as 
if it should be filled with background color. However, I didn't manage 
to get any plot command which actually delivers the FS_EMPTY style to 
the terminal driver. Do you have an example?

I would expect the FS_EMPTY call to be handled like LT_NODRAW, i.e. no 
fillarea should be drawn at all.

* Based on your description above (LT_NODRAW applied to a fill area), I 
constructed the following script:

set object rectangle from graph 0,0 to graph 1,1 fc rgb 'red' fs solid
set object polygon from graph 0.2,0.2 to graph 0.5,0.2 to graph 0.6, 0.7 
fs solid fc lt -3

plot x

That however fails on all terminals I tested and always draws a white 
polygon (tested cairo terminals, qt, svg, lua).

Best,
Christoph

Re: [Gnuplot-cvs] gnuplot ChangeLog,1.5046,1.5047

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

On Sunday, 14 September 2014 09:15:38 PM Petr Mikulik wrote:
> > Log Message:
> > new command 'toggle {<plotno>|"plottitle"|all}'
> 
> But this command already exists - it is the "raise" command

No. It has nothing to do with the "raise" command.

> I propose these new options are moved into the existing command.
> 
> +  New command `toggle {<plotno> | "plottitle" | all} has the same effect
> +  as left-clicking on the key entry for a plot shown by an interactive
> 
> - For reverse mouse buttons, MB left is menu action.
> - What is "key entry"?

  "key entry" =  plot title and line/point sample in the key.
  If you click on it, the corresponging plot toggles between being
  drawn or not drawn, while the other plots in the graph are unaffected.
  "toggle all" is the command line equivalent to hotkey "i".

  That is, the previous behavior was equivalent to
      bind "i" "toggle all"
  except that we didn't actually have a command "toggle all"
  Now we do.

	Ethan

Re: [Gnuplot-cvs] gnuplot ChangeLog,1.5046,1.5047

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

> Log Message:
> new command 'toggle {<plotno>|"plottitle"|all}'

But this command already exists - it is the "raise" command
(see also the "lower" command).

I propose these new options are moved into the existing command.

+  New command `toggle {<plotno> | "plottitle" | all} has the same effect
+  as left-clicking on the key entry for a plot shown by an interactive

- For reverse mouse buttons, MB left is menu action.
- What is "key entry"?
I guess it's just raising, isn't it?

---
Petr

Re: volunteers to fix some minor bugs in the lua/tikz terminal?

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

On Tuesday, 02 September, 2014 23:12:30 Christoph Bersch wrote:

> Another problem I encountered with the lua/tikz terminal is your recent 
> change of drawing the arrow shafts and the arrow heads separately, 
> <http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/graphics.c?r1=1.462&r2=1.463>.
> That doesn't work with the `tikzarrows` option, because the tikz-arrow 
> routine doesn't support negative headstyle. It seems to be possible to 
> draw only the arrow heads <http://tex.stackexchange.com/q/1260/33933>, 
> but I'm not sure if this works properly.
> 
> Do you have any suggestions for this?

The reason for that change was to insure that arrow heads were never
drawn with dashed lines.  Since the tikz private arrow routine will  (I think)
never draw with a head with dashed lines anyhow, the problem did not
exist there in the first place.  So it's unfortunate that the change broke
something.

My first inclination would be to have tikz interpret the negative head
style as a request to change the linetype to invisible, as shown in 
one of the stackexchange suggestions you linked to.

If necessary, the calling code could check some terminal flag - maybe
TERM_IS_LATEX? - and alter the call accordingly.  

I wouldn't be surprised if the new v5 dashed line code introduced other
bugs into the various TeX terminals.   

   cheers,

	Ethan

Re: volunteers to fix some minor bugs in the lua/tikz terminal?

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

Hi Ethan,

Am 02.09.2014 22:18, schrieb Ethan A Merritt:
>
> (1)
> The alpha channel in ARGB colors is ignored in term->set_color.
> The lua terminal does handle an alpha channel in other code paths,
> for instance in gfx.format_color, so clearly it must be possible.

I'm currently working on the ARGB part, which is already working.

I wasn't sure, how to handle properly the fill styles FS_OPAQUE and 
FS_SOLID with respect to the alpha value. Other terminals (checked qt 
and svg seem to use alpha values in both cases).

I can also have a look at the other points you raised.

Another problem I encountered with the lua/tikz terminal is your recent 
change of drawing the arrow shafts and the arrow heads separately, 
<http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/src/graphics.c?r1=1.462&r2=1.463>.
That doesn't work with the `tikzarrows` option, because the tikz-arrow 
routine doesn't support negative headstyle. It seems to be possible to 
draw only the arrow heads <http://tex.stackexchange.com/q/1260/33933>, 
but I'm not sure if this works properly.

Do you have any suggestions for this?

Best,
Christoph

volunteers to fix some minor bugs in the lua/tikz terminal?

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

Is anyone out there comfortable working with lua code?

My ability to understand lua code is practically non-existent.
Therefore I could use some help in fixing a few minor problems with the
lua/tikz terminal in the CVS source for gnuplot.

So far as I know, all of these require modifying the file
 .../term/lua/gnuplot-tikz.lua

(1)
The alpha channel in ARGB colors is ignored in term->set_color.
The lua terminal does handle an alpha channel in other code paths,
for instance in gfx.format_color, so clearly it must be possible.

(2) 
The linetype LT_NODRAW (defined as -3 in term_api.h) is supposed
to indicate that this line is not drawn at all.  When applied to a fill area
it is supposed to indicate that no fill is present (i.e. 100% transparent).
The lua code is treating this the same as LT_BACKGROUND, which is
suppoed to mean "draw this line in the background color".
It is true that if you are drawing directly onto the background these both
come out the same.   But if you draw a new line on top of a dark area,
say a previous filled area, then they most certainly are not the same.

(3)
Most terminals support a terminal option "linewidth <x>" that is used
as a multiplier for whatever individual linetypes are used in drawing.
That is, to make all of the lines in a plot twice the normal thickness,
you should be able to say
    set term tikz linewidth 2.0
Unfortunately this isn't implemented in the lua/tikz terminal

(4)
This one may not be possible.  At any rate it is trickier than the others.
The tikz terminal does not support the "boxed" attribute of text strings.
See for example the final plot in
    http://gnuplot.sourceforge.net/demo_cvs/datastrings.html


		any help is much appreciated,

				Ethan

Re: stat: standard deviation

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

On Sunday, 31 August 2014 11:12:26 AM Jonathan Thornburg wrote:
> On Sun, Aug 31, 2014 at 08:21:21AM +0200, pl...@pi... wrote:
> > Is there any difficulty in simply providing both, clearly labelled 
> > sample SD and population SD. This forces anyone who does not know what 
> > that means to find out ( or if the difference is small carry on 
> > regardless ).  Relevant assumptions made about the population, degrees 
> > of freedom etc explained in help.
> 
> I strongly agree -- this option provides the most useful information
> for users who *do* know what's going on, and avoids misleading the unwary.

Stats now calculates and returns the sample standard deviation STATS_ssd
(in cvs for 5.0 and 5.1).   The formulae used to calculate all single-column
stats values are now given in the TeX-derived documentation.  The difference
between _stddev and _ssd in particular is noted in all documentation formats.

	Ethan

Re: stat: standard deviation

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

On Sun, Aug 31, 2014 at 08:21:21AM +0200, pl...@pi... wrote:
> Is there any difficulty in simply providing both, clearly labelled 
> sample SD and population SD. This forces anyone who does not know what 
> that means to find out ( or if the difference is small carry on 
> regardless ).  Relevant assumptions made about the population, degrees 
> of freedom etc explained in help.

I strongly agree -- this option provides the most useful information
for users who *do* know what's going on, and avoids misleading the unwary.

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   currently on the west coast of Canada
   "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"

Re: stat: standard deviation

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

On 08/31/14 02:20, sfeam wrote:
> Gnuplot "stats" is not calculating the sample standard deviation.
>
> That is exactly the point being raised.
>
> The standard deviation, skew and kurtosis values all use a full-population
>
> assumption rather than being corrected for finite sampling.
>
> I definitely agree this should be clearly stated in the documentation,
>
> and I'll work on editing gnuplot.doc to include the relevant equation
>
> for each variable STATS_*.
>
> However that does not resolve the question of whether gnuplot should
>
> be reporting the finite-sampling assumption values instead of, or in
>
> addition to, what it reports now.
>
> By the way, this same point came up a while back with regard to the
>
> calculation of the bandwidth in "smooth kdensity".
>
> The code currently uses the population standard deviation, but arguably
>
> should use the sample-based standard deviation instead.
>
> The question did not generate any discussion at that time.
>
> Ethan
>

Is there any difficulty in simply providing both, clearly labelled 
sample SD and population SD. This forces anyone who does not know what 
that means to find out ( or if the difference is small carry on 
regardless ).  Relevant assumptions made about the population, degrees 
of freedom etc explained in help.

I don't recall the kdensity discussion. I usually use a suitable 
low-pass filter if I want "smooth" data, though I do on occasion use the 
bezier spline.

Peter.

Re: stat: standard deviation

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

On Saturday, 30 August 2014 07:39:57 AM pl...@pi... wrote:
> On 08/30/14 02:10, Allin Cottrell wrote:
> > It woud be sufficient either to state in the documentation that
> > gnuplot gives the MLE or to switch to the sample standard deviation.
> > I don't see much to be said for more complicated options.
> >
> > Allin Cottrell
> 
> 
> This should be clearly stated up front without the need for digging the doc.
> 
> If gnuplot is calculating the "sample standard deviation" ( which would 
> seem to be the most appropriate when given a sample of data ) then that 
> is what it should label it as when outputting the result, rather than 
> just 'std dev'.  The note about degrees of freedom assumption could go 
> in the doc.

Gnuplot "stats" is not calculating the sample standard deviation.
That is exactly the point being raised.

The standard deviation, skew and kurtosis values all use a full-population
assumption rather than being corrected for finite sampling.

I definitely agree this should be clearly stated in the documentation,
and I'll work on editing gnuplot.doc to include the relevant equation
for each variable STATS_*.

However that does not resolve the question of whether gnuplot should 
be reporting the finite-sampling assumption values instead of, or in
addition to, what it reports now.

By the way, this same point came up a while back with regard to the
calculation of the bandwidth in "smooth kdensity".
The code  currently uses the population standard deviation, but arguably
should use the sample-based standard deviation instead.
The question did not generate any discussion at that time.     

	Ethan

> Uneducated used of these kind of statistics is pretty common, perhaps 
> more so in population that are going to depend on a plotting program to 
> provide them, rather than having existing knowledge and software to 
> provide the stats.  It would be good to be as clear as possible about 
> what is being output with an assumption that user probably has little 
> knowledge of the subject.
> 
> A link to some starting point to further understanding as a note in help 
> may be valuable.
> 
> Peter.