Gaston is a plotting package that uses gnuplot as a backend. Gaston uses stdin, stdout and stderr streams to communicate with gnuplot. This works well in Linux, but (after a user report) I found that it is currently failing in Windows. Last time I tested on Windows was with Julia v0.6, and things worked correctly; however, Gaston has changed significantly since then.
My understanding is that libuv should handle all OS differences, which makes me suspect that this problem might be of interest. This is on Julia v1.1 and Windows 10, with Gaston master.
The problem manifests itself as follows:
julia> using Gaston julia> plot(1:10) Error showing value of type Gaston.Figure: ERROR: Gnuplot is taking too long to respond. Stacktrace:  error(::String) at .\error.jl:33  llplot(::Gaston.Figure) at C:\Users\mxbiee\.julia\packages\Gaston\dhvHQ\src\gaston_llplot.jl:190
The full stacktrace is here.
Julia starts gnuplot with this code:
mutable struct Pipes gstdin :: Pipe gstdout :: Pipe gstderr :: Pipe Pipes() = new() end const P = Pipes() function __init__() try success(`gnuplot --version`) catch error("Gaston cannot be loaded: gnuplot is not available on this system.") end gstdin = Pipe() gstdout = Pipe() gstderr = Pipe() gproc = run(pipeline(`gnuplot`, stdin = gstdin, stdout = gstdout, stderr = gstderr), wait = false) process_running(gproc) || error("There was a problem starting up gnuplot.") close(gstdout.in) close(gstderr.in) close(gstdin.out) P.gstdin = gstdin P.gstdout = gstdout P.gstderr = gstderr return nothing end
When plotting, Julia creates tasks to read gnuplot’s stdout and stderr. The task code is here. For each plot, two new
async_readers are instantiated, one per stream, here. Then, Gaston tells gnuplot to send a special token (
GastonBegin) through each stream. After plotting, the token
GastonDone is sent. Thus, Gaston can identify when gnuplot started and when it finished plotting, and it can tell if anything went wrong. That logic starts here.
As you can see from the error above, Gaston never finds the tokens in the stream, so it declares a timeout.
I hesitate to open an issue, since the problem seems too open-ended and I don’t have the time or resources to narrow it down. However, I’ll be happy to open one if people think it’s a good idea. I’ll also be happy to provide additional information, or run tests, if somebody (I hope!) decides to take the time to investigate this problem.