RE: [Catalyst] Chart::Graph::Gnuplot trouble.
Wade wrote: I do not get what you are pushing for -- from what I have seen normal catalyst code acts like normal perl code, except when the type of engine you are using requires its own stdio redirects -- in which case it must handle these in/outputs differently. If you want to have full control over the running procs use IPC::Run3, IPC::Run, IPC::Open3 or one of the other perl modules that afford you specific controls over the standard filehandles (per exec, system or run), or use an engine that does not require hijacking the handles for its own purposes I do not believe there _can_ be a generalized fix for all engines -- some _require_ stdio control to function. My scenario is the Catalyst web app is a product control panel and I want to be able to 1. fork off a /bin/tar to unpack an archive in the customer directory 2. fork off a /bin/mysql and pipe a proforma .sql file into it to create an application database In both cases picking up the exit status. Total time to run these is 1 second so I'm happy for the web app to wait on them. Both of these were hard to do under Catalyst even using IPC::Run. Regards, Peter ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Chart::Graph::Gnuplot trouble.
On Mon, 17 Mar 2008, Peter Edwards wrote: In Chart::Graph::Gnuplot latest it looks like line 768 is in _exec_gnuplot() which calls system() to run gnuplot. There are known problems getting the exit status back from a spawned process under Catalyst. I hit this a while ago. I didn't manage to track it down quickly so I found a workaround using IPC::Run. That might work for you if you use the pseudo-ttys option. Cat-devs, any pointers as to what in Catalyst is interfering with process spawning and I/O redirection? This has more to do with the kind of server you are running under than with the Catalyst itself. More specifically, it has to do with how the servers use the I/O, and yes, they do interfere. Most of them do. The only combination I can use successfully is Apache/mod_perl. I run gnuplot and r with IPC::Run3. Fastcgi and the Catalyst dev server screw up STDIN (I believe they reopen and select() on it, but I am not sure). I have studied all available server implementations in detail, but I can't recall the details -- please forgive my vagueness. I was convinced that there is nothing a person with my level of competence could do to fix that. So, I ended up running all my stuff under mod_perl (which I don't need otherwise), and I have to restart the server every time I change my code, which it quite a PITA, but I am grateful that there is at least one way to make things work. But I would also like a competent answer to this question: what can be done to make the normal Catalyst code interact with unix processes on all 3 channels? I mean, all 3: if a process spews something on stderr, I'd like to capture that, consider how severe the message is (unless it tells me in the status code) and possibly throw an exception and ultimately forward the message to the browser. I know I will be rebuked by the people thinking along the lines of cross-platform compatibility. Spare me. I will still want to run gnuplot and a thousand other things, and talk to them through the unix I/O, because that's all they afford me to do. Thanks, --Gene ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Chart::Graph::Gnuplot trouble.
Gene Selkov wrote: But I would also like a competent answer to this question: what can be done to make the normal Catalyst code interact with unix processes on all 3 channels? I mean, all 3: if a process spews something on stderr, I'd like to capture that, consider how severe the message is (unless it tells me in the status code) and possibly throw an exception and ultimately forward the message to the browser. If system() is broke, there are other alternatives. Check out IPC::Open3, and perldoc perlipc. You'll need to block SIGPIPE, and deal with reaping the zombie properly after the process exits. The Perl cookbook may have some good info too. If you really want to understand the ins and outs of UNIX programming, read the Richard Stevens books. Bruce ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Chart::Graph::Gnuplot trouble.
Gene Selkov [EMAIL PROTECTED] wrote on 03/20/2008 08:26:22 AM: On Mon, 17 Mar 2008, Peter Edwards wrote: But I would also like a competent answer to this question: what can be done to make the normal Catalyst code interact with unix processes on all 3 channels? I mean, all 3: if a process spews something on stderr, I'd like to capture that, consider how severe the message is (unless it tells me in the status code) and possibly throw an exception and ultimately forward the message to the browser. I do not get what you are pushing for -- from what I have seen normal catalyst code acts like normal perl code, except when the type of engine you are using requires its own stdio redirects -- in which case it must handle these in/outputs differently. If you want to have full control over the running procs use IPC::Run3, IPC::Run, IPC::Open3 or one of the other perl modules that afford you specific controls over the standard filehandles (per exec, system or run), or use an engine that does not require hijacking the handles for its own purposes I do not believe there _can_ be a generalized fix for all engines -- some _require_ stdio control to function. -Wade ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
RE: [Catalyst] Chart::Graph::Gnuplot trouble.
[info] test powered by Catalyst 5.7012 You can connect to your server at http://trillian:3000 exit value = 16777215 signal number = 127 dumped core = 128 at /usr/local/share/perl/5.8.8/Chart/Graph/Gnuplot.pm line 768 [info] *** Request 1 (0.143/s) [13684] [Sun Mar 16 22:16:47 2008] *** [debug] GET request for plot from 127.0.0.1 [debug] Path is plot In Chart::Graph::Gnuplot latest it looks like line 768 is in _exec_gnuplot() which calls system() to run gnuplot. There are known problems getting the exit status back from a spawned process under Catalyst. I hit this a while ago. I didn't manage to track it down quickly so I found a workaround using IPC::Run. That might work for you if you use the pseudo-ttys option. Cat-devs, any pointers as to what in Catalyst is interfering with process spawning and I/O redirection? Regards, Peter ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
