[kepler-dev] 2d display widget?

Dan Higgins higgins at nceas.ucsb.edu
Wed Jul 28 16:52:32 PDT 2004


Tobin,
    I have been fighting some of the same problems trying to integrate 
'R' into Kepler. (Incidently, 'R' has many of the same plotting 
capabilities as gnu-plot.) One problem with the CommandLine actor is 
that it waits for the command line subprocess process to end before 
returning control to Kepler. Thus (with 'R' anyway) any graphic displays 
created by the subprocess are closed. I had to save them as image files 
and then quit 'R' to continue with the Kepler workflow (and then display 
the saved image).

    As far as the inputFilePort, you may need to look at the code (or 
talk to Ilkay at SDSC who wrote it), but I think the idea is just to 
emulate the command line

process < infile > outfile

so simple file names seem to work for io redirection.

    Also I have been working on Windows, which has some problems with 
java subprocesses that don't seem to occur in Unix. It would be nice to 
have better plotting in Kepler that would work across platforms without 
having to buy Matlab!

Dan Higgins
NCEAS

---

Tobin Fricke wrote:

>On Wed, 28 Jul 2004, Edward A Lee wrote:
>
>  
>
>>If you want to take this on, I strongly recommend looking at Matlab for
>>inspiration...  Alternatively, you can just use the MatlabExpression
>>actor... The Matlab demo in the quick tour generates a beautiful 4-D
>>plot (3-D + time) of moving waves...
>>    
>>
>
>I suppose that would work, but external dependencies (on expensive
>software) are kind of a downer...  although I am completely in favor of
>'borrowing' ideas from Matlab (an extraordinarily well-engineered bit of
>software, IMO).
>
>I am playing with using gnuplot in this capacity, since gnuplot supports
>all kinds of jazzy plot formats, including various types of surface plots,
>is free, and runs on anything.  There are a few screenshots at
>http://wwww.gnuplot.info/ .  Exporting to postscript is another bonus for
>the possibility of use in publications.
>
>A first go was to use the org.sdm.spa.CommandLine actor to call gnuplot
>with the following command line:
>
>	echo "sin(x)" | gnuplot
>
>I'm a bit confused by the infileHandle port on CommandLine -- is it just a
>URL-or-filename?  Is there a way to support input redirection? i.e.,
>possibly to have the CommandLine actor start the cmdline process on
>initialize() and feed.
>
>Or would it be worth creating a distinct gnuplot actor?  Or maybe a
>UnixProcess actor could have these other (persistent process connected to
>Ptolemy via standard i/o) semantics.
>
>Another possibility is to have an actor that generates a FIFO (using
>mkfifo) or a temporary file (using mktemp) and (1) sends any input tokens
>to the standard input of this file/fifo, and (2) forwards the filename of
>the file/fifo as output, to be used, for instance with CommandLine.  This
>is an instance of the 'third party problem', with the unix filesystem
>providing a namespace.  Seems hackish to me.
>
>  
>
>>We did have a MatrixToImage actor at some point, but it was not well
>>written, and it was hard to use to get good images.
>>    
>>
>
>Being sort of lazy, my approach would be to take a Matrix, feed it through
>a Colormap, and produce an ImageToken.  This would lack many of the Matlab
>niceities but get the job done, I think.
>
>Tobin
>
>_______________________________________________
>kepler-dev mailing list
>kepler-dev at ecoinformatics.org
>http://www.ecoinformatics.org/mailman/listinfo/kepler-dev
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/kepler/pipermail/kepler-dev/attachments/20040728/789b5346/attachment.html>


More information about the Kepler-dev mailing list