Finish, Installation and Getting started

[TheColonel2688]

I am a C# Dev (with sprinkling of other languages) I also mainly develop IEC code now.

I have wanted to learn rust and I find this project very exciting and interesting. However i don't fine anything in place to help any noobs get started and use this.

Can the Installation section be finished and a Getting Started tutorial be added?

https://github.com/PLC-lang/rusty/blob/master/book/src/build_and_install.md

[riederm]

Hi @TheColonel2688,

thx for your interest into the project. The easiest way for you to start would be to use the Devcontainer feature from VS-Code. If you work under windows, you would need to install WSL and Docker for Desktop which is pretty easy.

From here on everything should work out of the box, the first download of the DevContainer takes some minutes but you get a small, virtualized linux container to compile and debug.

For a native windows installation we need to see, because I believe almost everybody in the Team does either use Linux or a Devcontainer.

see https://code.visualstudio.com/docs/devcontainers/containers

[ghaith]

You can also run natively on Windows using a custom llvm version https://github.com/PLC-lang/llvm-package-windows It needs to be in your path for llvm config to find it.

[volsa]

Just so we can fill the gaps in the documentation, what is actually missing besides the installation section? Because imo https://plc-lang.github.io/rusty/build_and_install.html already describes how to get a working development environment (albeit not going in-depth with Windows / Docker) and https://plc-lang.github.io/rusty/using_rusty.html can be seen as the "Getting Started" tutorial. Is it the Windows section in particular?

[TheColonel2688]

I hadn't seen https://plc-lang.github.io/rusty/ documentation IDK how I missed it.

But yeah, basically a step-by-step depth guide for Windows, Docker, and VS Code or at least a short paragraph with links to 3rd Part How-Tos on using Docker and Dev Containers

I have used docker before, but I have never messed with VS Code DevContainers andI haven't done any CLI builds since college. I use my Visual Studio as a crutch.

Also is there any debugging supported yet that is integrated into VS Code or some other editor? I assume not?

A Road Map on the main Readme.md would be nice, explaining

• what the current state of the project is
• what you are hoping to do for the next release
• what is not there that people might expect
  • debugging integration (Breakpoints, Variable Values etc)
  • a Hardware IO System (Standardized API for IO drivers and mapping, etc)
  • HMI (User Interface) Designer (I know that is long way and it probably a separate project)
• what the short-term goal of the project is (meaning: use cases)
• the long-term goal of the project (meaning: use cases)

[TheColonel2688]

Thoughts?

[ghaith]

Hello @TheColonel2688 I'm sorry for the late reply. See my answers below

But yeah, basically a step-by-step depth guide for Windows, Docker, and VS Code or at least a short paragraph with links to 3rd Part How-Tos on using Docker and Dev Containers

Agree, we have some part of it explained in the book, and we assumed with dev containers that the user would refer to VS code or Dev container info but a extended guide on our side makes sense.

Also is there any debugging supported yet that is integrated into VS Code or some other editor? I assume not?

You can compile any application for debug with -g and run it with the LLDCode in VS Code. You need to enable breakpoints for all files in the preferences It also makes sense to use -Onone for the optimization flags otherwise LLVM removes a lot of code for you.

A Road Map on the main Readme.md would be nice, explaining Agree, we need to update the readme. I'll answer the questions however here as well

* what the current state of the project is

Project is being made ready for production, it can be used with a Runtime or standalone. We are testing it internally with a custom written runtime.

* what you are hoping to do for the next release

CFC/FBD Support, better error handling, Object Oriented, Direct hardware / memory access support.

* what is not there that people might expect

• We are not fully codesys compatible, a project that compiles for Twincat is not necessarily correct in RuSTy, especially when it comes to pointers and other datatypes. We are for now 64bit only.
• There is no runtime, it has be added separately.
• Task configuration and the Resource section of the norm is left for the runtime, we don't compile Tasks in, so a task will not be able to have complex logic like the IEC Standard expects.
• There's no hardware support the way IEC61131-3 defines it
• OOP is still not complete.
• Only ST actually works

