Also, if the problem is CR/LF/Ctrl-Z translation from text mode then if the sequence of bytes for CR, LF are found in the data, it would get converted to a single \n which would give short data to gnuplot.
On Tue, Feb 12, 2013 at 1:53 PM, Chris Marshall <[email protected]> wrote: > After a clean restart of the pdl2 shell, I was able to get > > pdl> use PDL::Graphics::Gnuplot; > pdl> PDL::Graphics::Gnuplot::image(rvals(50,50)); > pdl> PDL::Graphics::Gnuplot::image(rvals(50,50)->(:,:,*3)); > > but > > pdl> PDL::Graphics::Gnuplot::image(rvals(50,100)->(:,:,*3)); > > hangs so the problem seems to be size related. I tried > generating an image with just Ctrl-Z in it but that did not > appear to make a difference (although i am not sure that > the data sent to gnuplot ended up having the Ctrl-Z in > it... > > So things are getting better---although I still can't plot > my 320x80x3 images! :-( > > --Chris > > > > > On Tue, Feb 12, 2013 at 1:34 PM, Craig DeForest > <[email protected]> wrote: >> 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
