The image readers heap a lot of abuse on the streams given to them (reset vs. restoring position, sending #binary, #close, etc.). With PNG, I was able to create a modified reader that uses the IEND chunk to stop the read rather than the end of stream, which is hideous for some uses (such as mine). My "fix" could be applied to the existing code. Any interest?
My wrapper around the stdout pipe is still failing me, but I think I see why. With a proper page-reading trick, I will hopefully be able to get it to work, which I define here as having the PNG read stop at the end of the data. Not now though: it's getting too late for this nonsense :) Bill -----Original Message----- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Monday, November 16, 2009 9:28 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess - working on gnuplot Dave, That works - thanks! Knowing how much data to read will be a problem. My assumption was that I would have an image reader pull from the stream, taking the hint when it finds a complete image. Sadly, they do bad things to the stream, and I am not sure how to correct that. Bill -----Original Message----- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Monday, November 16, 2009 7:59 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess - working on gnuplot Dave, Thanks for the examples, and the reminder about Squeak/Pharo differences. I'll see what I can figure out. You might have already explained why one of my tests failed. I do want the option to keep gnuplot running. It might turn out that the cases in which that matters are precisely the ones in which gnuplot should be allowed to write the output files, but I'd rather not start out with that approach. Re the problems in Pharo, one perhaps completely worthless point: I ran some of the unit tests with Pharo launched from a terminal, and got Ipv6 related messages. It made no sense to me, but (I think) that code is whacked, and if there is any relationship, it *might* be the problem. Usual caveats about this being a potential red herring apply. Bill -----Original Message----- From: pharo-project-boun...@lists.gforge.inria.fr [mailto:pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, November 16, 2009 7:40 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] OSProcess - working on gnuplot On Mon, Nov 16, 2009 at 05:36:08PM -0500, Schwab,Wilhelm K wrote: > Dave, > > ProcessWrapper looks like a win32-only project to me, and Sig's gnuplot > package > appears to use OSProcess for unix. Please let me know if I am missing > something. > > It is true that OSProcess' unit tests cause Pharo to experience an > ugly death, but a lot seems to work. I am having some success with > code such as > > gp := PipeableOSProcess command:'gnuplot'. > gp > exec:'set output ""'; > exec:'set terminal png'; > exec:'plot sin(x)'. > > but I cannot get any output without shutting down the process. Are > any of the problems you describe relevant to that, or am I asking too > much, or perhaps just going about this incorrectly? > > Bill You may be hanging up trying to read a blocking stream from the gnuplot program. Try using #setNonBlockingOutput to prevent this. The following three examples all work for me (but I ran this on a Squeak image). Your original example, but with #setNonBlockingOutput: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. gp close. "close stdin to gnuplot, like <ctl>D" gp upToEndOfFile inspect. "stdout, the graphics output" gp errorUpToEndOfFile inspect. "stderr output if any" If you want to keep gnuplot running in background, you will have to read data as it becomes available using #upToEnd rather than #upToEndOfFile: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'. (Delay forMilliseconds: 1000) wait. "allow gnuplot to send data" gp upToEnd inspect. "all available stdout data" gp errorUpToEnd inspect. "all available stderr data" gp close. You can cause the background gnuplot interpreter to exit by sending it the "exit" command, or by doing "gp close" as in the examples above: gp := PipeableOSProcess command:'gnuplot'. gp setNonBlockingOutput. gp exec:'set output ""'; exec:'set terminal png'; exec:'plot sin(x)'; exec: 'exit'. "exit gnuplot, similar effect to gp close" gp upToEndOfFile inspect. gp errorUpToEndOfFile inspect. If the above examples do not work for you, it is very likely due to the current inconsistencies between OSProcess and Pharo, for which I do not yet have a solution (I would welcome any tips here, I tried again last night to figure out what's wrong and gave up in frustration :-/ ). HTH, Dave _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
