G CLI 3.0 Breaking Changes

[James_McN]

Hi All,

I'm finally getting some time on G CLI again. I know there is at least one crash to fix (https://github.com/JamesMc86/G-CLI/issues/106) which I will patch but then I'm looking to 3.0.

Currently slated for this is to achieve Linux support and STDERR support. There may be groundwork for STDIN but I think that will probably not make the 3.0 release.

To achieve this I'm also rewriting the front end in Rust. A language I'm more comfortable with and with simpler tooling which I hope will make me able to fix issues faster in the future.

The main reason for this post is I've noted a series of breaking changes for 3.0. I wanted to share this and get some feedback from anyone that has questions or concerns.

I've documented them here: https://github.com/JamesMc86/G-CLI/wiki/Version-3.0-Breaking-Changes please take a look and let me have any comments on this thread.

If you think there is something that is a breaking change that needs doing, also let me know now so I can include it in 3.0.

[TiTou]

I use G-CLI for my GitLab CI, it all looks good for me.

Great work by the way!

[joerg.hampel]

Hey James, you mention the timeout in your list of breaking changes:

The --timeout flag is now ambiguous with --kill-timeout. This will be deprecated in favour of a --connect-timeout flag.

What exactly will change (ie which parameter will be deprecated)?

[James_McN]

Hi Joerg,

I plan to add the --connect-timeout as a replacement to the --timeout i.e. they would have the same function.

I think probably initially, we could just have both anyway to keep compatibility. I don't see any issue with this. But I have seem people get confused with which timeout the --timeout flag corresponds too.

[RkTrey]

Hey James--first thanks a ton for the work on this package. It's been incredibly helpful for my team in a number of ways.

Regarding the refactoring of the front end to use Rust, does this mean the C# portions of this tool are going to be deprecated? Can you provide some additional insight here please?

My concern here isn't regarding any breaking changes rather a persistent issue I have in automated builds of some of my applications which regularly fail due to the No Bytes at Port error (I'm the person who posted the ticket on your GitHub). 

[James_McN]

Hi RkTrey,

Thats right. The C# code will be deprecated in favour of Rust. I'm hoping a side effect might be that we get some more useful information in this error case!

In fact I had to just test. The usual case for this error is if LabVIEW closes the connection improperly Normally due to a crash or the program stopping without calling exit.

The error in Rust shows:

ERROR [g_cli] ReadLvMessageError(Error { kind: UnexpectedEof, message: "failed to fill whole buffer" })

Still not a lot more helpful.

[Olivier-JOURDAN]

Hi James, like others, I want to thank you for your work on this tool.

Concerning the changes you plan to make, I can't see significant issues with my regular use of G CLI.

The most "problematic" thing for me is the minimum LV version. At some point, I will need to upgrade the minimum LV version supported by Antidoc and its CLI tool to stay up to date with G CLI 😄