On Fri, Aug 3, 2012 at 12:53 PM, Jan Hoogenraad
<[email protected]> wrote:
> For what it is worth, here the status of what I use to do for my
> commercial work.
>
> I'm running all my projects (fairly large data ones) as perl scripts
> which output gnuplot text output.
> Then, the surrounding makefile invokes gnuplot to create gif files.
> Make spreads this work over the processors.
> Output is often sorted on html pages made from perl code.
>
> I found this simple, robust, fairly quick, and great to debug (edit the
> command files for formatting, use the data output to share underlying
> data with colleagues).

Yes, it sounds like a great use of the tool set. I especially like how
make spreads the work across multiple processors. Perl multithreading
is not great. It's also a dangerous area for Prima, though if you use
Prima in -noX11 mode, it might allow threads. But now I'm really
speculating...

> Of course, this is not new-fashioned, hip, or object-oriented.
> On the other hand, it gives fast, interactive graphics from any
> webserver or local directory.

The P in Perl stands for Practical, not Pretty, so if it gets the job
done I don't think anybody here cares if it's hip. But I'd argue with
you about the interactive part. Let me put it this way: comparing the
interactivity that you get with your system to what's possible with
PDL::Graphics::Prima is like comparing C string manipulation to
regular expressions. Sometimes C manipulation functions is exactly
what you need, but once you've used regular expressions, you wonder
how you ever got along without them. When I talk about interactive
plotting, I'm interested in achieving a completely different degree of
responsiveness compared to what most of us normally experience with
most plotting libraries.

I have only just begun to write my documentation about creating
interactive plotting scripts with PDL::Graphics::Prima. Perhaps I
shouldn't push it when there's no resource for inquisitive
individuals, but I also want to clearly differentiate between what is
traditionally done with plotting and what is possible if you know what
you're doing. :-)

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan

_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl

Reply via email to