Graphs of points and lines, no fancy graphics to impress people, and options you can change easily? I think you want gnuplot. It can output to various formats, such as on a local X11 or Windows window, or send whichever of postscript, pdf, svg, png you can display best if you're working remotely.

I use gnuplot a lot. You can even rotate your 3D graphs in its window with mouse :)

Graphs of points and lines...

Not just graphs. And even when they are graphs, they aren't simple two or three sets of data, but rather the same set of data to be redisplayed as (for example) a GA program evolves.

I think you want gnuplot.

Not really. Actually, not at all. gnuplot won't allow me to (for example) adjust a low or high-pass filter threshhold as the data is being gathered and plotted.

It can output to various formats, such as on a local X11 or Windows window, or send whichever of postscript, pdf, svg, png you can display best if you're working remotely.

Output formats are of no importance, the plots are generally thrown away afterwards. If I need to keep and share them, a simple png or screen grab is good enough. And I never work remotely.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Not really. Actually, not at all. gnuplot won't allow me to (for example) adjust a low or high-pass filter threshhold as the data is being gathered and plotted.

well, that sounds like what this project promises, from the page:

.. to plot data [on gnuplot] on the fly as they are computed ..

it's in python though, and I didn't found a perl equivalent, perhaps you could make a port, if it suit your needs.

In 2012 (years after the original post), the mighty dkogan made PDL::Graphics::Gnuplot, later taken to the next level by drzowie (who also made PDL::Graphics::Simple to wrap that plus other PDL graphics modules).

Move up to Gtk2. ;-)

Perl/Gtk2 will accept binary data for images, and the DrawingArea widget has alot more flexibility than GD, in terms of setting up axis, and fonts, since it uses Cairo

As a matter of fact, there is a module Gtk2::Ex::Graph::GD. Also consider if you are using Firefox, IT itself uses Gtk2 based widgets, so why deal with javascript and all that mess? Just write your own app. :-) Sample code in the readmore

First, let me thank you for your response. I'm about to dismiss your suggestion, but I hope to show that I'm not doing so without due thought and consideration :)

Move up to Gtk2. ;-) Perl/Gtk2 will accept binary data for images,

The first problem is that despite several attempts, I've never managed to get GTK* to build here. The last time I attempted it, I was using 32-bit and it failed hard. I have no expectation that it would be any easier for my 64-bit setup.

But even if I could, it still doesn't answer most of the problems I have with such toolkits. Which essentially comes down to the fact they take over the whole application, forcing a particular (and abhorrent:) structure, and side-lining the raison d'etre for the applications existence.

For the type of applications I'm describing, there purpose in life is to generate and.or process large amounts of data. They are just command line apps that you fire off into the background and forget till they are done. But sometimes, especially during development, I want to be able to visualise what they are doing. Because they are dealing with large amounts of data, producing huge swaths of trace output--just reams and reams of numbers--is effectively useless, because the detail gets lost in the noise.

That's where the visualisation comes in. If you can throw a few lines or dots or blocks of color into an image and 'flicker compare' two different algorithms; or sequential iterations of same algorithm; the human brains uncanny ability for pattern recognition--hardwired and tuned over millions of years of evolution--can often detect patterns, trends and anomalies in huge amounts of data, that would be weeks of work to detect by looking at the same data represented as reams of numbers.

But the visualisations are not the primary purpose of the applications. Or even a required part of the final programs. They are just a transient part of the development process. The are effectively just a debugging aid, used in much the same way as Data::Dumper, for a quick check of what the program is doing to or with the data. And just like Data::Dumper debug lines, once the program is working correctly, they should be easily either disabled, or remove completely from the program. Their purpose served.

You just can't do that with a GUI toolkit.

Also consider if you are using Firefox, IT itself uses Gtk2 based widgets, so why deal with javascript and all that mess? Just write your own app. :-)

Why write an app when I have a browser that can already do everything I need? And more importantly, everyone has a browser. So if I want to share my visualisation with someone else--as in the OP of a question I am responding to here; or my brother in the states--they only have to install the BUI module (not a real suggestion for a name)--which should have no need for non-core dependencies and run anywhere perl does--and download the code I post and run it.

No need to have to seek out and download 27 billion dependency libraries spread all across the web and work out how to try and build them all together as is the case wth GTK* and similar.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

I have been working with the SIMILE Widgets to do some of what you are talking about(local filtering of data showing up in the visualization), but have found that the types of graphs are somewhat limiting(though the timeline is extremely cool!).

Protovis seems like it might provide you with the ability to

• Use just your local browser to display your visualizatoins
• Modify the visualizations on the fly
• Leave all the work in the browser/Avoid the shared variable portion of what you described because Protovis could handle your data mods on the fly

I think the animation portion of what you mentioned above could be handled as mentioned here-> Moving scales as time lapses..., though it might prove to be too slow for what you want.

I suspect this may not address everything you have mentioned above, but it may prove as a starting point for some of it. I have yet to dive into Protovis, but intend to as a way to enhance the SIMILE visualization tools. I have been using Perl to generate JSON data from SQL queries which is delivered when AJAX requests are made from the pages that contain the visualizations.

Hope this is of interest, if not entirely useful to you...

