search

JamesMc86 / G-CLI

A proxy mechanism allow LabVIEW programs to easily write out to the command line.
BSD 2-Clause "Simplified" License
71 stars 19 forks source link

Running built executable can't connect in start CLI #144

Closed negentropicdev closed 1 year ago

negentropicdev commented 1 year ago

It looks like when g-cli launches a .exe it's hardcoded to listen on port 5000 however the Start CLI in LabVIEW is still using the labview global labview.ini or service locator to link up with the g-cli

JamesMc86 commented 1 year ago

I'll take a look - that shouldn't be the case.

The only difference with an exe is that we can trust the CLI args in LabVIEW so it should bypass the service locator - not to say I haven't mucked something up!

JamesMc86 commented 1 year ago

Yep I screwed up:

https://github.com/JamesMc86/G-CLI/blob/7fa4e0cf5e3ea0e52c492deada31fdbb15c88209/rust-proxy/src/comms.rs#L54

Probably an artifact from early testing I missed. I'll look to patch this to autodetect a free port.

It should still work with a single exe but will fail with multiple as in #143

JamesMc86 commented 1 year ago

Oh but let me know if you think there is something else going on as well. A single EXE should work without issue and that is tested as part of the release process.

JamesMc86 commented 1 year ago

Just pushed a fix for this which will be in v3.0.1. I'll probably try to get that out this week with just that fix but going to review if there is anything else.

JamesMc86 commented 1 year ago

Just pushed v3.0.1 to VIPM which should fix this. You can get it now on the release pages if you cant wait!

negentropicdev commented 1 year ago

Thanks! We'll give it a shot. I suspect there may still be an issue because the LabVIEW side was still trying to use service locator and failing since there wasn't a service registered, since we weren't launching a VI directly.

negentropicdev commented 1 year ago

Tha LabVIEW side deciding on whether to use service locator or passed parameter is gated on LabVIEW's INI check for AllowMultipleInstances

JamesMc86 commented 1 year ago

This is a code clarity issue. It considers an exe a multi-instance version and that is handled in that VI with a conditional disable structure

This could be named or structured more clearly.

negentropicdev commented 1 year ago

Okay cool I'll take a look again I definitely missed that, shame on me!

negentropicdev commented 1 year ago

Yep, amazing how blind I can be to a blatant CDS structure :-D

Thanks again for the fix! My coworker was super impressed with the turnaround ;)