Perpetuum 1.0 -- targeting Erlang and C

This release of Perpetuum is thought to be stable for both C and Erlang. The models for the two languages differ sharply, as explained in the README. Erlang/OTP has a rather elaborate model and language culture when it comes to processes, communication and design patterns. This knowledge has been applied in this model.

C on the other hand, leaves many choices to the programmer; we have not tried to force our choices onto the user, which means that s/he must do more work. The C model however, lends itself particularly well for (very) small environments, probably including 8-bit microcontrollers. This is when you start redesigning your washing machine with Petri Nets!

The build environment tooling is a bit rough around the edges, we are aware of that. But at least the innovative generator logic for Erlang is solid and heavily tested, and that has been our first concern with this release. The room to grow will likely come later; for now, our first aim is to use this release and see it in action. We'd love to hear if you are making good use of the software too!

Expanded test scripts (and fixed a few bugs)

The following requirements have been met:

• application logic
• '$init', '$stop'
• '$enquire'
• AppData, EventData
• all possible transreply()
• add '$default' to trans_switch()
• use/test trans_switch()
• timer logic
• backgrounded signals

What has not been done yet, is automate all these things and building. It is now time for cleanup towards a 1.0 release, for which the code is now in a good state:

• Finishing touches
• Document bitfield vectors
• Document non-event '$trans'
• Hush reflow verbosity
• Good test coverage
• CMake, CTest
• App dirtree buildup for Erlang
• Documentation update

Restructured reflow; no inhibitor multiplicity

Current releases are focussed on Erlang. The code generated for C is already believed to be correct.

This code is working. At least, inasfar as covered by the test directory, which means to start a process with start/3 or start_link/3 with the generic trans_noreply/4 backend, and then bother the Petri Net with event/3, marking/1 and both canfire/1 and canfire/2. The tests involve various traces through a simple Petri Net for a traffic light with night mode, and a complex Kerberos/DNS/DANE/ECDHE security process to be used for Kerberos Realm Crossover, including cached old rejections and successes, as well as refreshing of the latter when they are re-requested.

Reflow code has been tested by running the kxover_client.test which needs resizing:

• by pulling from compiler pregeneration transmaps
• by generating new transmaps dynamically
• by comparing the output from these two

Dynamic transmaps can be selected in the gen_perpetuum.erl file through a comment switch; it is not ready for routinely testing yet, but has been manually confirmed. Ideally, the compiler could be instructed to construct just one transmap, or more, and compare the results. Note that kxover_client combined with the thoroughness of the test runs are reasonably close to exhaustive tests.

Blocking of multiplicity on inhibitors is made explicit because we hitherto didn't consider its semantic twist [we didn't know about the syntax, really]. An adaption of the computation model seems possible, but needs a bit of thinking and is planned after the 1.0 release because it is not urgently needed by dependents on this project. Talk to us if you need to rely on it.

The following releases are planned to arrive at complete functionality:

0.9 will test integration with application logic, application data, event data, return values.
1.0 will cleanup documentation and code, strive for good test coverage, and integrate with CMake.
1.1 will support multiplicity on inhibitors, with borrowing between bitfields and place range care.

API call interaction with Petri Net processes

Current releases are focussed on Erlang. The code generated for C is already believed to be correct.

This code is working. At least, inasfar as covered by the test directory, which means to start a process with start/3 or start_link/3 with the generic trans_noreply/4 backend, and then bother the Petri Net with event/3, marking/1 and both canfire/1 and canfire/2. The tests involve various traces through a simple Petri Net for a traffic light with night mode, and a complex Kerberos/DNS/DANE/ECDHE security process to be used for Kerberos Realm Crossover, including cached old rejections and successes, as well as refreshing of the latter when they are re-requested.

The following releases are planned to arrive at complete functionality:

• 0.8 will add working reflow procedures, and have them tested.
• 0.9 will test integration with application logic, application data, event data, return values.
• 1.0 will cleanup documentation and code, strive for good test coverage, and integrate with CMake.