Could something like this -> Protovis meet your needs? Or be modified to do so? What strikes me is that you are asking for some local control over that which appears in the chart you are generating.

That is very interesting, but it's still not what I am looking for, for two reasons:

1. It uses a language that is not Perl. And that language is all about, and limited to, the generation of the pictures from a static dataset.
2. Whilst it allows the resultant graphic to be manipulated interactively, those manipulations can only be applied to a static dataset. Whereas I want to interactively adjust and control parameters that go into the generation of the dataset.

   This point is subtle enough that I've apparently failed to convey what I mean by it. I'll attempt to correct this below.

By way of example, in Re: Picking the best points, I produced a plot to visualise the algorithm I was suggesting to the OP.

The command: 868223-plot -N=1000 -RETAIN=50 that generates that plot has two command line parameters: -N=nnnn -RETAIN=mm.

The first controls the number of values in the input set of points (the red plot); the latter, the number that are retained in the results set (the green plot).

Here are a sequence of images taken starting with the same input set of 100 points, and reducing to 95, 50 down to the final 20.

What I would like to be able to do is present a page in my browser that might look something like this

What I want to happen is for any changes made to either of the "Input dataset size" or " Output dataset size" dropdown controls, causes the plot to be redrawn using those parameters.

But, and here is the real motivation, if the "Replot at each step?" checkbox is checked, then the perl program regenerates the plot after each point is eliminated, effectively animating the reduction process on the screen.

You can see this type of animation (usually Java applets) used all across the web for exploring/explaining algorithms. For example, different types of sort algorithm. I want that possibility, but written in Perl, and within my own box. If it also worked across the web, that would be a bonus, but that is not my goal.

I'm looking for the ability to create simple, local GUI front-ends to perl programs, without having to structure my code around the GUI. Perl has all the tools I need to produce the visualisations, but no simple mechanism for a) displaying those images in real time; b) accepting input from the operator to control those visualisations.

The browser has those capabilities and is both ubiquitous and platform independant. And with the advent of AJAX, the "whole page refresh for each change" thing has gone away.

So, I'm looking to cut out the need for the webserver, by moving the browser/perl program communications into a black box that runs in a thread. In pseudo-code, the perl application's view of this becomes something like:

use Bui;

my $html = do{ local $/; <DATA> };
my $Isize :shared = 100;
my $Osize :shared = 20;
my $step  : shared = 0;
my $img   :shared;

Bui->init( $html, \$Isize, \$Osize, \$step, \$img );

my $gd = GD->new( ... );

while( 1 ) {
    my @in = gendata( $Isize );
    plotPoints( $gd, @in );
    $img = $gd->png;
    while( @in > $Osize ) {
        my $discard = selectDiscard( @in );
        splice @in, $discard, 1;

        if( $step ) { ## If the "Replot at each step?" checkbox is che
+cked

             ## clear old plot
             $gd->drawRect( 0,0, $x, $y, white ); 

             ## Plot points minus the discarded one
             plotpoints( @in ); 

             ## Update the image; the next time the browser polls for 
+an update
             ## the revised image will be sent to the browser and be d
+isplayed
             $img = $gd->png; 
        } 
    }   
    ## clear old plot
    $gd->drawRect( 0,0, $x, $y, white ); 

    ## Plot points minus the discarded one
    plotpoints( @in ); 

    ## Update the image; the next time the browser polls for an update
    ## the revised image will be sent to the browser and be displayed
    $img = $gd->png; 
}
[download]

The BUI->init() call:

1. starts a thread;
2. which opens a listener socket;
3. gives an appropriate local url to the browser;
4. responds to the browser's connection by supplying the html + some small amount of javascript;
5. fields each XMLHttpRequest and
   1. updates the appropriate shared var(s) if it is an inbound update;
   2. resends the lastest rendition of the image, if it has changed, if the inbound request is an image update poll.

The main program just gets on with running the algorithm, with the full power of perl at its disposal, updating the image using whatever tools it desires to use, at whatever intervals are appropriate; and the BUI 'black box' takes care of all communication with the browser; which in turn takes care of all the display and interaction.

I hope that will clarify the problem I'm trying to solve and the idea I am presenting.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Thanks for the links. Of those, I'd only ever heard of MatLab.

For the type of plotting I'm interested in, these highly sophistacated products are overkill. With sophistication, comes complexity and learning curve. were they free products, they might be worth considering, but this isn't important enough to sepnd money on. I already know how to produce the types of plot I am interested in using the simple API of GD. It does all I need.

The only addition I am looking for is the ability to watch the plots evolve in real-time, rather than only seeing a static image of the final result. To this end, the browser and Canvas tag can provide this ability, and has a sufficiently simple api that the learning curve is minimal.

The final parts of the task, and that I was asking about, are:

1. Avoiding the need for a webserver.

   This is fairly easily achieved by running a simplified server in a thread, that can server to the browser, but without the need to be able to service more than one concurrent client. And without imposing the stateless nature of http on the interactions.

2. Avoiding the need to write code in another language (Javascript).

   I intend to achieve this by proxying the Canvas API within a perl object that talk to the browser via the server-in-a-thread.

I'm still working out how to do handle push within the (minimal & standardised) Javascript that will be served along with the HTML; and getting to grips with ajax for the browser interactions, but it just takes time.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.