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
