In theory this method could be used to build testing output devices.
specific devices that expect certain data to be sent to them and raise
errors if the data is wrong. I think there are a lot of architectural
hurdles to jump before it would be do-able, but definitely something to aim


On Mon, Jul 7, 2008 at 10:28 PM, Edward A. Lee <[EMAIL PROTECTED]>

> This sounds like a great idea!
> One possible application that would make my life easier is in building
> regression tests.  If the Test actor could display results when not running
> headless, and not display them when running headless, that would make
> developing
> tests much easier...
> Edward
> At 09:42 PM 7/2/2008, Tristan King wrote:
> >I've started doing a bit of work on building an actor IO package (<
> >
> >The purpose of this is to provide user input and output for actors so that
> the actors themselves don't have to be responsible for how they get user
> input, or how output is displayed. This will help to build actors that are
> useable in gui and headless environments without having to have modified
> actors for each situation.
> >
> >I've built a simple prototype which uses an IO factory which is embedded
> in the Manager (since all actors can get access to the manager which
> controls them). When an actor requires an IO "device" it makes a request to
> the IO factory which returns an instance of the desired "device". For
> example, the Display actor requests a Text-based output device. This device
> implements a standard text based output device interface which has a
> write(String) function, and all the Display actor has to do is "write" the
> text to the device which handles how to display it. I've used spring to
> instantiate the correct IOFactory so that in the case of vergil, each
> manager is loaded with a and if vergil is
> not used the manager defaults to a
> >
> >My work is currently stored in my ptII git mirror, in a branch which has
> been converted for maven compilation.
> >If you want to clone the whole repository here are the git commands to
> clone the repository and to get to the branch (this will take a while):
> >
> >git clone git://<>
> >git checkout -b actorio origin/actorio
> >
> >or you can download the current snapshot of the branch (which is about
> 35mb) from:
> ><
> >
> >you can then run it by doing:
> >
> >mvn compile # compiles the code, may take a while the first time while
> maven sorts out it's dependencies
> >mvn exec:exec # starts vergil
> >
> >then fire up any workflow while uses a Display actor. Note that i'm
> rubbish with swing and some of the window placing/sizing functionality has
> been removed to facilitate the separation of the actor from the
> visualisation, so the display window isn't nearly as good as the old one. If
> you start the workflow using MoMLSimpleApplication (i.e:
> >
> >mvn compile
> >java -cp
> target/classes:$HOME/.m2/repository/org/springframework/spring-context/2.0.8/spring-context-2.0.8.jar:$HOME/.m2/repository/org/springframework/spring-beans/2.0.8/spring-beans-2.0.8.jar:$HOME/.m2/repository/org/springframework/spring-core/2.0.8/spring-core-2.0.8.jar:$HOME/.m2/repository/log4j/log4j/1.2.15/log4j-1.2.15.jar:$HOME/.m2/repository/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
> ../test.xml
> >
> >) it will print the output of any Display actors to the console.
> >
> >If other people want to work on this, I will create a new branch for it on
> the ptolemy II svn (it requires a few changes to the core of ptolemy so i'm
> not gonna commit it to the trunk) and put it there in makefile building
> mode.
> >
> >So, is anyone else interested in this? I think it's a key component in
> making kepler available in multiple environments. But it's a big change,
> much too big to be left up to one person. I would feel a lot more
> comfortable with a bunch of people telling me my ideas and designs are
> rubbish and help me build a good system rather than to build something that
> no one but me wants to use.
> >
> >Things that need to be done:
> >* My factory idea and prototype architecture needs to be criticised.
> >* Types of "devices" need to be defined (i.e. text output, image output,
> file output, graph output, etc)
> >* IO Factory and device interfaces need to be defined.
> >* Existing actors need to be modified to use the factory.
> >* standard factory implementations need to be written (i.e. I'm rubbish at
> swing and thus someone else should do the vergil factory).
> >
> >Comments? Ideas? Criticisms?
> >Cheers
> >-Tristan
> >
> >--
> >Tristan King
> >Research Officer,
> >eResearch Centre
> >James Cook University, Townsville Qld 4811
> >Australia
> >
> >Phone: +61747816902
> >E-mail: <mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED] www: <
> ------------
> Edward A. Lee
> Robert S. Pepper Distinguished Professor
> EECS Dept., 545Q Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> phone: 510-642-0253, fax: 510-642-2845

Tristan King
Research Officer,
eResearch Centre
James Cook University, Townsville Qld 4811

Phone: +61747816902
E-mail: [EMAIL PROTECTED] www:

Reply via email to