[kepler-dev] Actor is not ready to fire messages

Wed Jan 9 21:30:32 PST 2008

Hi Edward:

We are interested in static analysis methods for workflows and thus CAL
looks like an interesting starting point.
In fact, when I had a look at it in the past I was intrigued by CAL(trop) :)

For us, in addition to production/consumption rates, also other type
information is of interest, e.g., one could think about adding a unit type
system (cf. Rowland's work) or a semantic type system (cf. Bower's work) and
other goodies.

Indeed a fun research / thesis topic -- will let you know if someone shows
up at our doorstep ;-)

cheers

Bertram

--
Bertram Ludaescher, Assoc. Professor
Dept of Computer Science & Genome Center
University of California, Davis
One Shields Avenue, Davis, CA 95616
Ph: +1-530-754-8576
ludaesch at ucdavis.edu

On 1/8/08, Edward A. Lee <eal at eecs.berkeley.edu> wrote:
>
>
>
> This is actually a rather interesting research problem.
> We have two major sets of (partial) results on this:
>
> - The behavioral interfaces that Yuhong Xiong developed
>    in his PhD thesis and several papers on the Ptolemy website.
>    These use interface automata to specify actor and director
>    assumptions and behaviors, and formal composition to check
>    compatibility. It is effectively a "behavioral type system."
>    This has never really been "productized" in the Ptolemy tree.
>    It's just a concept demonstration phase.
>
> - The Cal actor language, developed by Joern Janneck while he
>    was a postdoc here. One of the main motivations of Cal was that
>    actor definitions could be statically analyzed for token
>    production/consumption behavior (unlike Java actors, where
>    the question is actually undecidable).  This static analysis
>    has never been implemented, but there would be considerable
>    interest in doing so.  Cal has been adopted by MPEG as the
>    specification language for all video and audio coding standards
>    (!) and is also being extensively developed at Xilinx as a
>    hardware design language for FPGAs.
>
> Anybody want a PhD thesis topic?
>
> Edward
>
> At 11:08 AM 1/8/2008, Timothy McPhillips wrote:
> >Hi Christopher,
> >
> >The idea of requiring that actors declare SDF-safety by implementing
> >a Java interface is interesting.  There seem to be a number of
> >related issues it'd be nice to address at some point.
> >
> >A general issue, it seems to me, is that it can be hard for users
> >(developers included) to know what components (actors, directors,
> >etc) can be used productively together. Knowing what actors are
> >compatible with which directors is one example of this issue.
> >Another example is that different actors may be incompatible with
> >each other due to differences in how data is managed (ports vs
> >parameters, sequences of tokens vs arrays of tokens when handling
> >variably-sized collections of data, etc).  One may find an actor that
> >sounds like it does what one desires, but due to differences in how
> >data is consumed or produced it may turn out that the actor won't
> >work with the actors (or director) one has already selected for use
> >in a workflow.   So there may be multiple dimensions in which
> >component incompatibility may arise.
> >
> >Examining the documentation or source code for actors can reveal why
> >certain components don't work well together, but I wonder if there
> >isn't a more general solution that makes it easy to see what actors
> >and directors are meant to work well together in the first place.
> >
> >What do you think?
> >
> >Tim
> >
> >On Jan 8, 2008, at 7:51 AM, Christopher Brooks wrote:
> >
> >> Are you using the SDF director?
> >> My suggestion is to not use BooleanSwitch in SDF.
> >> As to why, see Dan Higgins' explanation in
> >> http://www.kepler-project.org/Wiki.jsp?page=DirectorsInKepler
> >>
> >> My understanding is that BooleanSwitch may be used in SDF, but only
> >> under carefully controlled situations.  This issue seems to come up
> >> fairly regularly with BooleanSwitch, the documentation should be more
> >> clear, I'll see what I can do.  Maybe we should disable BooleanSwitch
> >> under SDF, or at least have it print a message or something.  Perhaps
> >> actors that are SDF safe should implement a specific interface, or
> >> actors in actor/lib that are not SDF safe should implement a specific
> >> interface.
> >>
> >> _Christopher
> >>
> >> --------
> >>
> >>     Hi,
> >>
> >>     I create two custom actor, one of them reads a binary file and
> >> other
> >>     writes the input into a netcdf file (i also update my actors
> >> according
> >>     to earlier suggestions about stopping workflow) and the workflow
> >>     structure is similar to BinaryFileRead and BinaryFileWrite but
> >> in my
> >>     case there is only one file which has multiple time step data.
> >> I am
> >>     using Boolean Switch actor to stop my work flow but at the last
> >>     iteration it gives me "Actor is not ready to fire" messages.
> >> So, I check
> >>     the "end of file" port of my custom binary file reader actor using
> >>     display actor and it seems ok.
> >>
> >>     any suggestion will be helpful,
> >>
> >>     best wishes
> >>
> >>     --ufuk
> >>     _______________________________________________
> >>     Kepler-dev mailing list
> >>     Kepler-dev at ecoinformatics.org
> >>     http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/
> >> kepler-dev
> >> --------
> >> _______________________________________________
> >> Kepler-dev mailing list
> >> Kepler-dev at ecoinformatics.org
> >> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/
> >> kepler-dev
> >
> >_______________________________________________
> >Kepler-dev mailing list
> >Kepler-dev at ecoinformatics.org
> >http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
> ------------
> Edward A. Lee
> Chair of EECS and Robert S. Pepper Distinguished Professor
> 231 Cory Hall, UC Berkeley, Berkeley, CA 94720-1770
> phone: 510-642-0253, fax: 510-642-2845
> eal at eecs.Berkeley.EDU,
> http://www.eecs.berkeley.edu/Faculty/Homepages/lee.html
>
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/kepler-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/kepler-dev/attachments/20080109/e9742339/attachment.htm