• • debugging integration (Breakpoints, Variable Values etc) This is mostly done. The Debugger however thinks we are C

  • a Hardware IO System (Standardized API for IO drivers and mapping, etc) Planned, not yet there. It is however redundant. The symbols can be exported as dwarf or as json to be accessed by a runtime.

  • HMI (User Interface) Designer (I know that is long way and it probably a separate project) Seperate project yes :) the scope of this projcet is to be a Compiler.

  • what the short-term goal of the project is (meaning: use cases) Production quality ST compiler
  • the long-term goal of the project (meaning: use cases) Production quality ready IEC61131-3 compiler :)

[TheColonel2688]

@ghaith, Thank you so much for your detailed response!!

Agree, we have some part of it explained in the book, and we assumed with dev containers that the user would refer to VS code or Dev container info but a extended guide on our side makes sense.

It doesn't need to be extensive, just a little more details.

You can compile any application for debug with -g and run it with the LLDCode in VS Code. You need to enable breakpoints for all files in the preferences image It also makes sense to use -Onone for the optimization flags otherwise LLVM removes a lot of code for you.

this is good to know!!!

Project is being made ready for production, it can be used with a Runtime or standalone. We are testing it internally with a custom written runtime.

• We are not fully codesys compatible, a project that compiles for Twincat is not necessarily correct in RuSTy, especially when it comes to pointers and other datatypes. We are for now 64bit only.
• There is no runtime, it has be added separately.
• Task configuration and the Resource section of the norm is left for the runtime, we don't compile Tasks in, so a task will not be able to have complex logic like the IEC Standard expects.
• There's no hardware support the way IEC61131-3 defines it
• OOP is still not complete.
• Only ST actually works

• 64 bit only is very fair.
• as far as pointers go in my opinion they should be relegated to libraries only. References and Interfaces should be the only thing that is in the process/operation code of any project/application. but in codesys references and interfaces do have some limitations that make them clunky.

This is mostly done. The Debugger however thinks we are C

What are the draw backs of the debugger thinking the code is C?

Planned, not yet there. It is however redundant. The symbols can be exported as dwarf or as json to be accessed by a runtime.

ok that is good news, that they can be exported as dwarf or json.

• There is no runtime, it has be added separately.
• Task configuration and the Resource section of the norm is left for the runtime, we don't compile Tasks in, so a task will not be able to have complex logic like the IEC Standard expects.

  a Hardware IO System (Standardized API for IO drivers and mapping, etc)

Planned, not yet there. It is however redundant. The symbols can be exported as dwarf or as json to be accessed by a runtime.

HMI (User Interface) Designer (I know that is long way and it probably a separate project)

Seperate project yes :) the scope of this projcet is to be a Compiler.

what the short-term goal of the project is (meaning: use cases)

Production quality ST compiler

the long-term goal of the project (meaning: use cases)

Production quality ready IEC61131-3 compiler :)

If the goal is to only be a compiler. Then what is the point of the project? What do you guys get out of it? Do plan on adding a runtime project later? Or are you hoping that someone else will pick that up? In other words, how do you guys intend to use RuSTy or is this all just for fun?

Do you guys have a copy of the IEC61131-3 3rd Edition? (Do you want one?)

[ghaith]

This is mostly done. The Debugger however thinks we are C

What are the draw backs of the debugger thinking the code is C?

The UI for most debuggers will assume we are debugging a C program, so watch expressions or conditional breakpoints have to be written in C. If we also end up having differences in the struct layout it will show up. Not a big deal IMHO but it would be nice to eventually have better support for this.

Production quality ready IEC61131-3 compiler :)

If the goal is to only be a compiler. Then what is the point of the project? What do you guys get out of it? Do plan on adding a runtime project later? Or are you hoping that someone else will pick that up? In other words, how do you guys intend to use RuSTy or is this all just for fun?

The project started as a hobby project between coworkers to better understand compilers, but it has been picked up by our company Bachmann electronic

Do you guys have a copy of the IEC61131-3 3rd Edition? (Do you want one?)

We have the norm for reference in our company. We occasionally make references to it in issues but AFAIK we cannot share any of its content/details directly in here.

[TheColonel2688]

Thank you for the explanations and the link to the blog post.