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: [email protected] [mailto:[email protected]] On Behalf Of David T. Lewis Sent: Monday, November 16, 2009 7:40 PM To: [email protected] 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 [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
