Re: [eclipse-clp-users] Visualizing delayed goals as 2D spatial regions in Java

-dp- wrote:
> I'm looking for suggestions about how I might implement a visualization. 
> My ECLiPSe program takes as input a set of points in 2D space, plus 
> information about the properties of each point that helps predict where 
> each point will be next. The delayed goals at any point are equations in 
> terms of X and Y variables that describe subregions (e.g. circles or pie 
> shapes around each point) of where each point might be next. I want to 
> create a graphical display of the points and subregions (as circles, 
> etc) that will be updated as delayed goals change.
> 
> I've looked at ECLiPSe%206.0/doc/visualisation/visualisation003.html in 
> my local install docs. Although none of the provided viz clients suit my 
> need directly, perhaps lib(java_vc) is something I should try to build on?

That would definitely make sense.  If you can shoehorn the existing
"viewables" on the ECLiPSe side into holding the information that you
need to convey to the viewer (say in a similar way that the Gantt
chart viewer expects viewable-matices of a particular form), then
you only need to add a new viewer on the VisClient (Java) side.


> My earlier idea was to use the Java embedding interface. I don't need to 
> display every change to delayed goals; I would be fine with calling a 
> dedicated predicate whenever I wanted to update the display. So, I 
> thought I would use delayed_goals/1 to get the delayed goals, then 
> change all variables to specially-named strings (to avoid having them 
> rendered as nulls), then put them on my eclipseToJava queue (and write 
> an equation grapher in Java).

I think this is all pretty much subsumed by lib(viewable)!

So even if you don't want to integrate with the existing Java
Visualisation Client, you could still use lib(viewable) on the
ECLiPSe side, and write your own visualisation client that uses
the same communication protocol.  You may have seen that th
distribution contains a library(tty_vc) which is a simple
visualisation client written in ECLiPSe itself, which you can
use as a guideline for implementing the communication protocol.

If your viewer is in Java, you can reuse the Queues-functionality
from the Java interface, which is what the existing java_vc does
as well.


 >
 > Is there a better way?

If you don't like to build on top of existing stuff, you can
always open socket connections onto which you let the ECLiPSe
side write the relevant information in a format of your choice,
and connect your viewer process to the other side.

But an integrated new viewer that we could add to the ECLiPSe
distribution would of course be much nicer!


-- Joachim