Priorities

[NOP0]

I'm currently working on the #19, #22, #29 PR's. Where to next? I guess there's some options

1. Contributing more to the parsing, like #19, #22
2. Contributing "well known" standard functions to the standard library.
3. "Fixing" the dummy-input crate. Dummy-input is not the best name, and it should maybe be some generic stuff over possible input types? Ideally there could be like signal generators here that you could parametrize, like generating a sine wave or a bool pulse train. Maybe there could be some "devices" that take a closure, so you can supply the signal generator. In that way you can use the same signal generators in the user program also?
4. Updating gpio crate according to the new ProcessImage, making a minimal example for RPi?

... and probably a lot of other stuff. It's no lack of tasks. 😄 Are there any of these tasks that should be prioritized? Are there other tasks?

I try to have at least of couple of different topics going at the same time for variety. But like for all of us, however much I enjoy it, I have a "set" amount of time each week for this kind of stuff. 🙂

Thoughts?

[Michael-F-Bryan]

My first priority is to finish #27 and I should be ready to merge some time tonight. From there some future tasks are:

• Start writing a compiler to turn parsed structured text into a blob of executable WASM. I'm guessing the easiest way to do that is with cranelift, but it's a big library and I've never really used it before
• Implement parsers for the other IEC languages (will probably require reading the XML format spec and deserializing it properly)
• Write some sort of rustmatic_core::Process which can poll a rustmatic_wasm::Program so we can run a WASM program on the runtime. This will probably require an adapter which takes rustmatic_wasm::Environment calls and passes them through to the rustmatic_core::System
  • We may also want to refactor things so rustmatic_wasm types directly work with/implement traits from rustmatic_core
• Figure out how users will interact with the runtime (GUI program, exposing a programmatic HTTP API, REPL, etc.)

---

I think our overall goal should be to get a really simple example up and running as fast as possible, allowing us to put off things which won't directly get us closer to that goal.

It's really satisfying when you have a working thing in front of you and can interact with it, whereas adding extra library functions or API flexibility just doesn't have the same appeal.

In my mind, the simplest useful example would be a program written in structured text which is executed by the runtime and toggles the state of an output (e.g. the 0'th bit of output address 0) at a frequency dictated by an input (e.g. the byte at input address 5).

EDIT: as part of #27 I made an ugly blinky.rs program we can build on.

[NOP0]

I think our overall goal should be to get a really simple example up and running as fast as possible, allowing us to put off things which won't directly get us closer to that goal.

100% ACK.

I guess some obvious things I can contribute towards this might be:

• I need to get up to speed on #27.
• Then I think there's some parts missing in the grammar for the MVP IEC program per your description. I'll open a new issue on this. I guess we have the Rust version of this in your blinky.rs
• I'm happy to work on anything, of course heavy stuff might need mentoring :slightly_smiling_face:

[NOP0]

Figure out how users will interact with the runtime (GUI program, exposing a programmatic HTTP API, REPL, etc.)

I don't know if we could use something like vscode webview to i.e. display Ladder Logic? https://code.visualstudio.com/api/extension-guides/webview