From bob at ted.net Sat Dec 29 13:55:55 2007 From: bob at ted.net (Bob Blick) Date: Sat, 29 Dec 2007 13:55:55 -0800 Subject: [Santa-rosa-pm] charting tools Message-ID: <4776C26B.6080406@ted.net> Hi everyone, I'd like to produce some charts on demand for a webpage, and I'm wondering which perl module to use. I just want simple charts with data in the y axis and time on the x axis, like you'd expect to see temperature data, something like a chart recorder would produce. Legends and grids would be nice too. Either PNG or GIF output. Any suggestions? Thanks, Bob From geoff at broadwell.org Sat Dec 29 14:12:56 2007 From: geoff at broadwell.org (Geoffrey Broadwell) Date: Sat, 29 Dec 2007 14:12:56 -0800 Subject: [Santa-rosa-pm] charting tools In-Reply-To: <4776C26B.6080406@ted.net> References: <4776C26B.6080406@ted.net> Message-ID: <1198966376.5714.1177.camel@beast.home.broadwell.org> On Sat, 2007-12-29 at 13:55 -0800, Bob Blick wrote: > I'd like to produce some charts on demand for a webpage, and I'm > wondering which perl module to use. This may not be the best way to do it, depending on your requirements -- see below. > I just want simple charts with data > in the y axis and time on the x axis, like you'd expect to see > temperature data, something like a chart recorder would produce. Legends > and grids would be nice too. Lots of modules will do this. At a low level, GD and it's associated GD::Graph modules may do the trick. See: http://search.cpan.org/~mverb/GDGraph-1.43/ http://www.jonblog.uklinux.net/www/presentation/GDGraphing.html > Either PNG or GIF output. Also consider the HTML canvas element. The server just writes the raw data out to the web page, and some simple JavaScript does the actual graphing. That's how I did our systems performance dashboard at work, so that the stats server doesn't ever have to do the graphing, and to make page loads faster. The canvas element is supported natively on Safari 2.0, Firefox 1.5, and Opera 9.0, all of which have been out for a good while. It is also supported on IE (5? 6?) using Google's "excanvas.js" thunk layer. Still, if you have to support ancient browsers, you might need to stick with Ye Olde GD. -'f From geoff at broadwell.org Sat Dec 29 14:30:17 2007 From: geoff at broadwell.org (Geoffrey Broadwell) Date: Sat, 29 Dec 2007 14:30:17 -0800 Subject: [Santa-rosa-pm] Launching child processes with STDERR redirection Message-ID: <1198967417.5714.1193.camel@beast.home.broadwell.org> I keep forgetting to post this, and Bob's post reminded me. The code below launches a child process while capturing both STDOUT and STDERR *without* using shell redirections. This allows the list form of exec() to be used, thus improving security and correctness. Both routines die if the piped open (fork) or exec fails. Otherwise, they return either the pipe filehandle alone, or the pipe filehandle and the child's process ID, depending on calling context. The difference between the two routines is that one returns a filehandle that expects to be read from, and the other expects to be written to. Code-wise it's only swapping two characters in the open() call, so I could have just made a single routine with a special argument choosing pipe mode. Instead, I made two separate routines so that calling code can be a little cleaner and self-documenting: my $pipe = pipe_from_command(@command_and_args); while (<$pipe>) { ... } my $slave = pipe_to_command(@command_and_args); print $slave "Bow before me!\n"; Anyway, here's the code: ####### sub pipe_from_command { my $pid = open my $pipe, '-|'; die "Could not fork: $!" unless defined $pid; unless ($pid) { open STDERR, ">&STDOUT"; exec @_ or die "Could not exec: $!"; } return wantarray ? ($pipe, $pid) : $pipe; } sub pipe_to_command { my $pid = open my $pipe, '|-'; die "Could not fork: $!" unless defined $pid; unless ($pid) { open STDERR, ">&STDOUT"; exec @_ or die "Could not exec: $!"; } return wantarray ? ($pipe, $pid) : $pipe; } ####### -'f