Ouch! Okay this definitely sounds like a plausible cause for the problem. I'll have a look at these issues tonight, and see if we need to ditch open3 in favor of getting down to the bare metal. Meanwhile, anything you can find out about cygwin's treatment of the data is a Good Thing.
Given that Dima is now familiar with the gnuplot internals, I probably ought to bug him to see if we can improve the IPC aspects of gnuplot itself -- for example, when it is trying to read data from a pipe gnuplot just goes catatonic until it gets all the bytes it wants. It would be a Good Thing to be able to send it a signal telling it to wake up, it's not getting any more data. Cheers, Craig On Feb 12, 2013, at 10:57 AM, Chris Marshall <[email protected]> wrote: > From the cygwin API faq info: > > When processing in text mode, certain values of data are treated > specially. A \n (new line, NL) written to the file will prepend a \r > (carriage return, CR) so that if you `printf("Hello\n") you in fact > get "Hello\r\n". Upon reading this combination, the \r is removed and > the number of bytes returned by the read is 1 less than was actually > read. This tends to confuse programs dependent on ftell() and fseek(). > A Ctrl-Z encountered while reading a file sets the End Of File flags > even though it truly isn't the end of file. > > That means if the binary data being piped > through to gnuplot contains a Ctrl-Z then the > pipe will treat it as end-of-file. Is there a > way to check if that is happening. > > At any rate, the solution would be to > use binmode for the pipe. > > --Chris > > On Tue, Feb 12, 2013 at 11:15 AM, Chris Marshall <[email protected]> > wrote: >> Looking at the docs for IPC::Open3, I see the >> warning: >> >> If you try to read from the child's stdout writer >> and their stderr writer, you'll have problems with >> blocking, which means you'll want to use select() >> or the IO::Select, which means you'd best use >> sysread() instead of readline() for normal stuff. >> >> and I notice in the open3() call that you have >> both $err opened to child STDOUT and STDERR. >> Maybe that is triggering the problem. >> >> Would it be possible to redirect STDERR to >> STDOUT and then just open the one? >> >> --Chris >> >> On Tue, Feb 12, 2013 at 11:05 AM, Chris Marshall <[email protected]> >> wrote: >>> Still hangs. My guess is a problem with binary >>> data. I could not see where the input handle >>> was opened and had binmode set. Is there a >>> way to force ascii mode so I could at least >>> see if that is the source of the problem? >>> >>> --Chris >>> >>> On Tue, Feb 12, 2013 at 10:17 AM, Craig DeForest >>> <[email protected]> wrote: >>>> Hi, Chris, >>>> >>>> Thanks very much for giving this another look! >>>> >>>> Your image example definitely found a bug. The long delay does not happen >>>> for me under either Linux or MacOS. I suspect that there might a problem >>>> with Cygwin IPC that needs to be worked around - the pipe seems to be >>>> hanging up for some reason. >>>> >>>> As a simple test case, why not try >>>> >>>> PDL::Graphics::Gnuplot::image(rvals(5,5)) >>>> >>>> which should produce something very quickly? If *that* doesn't work, then >>>> we need to get someone with a Cygwin system and an afternoon to try to >>>> understand why it is failing. I could do that except for the part about >>>> having a Cygwin system. Would you be willing to let me ssh into your >>>> virtual machine some time? >>>> >>>> Cheers, >>>> Craig >>>> >>>> >>>> >>>> On Feb 12, 2013, at 8:04 AM, Chris Marshall <[email protected]> wrote: >>>> >>>>> Hi Craig- >>>>> >>>>> I'm trying again with the PDL::Graphics::Gnuplot on >>>>> my cygwin/win7 system to sort things out before the >>>>> coming PDL-2.4.12 release. >>>>> >>>>> Starting with the tutorial on the wiki, I have a >>>>> few questions/observations: >>>>> >>>>> - the terminal type seems to need quotes, 'png' >>>>> - how can I list terminal types from perl >>>>> - the default empty string gives terminal type '' >>>>> (this breaks the mouse click examples saying >>>>> that '' terminal does not support it---even though >>>>> the default for my system is 'x11' >>>>> - reading mouse on 'x11' gave no $status hash >>>>> >>>>> Finally, I got a window open and displaying ok, >>>>> so I tried to display an image. Boom! This is >>>>> a bit disheartening since the image was small >>>>> and doing images with plot overlays is specifically >>>>> what I need (often) to comprehend image data. >>>>> >>>>> I'm hoping it is a bug somewhere that can be >>>>> fixed. Here is the output from my pdl2 >>>>> session. The image is a shape [3,320,80] >>>>> float piddle with pixels in [0,1] and badvalues. >>>>> >>>>> pdl> use PDL::Graphics::Gnuplot >>>>> pdl> $hsv40 = get_hsv_frame(40); >>>>> Loading get_hsv_frame.pdl ...found ./crank/get_hsv_frame.pdl >>>>> pdl> PDL::Graphics::Gnuplot::image( {cbrange=>[0,1]}, $hsv40->mv(0,-1) >>>>> ) >>>>> Runtime error: Hmmm, my main Gnuplot process didn't respond for 60 >>>>> seconds. >>>>> This could be a bug in PDL::Graphics::Gnuplot or gnuplot itself -- >>>>> although for some terminals (like x11) it could be because of a >>>>> slow network. If you don't think it is a network problem, please >>>>> report it as a PDL::Graphics::Gnuplot bug. You might be able to >>>>> ignore this message, or you might have to restart() the object. >>>>> If you are getting this message spuriously, you might like to >>>>> set the "wait" terminal option to a longer value (in seconds). >>>>> at /cygdrive/f/perl/local/lib/perl5/PDL/Graphics/Gnuplot.pm line 6030. >>>>> >>>>> PDL::Graphics::Gnuplot::_checkpoint('PDL::Graphics::Gnuplot=HASH(0x820c3e48)', >>>>> 'main', 'HASH(0x82098438)') called at >>>>> /cygdrive/f/perl/local/lib/perl5/PDL/Graphics/Gnuplot.pm line 2462 >>>>> PDL::Graphics::Gnuplot::plot(undef, undef, >>>>> 'PDL=SCALAR(0x820bdcb0)') called at >>>>> /cygdrive/f/perl/local/lib/perl5/PDL/Graphics/Gnuplot.pm line 3098 >>>>> PDL::Graphics::Gnuplot::image('HASH(0x825d8bb0)', >>>>> 'PDL=SCALAR(0x820bdcb0)') called at (eval 466) line 5 >>>>> pdl> PDL::Graphics::Gnuplot::image( {cbrange=>[0,1]}, >>>>> $hsv40->mv(0,-1)->setbadtoval(0) ) >>>>> Runtime error: Hmmm, my main Gnuplot process didn't respond for 60 >>>>> seconds. >>>>> This could be a bug in PDL::Graphics::Gnuplot or gnuplot itself -- >>>>> although for some terminals (like x11) it could be because of a >>>>> slow network. If you don't think it is a network problem, please >>>>> report it as a PDL::Graphics::Gnuplot bug. You might be able to >>>>> ignore this message, or you might have to restart() the object. >>>>> If you are getting this message spuriously, you might like to >>>>> set the "wait" terminal option to a longer value (in seconds). >>>>> at /cygdrive/f/perl/local/lib/perl5/PDL/Graphics/Gnuplot.pm line 6030. >>>>> >>>>> PDL::Graphics::Gnuplot::_checkpoint('PDL::Graphics::Gnuplot=HASH(0x820c3e48)', >>>>> 'main', 'HASH(0x825c60c0)') called at >>>>> /cygdrive/f/perl/local/lib/perl5/PDL/Graphics/Gnuplot.pm line 2389 >>>>> PDL::Graphics::Gnuplot::plot(undef, undef, >>>>> 'PDL=SCALAR(0x825ccb28)') called at >>>>> /cygdrive/f/perl/local/lib/perl5/PDL/Graphics/Gnuplot.pm line 3098 >>>>> PDL::Graphics::Gnuplot::image('HASH(0x8210deb0)', >>>>> 'PDL=SCALAR(0x825ccb28)') called at (eval 475) line 5 >>>>> >>>>> Hope this gives you some ideas. Do you have >>>>> a working image example that I could try? >>>>> >>>>> Thanks, >>>>> Chris >>>>> >>>> > _______________________________________________ Perldl mailing list [email protected] http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
