#1559 Qt gnuplot pipe occasionally deletes first character in commands

[John Woods]

I'm not one hundred percent certain this is a Gnuplot bug, but if it's a Ruby bug, it's in Ruby core. Gnuplot bug #1426 suggests that it's more likely to relate to my use of Qt on Mac OS X than my use of Ruby.

I'm using a Ruby script to receive data from 0mq and update multiple Gnuplot instances. The update takes the form:

plot '-' with lines linecolor "dark-red" linewidth 2, '-' title 'true' with lines linecolor "royalblue" linewidth 2
112 NaN 0.0 NaN
133 NaN 0.0 NaN
154 NaN 0.0 NaN
175 NaN 0.0 NaN
198 NaN 0.0 NaN
222 NaN NaN NaN
243 NaN NaN NaN
265 NaN NaN NaN
289 NaN NaN NaN
311 NaN NaN NaN
332 NaN NaN NaN
ee
3623 -1.000285976076409
3646 -1.0002896946770228
3668 -1.000293110898606
3690 -1.0002967112743915
3715 -1.0003008292864373
3739 -1.0003048092765943
3764 -1.0003088154204403
3787 -1.0003126791833803
3811 -1.0003165669658778
3834 -1.0003204787679019
3856 -1.0003242429672865
e

The error message is

gnuplot> lot '-' with lines linecolor "dark-red" linewidth 2, '-' title 'true' with lines linecolor "royalblue" linewidth 2
         ^
         line 5254: invalid command

The error only happens when there are many updates in quick succession. I cannot reproduce this by hand in the gnuplot console (perhaps because I can't paste quickly enough).

I'm using Gnuplot 5.0 patchlevel 0. I've attached a log of the output of my script so you can see that it works the first few times before starting to error out.

My next step will be to attempt this with something other than Qt and see if the same error occurs.

[Ethan Merritt]

From your description of the problem, I think it is likely to lie in the input stream processing (i.e. libreadline) rather than on the output terminal (qt / wxt / x11 / pngcairo / whatever).

The first thing I would check is whether the gnuplot executable is using the flaky OSX "libreadline" (really a wrapper around a modified BSD libeditline). If so, rebuild the program to use either the real GNU libreadline6 or gnuplot's built-in readline support. This is documented in the Release Notes and the installation guide.

On the other hand, I suspect the best approach is to replace the in-line data mechanism (plot '-') with the new datablock mechanism. So your script above would become

$DATA1 << EOD1
112 NaN 0.0 NaN
133 NaN 0.0 NaN
154 NaN 0.0 NaN
175 NaN 0.0 NaN
198 NaN 0.0 NaN
222 NaN NaN NaN
243 NaN NaN NaN
265 NaN NaN NaN
289 NaN NaN NaN
311 NaN NaN NaN
332 NaN NaN NaN
EOD1

$DATA2 << EOD2
3623 -1.000285976076409
3646 -1.0002896946770228
3668 -1.000293110898606
3690 -1.0002967112743915
3715 -1.0003008292864373
3739 -1.0003048092765943
3764 -1.0003088154204403
3787 -1.0003126791833803
3811 -1.0003165669658778
3834 -1.0003204787679019
3856 -1.0003242429672865
EOD2

plot $DATA1 with lines linecolor "dark-red" linewidth 2, \
     $DATA2 title 'true' with lines linecolor "royalblue" linewidth 2

[John Woods]

Thanks! This was very helpful.

[Dan Sebald]

Has the problem been solved? Should this bug report be closed?

[Dan Sebald]

Now I've experienced this bug. The first letter of commands is occasionally dropped when continually streaming through a pipe:

gnuplot> lot x
^
line 0: invalid command

However, this only seems to happen for Qt terminal and not X11 or WXT. Another characteristic of the Qt terminal is that upon exit, the gnuplot_qt process doesn't always close, maybe about 60% or 70% of the time does it close.

If there is a pipe used for communication between gnuplot and gnuplot_qt, might there be a pipe/buffer conflict with the pipe replacing STDIN?

[Dan Sebald]

Issuing "unset mouse" before streaming commands doesn't fix the problem. (I'm using Unix.)

[aloisius]

I can confirm this effect for v5.0.1 on linux.
I use tclTk with a pipe to gnuplot and this effect happens for Qt and not for x11 terminal.

[aloisius]

here is a small tcl script showing the effect of broken pipe on Qt

#!/bin/env tclsh

set   GP    [ open "| gnuplot 2>@1 " "r+" ]   ;# open pipe to gnuplot
fconfigure $GP -buffering none                ;# no buffering for pipe
puts $GP  { set term qt }                     ;# set terminal to qt / x11
flush $GP
puts $GP { plot sin(x) }
#  gnuplot  command which needs some time to execute
# A loop up to 80 with sin plots
set comm { do for [i= 1:80] { print i ;  replot sin(x) notitle }}
puts $GP $comm
# next gnuplot command is print "FINISHGNUPLOT"
puts $GP  { print "FINISHGNUPLOT"}

# Loop will catch all gnuplot output  until FINISHGNUPLOT occurs
gets $GP  in
while { $in != "FINISHGNUPLOT" } {
               puts "gnu > $in  "
               gets $GP in
               flush $GP
      }
puts "Finish"
​

If i use x11 instead of Qt the script runs and finished with

...
gnu > 77
gnu > 78
gnu > 79
gnu > 80
Finish
​

(I even run the script with a loop up to 1000 with X11 terminal)
For Qt the output is

...
gnu > 79
gnu > 80
gnu >
gnu > gnuplot> NISHGNUPLOT""
gnu >          ^
gnu >          line 0: invalid command
​

Here the command

print "FI

is lost. How much is lost is dependent on the system and the loop size.
If i use 40 for the loop maximum i got

gnu > 38
gnu > 39
gnu > 40
gnu >
gnu > gnuplot> int "FINISHGNUPLOT"
gnu >          ^
gnu >          line 0: invalid command
​

[Ethan Merritt]

Thank you for the test script.
I was finally able to trace the problem to a missing test in the qt terminal code for the presence of input from multiple sources being present at the same time. Fixed now in 5.1 and 5.0.2.
Sorry for mis-diagnosing the problem when it was originally reported.

[Dan Sebald]

Appears fixed. In the application I'm currently working on, I've removed all instances of an extra white-space I placed at the front of gnuplot commands. It recursively does hundreds of plots and exhibited no problems. Thanks.