PDLPorters/PDL-Graphics-Gnuplot

Simple line plot hangs on Windows

bruceravel opened this issue · 10 comments

bruceravel commented

I don't understand what the purpose of this bit of code is:

https://github.com/drzowie/PDL-Graphics-Gnuplot/blob/master/lib/PDL/Graphics/Gnuplot.pm#L3251-L3258

I want to diagnose the problem, but I don't know what I am looking at.

I am sending two piddles to make a simple line plot, like so:

gplot({xlabel=>'Emission energy (eV)', ylabel=>'XES'},
        with=>'lines', lt=>1, lw=>1, legend=>$legend,
        $energypdl, $xespdl)

where the two piddles are pretty short -- 200 points or fewer.

If I comment out the entire unless block, the plot happens just fine. Otherwise the process hangs after 2 or 3 times through the do ... until loop.

Without an understanding of why that sysread voodoo is necessary, I am not sure how to raise a clearer issue or suggest a solution to the problem.

drzowie commented

That block is intended to scoop up characters written by Microsoft Windows to its end of the pipe. Windows lacks input control signals and several other POSIX niceties, so we snarf up characters until we get either nothing or a '>' (presumably the end of the "gnuplot>" prompt). It appears that instead your process is deadlocking. It the loop buzzing? If so, you could find out what character it is returning, and make that an exit condition. If it's hanging, I'd welcome a fix.

bruceravel commented

@drzowie: I will look into it. I have an experiment coming up next month with Windows-using collaborators, so I will need that to be working. I'll get back to you soon.

drzowie commented

Awesome!

drzowie commented

If you're using a new version of Microsoft Windows, it might be worthwhile to just try turning off the $ms_io_braindamage flag and see if it works better. It's remotely possible that Microsoft finally embraced the POSIX standard. There's probably also a better way of doing IPC within the Microsoft context -- the current $ms code uses a sort of cargo-cult approach since I don't do Windows.

bruceravel commented

@drzowie
Craig, I spent some time looking into this this morning. The bit of code in question comes into play when sending ASCII chunks of data to gnuplot -- essentially sending the rows of a two-column data table to gnuplot line by line.

I am pretty flummoxed. The do loop hangs after 2 bytes of the first line sent. It enters the call to sysread to fetch the third byte and never returns. And I cannot figure out how to make Windows timeout the call to sysread -- apparently a common problem.

I don't think this issue should be closed, but I have no advice for a solution. As I said in my original post, I am simply commenting out the unless block.

Windows .... ....

drzowie commented
bruceravel commented

Well, truth is, I only have one test case. However, the commenting-out solution improves usability in 100% of them 😄

amba commented

We are also experiencing this issue in Lab::Measurement.

@bruceravel: which version of gnuplot and windows are you using?

In my tests (latest Strawberry Perl on a Windows 7 VM) the following gnuplot versions show this problem:

  • 4.6.6
  • 4.6.7
  • 5.0.0
  • 5.0.1
  • 5.0.5

i.e. those versions do not echo back commands and the P::G::G tests fail with a deadlock, see my recent report.

While older versions of gnuplot echo back commands and the P::G::G tests pass. Tested versions:

  • 4.6.0
  • 4.6.3
  • 4.6.5

From this it seems that gnuplot and not windows is guilty for the changed behavior.

drzowie commented

Sorry this took so long to address. I've incorporated amba's fix into the main tree. I'm planning to push a CPAN update later today.

drzowie commented

I'm marking this fixed based on amba's input.