On Tue, May 28, 2002 at 06:54:44AM -0400, Peter Chen wrote:
> On Fri, 2002-05-24 at 13:05, [EMAIL PROTECTED] wrote:
> > (event-listener) -> [step1] -> (step2 args) -> [step2] ... -> [step n]
> ....
>
> > using my coloured Petri net implementation you could either use the graph
> > editor or write a simple hash describing the net. So it either gives you
> > a good graphical presentation of complex nets or a short and easy to write/read
> > code presentation.
>
> Do you have some POE code that may demonstrate this?
>
> I reread the introductory CPN paper a couple times. I must admit that I
> do not understand CPN well enough.
And I must admit that I probably didn't give a good link according to the
feedback. There is quite a lot of theory covering Petri nets. But using
them requires mostly common sense and some knowledge about the notation and
how you express conditions. As a starting point one could take a look at
easier types. For example, place/transition nets just have tokens without
a data type. Places carry a certain amount of tokens, arcs either consume
or produce a specified amount of tokens. So a transition would be enabled,
if the places that are connected by incoming arcs (place->transition, the
transition's pre-set) have enough tokens to satify the need of all the arcs.
That would be the transitions pre-condition, and the result would be the
tokens that outgoing arcs produce, thus enabling other conditions. In the
above example steps would be the transitions, and they would only be enabled
if the previous step had produced a result and put it on the proper place.
Having tokens with data types just makes it more powerful (and easier to get
real life data across). The basic concept stays the same. Attaching code to
transitions that gets run when a transition is fired just makes it easier.
You could as well produce a special token and put it on some place that is
linked to the interface you want to reach.
I cannot give final POE code since I'm not quite sure about the syntax that
would be used to specify place types. The net could be described similar to
the small sum test (just list all the transitions together with their arcs,
the arcs' expressions and the guard and code expressions). For the example
above this could be
stepN = {
arc_in => {
placeN-1 => {
type => 'single', # just check one token at a time
expression => sub { shift; }
# just consumes one token, enabled as soon as there is one token
# (that means one work-packet
}
},
arc_out => {
placeN => {
expression => sub {
my $data=shift; my_code_is_here($data->{placeN-1});
# produce a result, the argument is the token coming from the
# incoming arc, the result will be put on the place holding
# arguments for the next step
}
},
}
}
This is not really more than just writing the steps. But these would occur in
the correct order, and you could even execute several of these concurrently.
If you wouldn't want this, the first step would need to consume one token
acting as some kind of lock, and the last step should produce such a token
(using an additional place).
Embedding this net in a POE session should be as easy as calling a POE::CPN
constructor or running it inside a session. You would need to mark the
first and last place with some sort of tag. The first place (the event your
function is triggered by) would require information about the name of the
event, for example. There exist two POE related types of places for this,
POE::CPN::Place::Receive and ...::Send. The first is a normal event handler
producing a token for every received event, the latter sends events to sessions
or postbacks. POE context could be passed implicitely or explicitely, I don't
know what would be better yet.
Torvald
