vanrein / perpetuum Goto Github PK
View Code? Open in Web Editor NEWGenerating event-triggered code from Petri nets [C and Erlang]
License: Other
Generating event-triggered code from Petri nets [C and Erlang]
License: Other
We should split the compiler, so packages can be more subtle about dependencies
We will need to have a full grasp of what needs to be generated before we can split the functionality; specifically, issues #6, #9, #10, #11 and #13 need to be resolved first. Until then, we will be stuck with a monolithic compiler that needs all of pntools, cmph and that may even generate all output in one go.
Perpetuum is useful for (and intended for) key management process control. It may even live through the life of a process and wakeup near its end for short-lived secrets. To make this work, it can help to hibernate processes during the days that they are inactive, ideally after minimising memory footprint.
The same place may point to a transition with both an inhibitor arc and an outgoing arc. This can be meaningful when the outgoing arc has a lower multiplicity than the inhibitor.
Semantics for 1.1 will be made to blocks this until well-defined, and prior versions always block inhibitors with multiplicity.
The approach may require (in the general case) a split of a place into two identical copies, except:
This saves Petri Net state, and recovers it later. Synchronisation may be costly, can we keep it simple?
Complication: Timeout processing needs to be noted, but luckily it can be simply retried immediately after recovery. Limiting it to at most one timer seems fine. Since timeouts are also supported for the synchronous event message, this is a true concern.
Make a new testrun:
This is an auto-trigger capability, and may be centered around numbered hints that end up in flags carried around the loop; the loop can (if hints exist, and Colour changed since the last attempt) fold over the transmap to process those that are hinted, and to collect new hints. (One bit can hint that something was done at all.)
Application-driven hints can be returned as {retry,Hint(s)} and processed upon later process_hints() invocation, or automatically retried for asynchronous signals (without EventData).
The big thing about hints is how they shall be configured; it requires application logic; this is not available to the compiler, but it is during indstantiation.
Note that hints in no way undermine Petri Net semantics, where transitions may fire at random. The hint behaviour can be manually crafted by sending signals from transition callbacks to the application logic.
Specifically, we are looking into libev which appears to be the best one at present, in terms of scalability, portability and knowledge captured.
There are a few possible relations to consider, and ideally we would not pin down the Perpetuum users, but leave them free to make the combination they desire:
This is considered a Good Thing(tm) by Erlang engineers.
We have considered a few models up to here:
Request/Response. This is where Rick's idea for Perpetuum came from, as a model of asynchronous processing, cutting long-lasting (remote) requests into a request/response pair and treating each of these atomically on a transition. Requests would be outgoing actions, responses would be incoming events (and probably extend the logic of a surrounding event loop).
Longer Activities in Places. This addition by Adriaan meant that we did not have to explicitly write down requests and responses. We could make the following transitions dependent on the exit code or another form of return value, perhaps the errno
variable, to accommodate more flow control.
Multiple outputs. One longer-lasting process could bring out more than one output. A good application would be an LDAP query that responds with any number of SearchResult
messages before it sends SearchDone
. It is attractive to be able to process the individual SearchResult
messages separately, so their contents can more easily be dissiminated over the rest of the graph. This was not possible with a transition looping back to the place holding the long-lasting activity, but we needed that to retain the Petri net semantics that supports analysis. So we had to explicitly start the long-lasting activity before the place.
To suppress or trivialise reflow, and to change the reach of pre-expanded integers. Use with erlc -D...
Have a cache to share structure?
As described here:
An inhibitor arc drawn from place to a transition means that the transition cannot fire if the corresponding inhibitor place contains at least as many tokens as the cardinality of the corresponding inhibitor arc.
This is supported by GreatSPN, so the tools we recommend already do it. We just need to be a little more clever...
Move code that computes marking and canfire from Petri Net processes to caller. Specifically, rewriting internals into external handles such as atom()s naming transitions and places.
Since there may be (far) less callers, this should be more efficient in terms of storage size per Petri Net. Thus, is would help to have very large numbers of Petri Nets around.
It would not help to speed up parallel computations based on introspection. Usually however, introspection is not done but it is left to the Petri Net to backfire when a transition cannot occur (and the marking is not of external interest).
A few mechanisms can be thought of for composing Petri Nets:
These can be really helpful in managing complexity. When the models are supplied as a list, the compiler can, wel, er... compile them into a larger one. Since the editor and simulator are likely to not follow this, the emphasis on predictable semantics has been added above.
At the present time, it may be that the only thing we shall consider are the same-named transitions.
Error for kxover_server:transmap (58) is unexplained, apparently a problem with the "when" condition.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.