Continuous Integration

Showing results for 
Search instead for 
Did you mean: 

G CLI 3.0 Breaking Changes

Hi All,


I'm finally getting some time on G CLI again. I know there is at least one crash to fix ( 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: 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.

James Mc
CLA and cRIO Fanatic
My writings on LabVIEW Development are at
Message 1 of 7

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

Great work by the way!

We have two ears and one mouth so that we can listen twice as much as we speak.


Antoine Chalons

0 Kudos
Message 2 of 7

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)?

DSH Pragmatic Software Development Workshops (Fab, Steve, Brian and me)
Release Automation Tools for LabVIEW (CI/CD integration with LabVIEW)
DQMH® (The Future of Team-Based LabVIEW Development)

0 Kudos
Message 3 of 7

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.

James Mc
CLA and cRIO Fanatic
My writings on LabVIEW Development are at
Message 4 of 7

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). 

0 Kudos
Message 5 of 7

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.

James Mc
CLA and cRIO Fanatic
My writings on LabVIEW Development are at
0 Kudos
Message 6 of 7

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 😄

Olivier Jourdan

Wovalab founder | DQMH Consortium board member | LinkedIn |

Stop writing your LabVIEW code documentation, use Antidoc
0 Kudos
Message 7 of 7