oswald2 / auris Goto Github PK

The system has to use multiple state machines (on the protocols as well as on TC verification etc).

Currently, these are a RIO/IO spaghetti mess. A cleaner alternative would be much appreciated.
Following requirements:

• Must support STM. The state machine requirest multiple threads. State changes are often stored in TVars. The input is often provided via either a STM conduit or an STM TBQueue. There can be multiple STM input queues present (e.g. in FOP1 there is the to-be-encoded command input and the CLCW input, which are independent)
• Timers must be supported. This involves IO functionality. Reason is, there are timeouts in the protocol, which trigger certain actions. This must be handled, also in combination with STM waiting for input and state changes. Up until now, the timer-wheel library was used, but now I switched back to updatable-timers from Paolo.

Currently, the tables of the MIB are loaded via cassava and manually converted into the data structures of the data model. This could be cleaned up by utilising the lens library.

Since probably most of the other contributors, like me, got into this project via your presentations at multiple Haskell-hackathons, it would maybe be a good idea to not only create some guidelines for contributions (to give a bar for code quality since most are maybe, like me, beginners and are rather producing confusing code which on top is not readable as well :) ) but maybe also to create a space (somewhere, Slack, Discord?) for discussions.
Especially the space for discussions and progress would be interesting since currently most of the stuff happens in the slack/discord spaces of the specific hackathon.

I just randomly file this issue, since I asked myself if you have been hacking on MuniHac (which I was unable to attend) and made any progress :).

Feel free to delete this if this does not fit :).

Sending a TM packet from the ASCII RTE MIB with a pid event causes extraction to fail with an index out of bounds erreo on a ByteString.

Current extraction needs to be checked.

Also, writing a bit-parser (with binary-bits as example) may be better.

Also thinking about creating a bit-builder for encoding would be nice.

Hello,
your project looks very fascinating but I guess possible contributors also need to know the license of it. Please decide and publish it as usual. Thanks!

The programming of the user interface is cumbersome. Maybe FRP may help (reactive-banana, dunai, reflex). This has to be analyzed and tried.

Add a display for the content of the data model.

Currently, only a single GRD is displayed in big. A display switcher should be implemented, which is able to display 4 TM displays in parallel, which are switchable:

• One display only
• 2 displays vertically
• 2 displays horizontally
• all 4 displays.

A TM display can be a GRD, AND or SCD (and later synoptic display).

Type classes?

AND are alphanumerical displays. Basically, these are tabulated terminal displays (may be different in FLTK) for displaying incoming TM values.

A generic AND implementation should be done first, then the support for creating them from the MIB should be added.

Add retrieval capabilities

SCD are scrolling displays. These display a limited number of TM parameters in a row with a timestamp. A new row is added, when a new parameter value arrives.

A generic implementation should be done first, then the creation via the definitions in the MIB should be done.

Ol (operations language) is a simple interpreted language, which is used for expressing synthetic parameters. The language should be implemented and parsed into an AST which can be fed to the TM model so that the synthetic parameters can be calculated.

Variable packets which contain a variable length string in a group are not processed correctly.