Jim Kring

Sure thing, and thank you for reporting it.

Here's a pre-release of a build you can test. vipm-20.3.2540-windows-setup.exe PS - this link may stop working after a day or two, as we're working on the official release.

Hmmm, OK. Thanks for that info and the kind words. It’s helpful. Fix coming soon.

Oh, I think I know what it is. The service that auto-starts VIPM looks for the transition from NO LabVIEW versions running to ANY LabVIEW version running. Here's what I think happened: LV2019 started, which auto-started VIPM. VIPM was closed and LV2019 was left running. Then, LV2020 was opened (while LV2019 was still running) VIPM did not auto-start because the transition from NO LabVIEW running to ANY LabVIEW running did not occur. Anyhow, it's not super important, since we'll fix this, but I hope it's helpful to make sense of what was happening.

Yes, that *is* odd. Question: Are LV2019 and LV2020 32-bit or 64-bit?

Great. Yes, that should work too. I think you discovered a bug. When the System Tray is disabled, VIPM should not start up automatically when LabVIEW starts, even if Start VIPM when LabVIEW starts? is set to TRUE. We'll fix that in the next release. Glad you figured out a good solution.

After you Disable System Tray in the VIPM Options, please reboot your computer and see if that fixes it.

This sure is an odd issue, @nriver. Thanks for posting a link to the fix.

Hi there. We've got a new build for Mac available here: vipm.io/desktop Please try it out and see if it helps with this issue.

Hi there. Glad you got it working. I'm not familiar with the PATCH method. Also, the source is available on GitHub if you want to try supporting this. https://github.com/JKISoftware/JKI-HTTP-REST-Client Let me know if you have questions.

Hey Greg. There's a new build (2020.3.2540) released. You should be able to get it via Help >> Check for VIPM Updates or the Updates Available button on the toolbar after a restart. Or, you can go to vipm.io/desktop

Hi there. A couple things: 1) There is a way to disable this in the settings file. 2) We just released 2020.3 (SP3) that disables the system tray by default, which will also prevent automatic start when LabVIEW starts. My suggestion would be to go with #2 so you're running the latest and greatest version of VIPM, since it has some other improvements, too. Please let us know how that works for you. -Jim

OK, thanks for posting all this. I don't really know how to interpret that, either. Since this is a new release, maybe we just need to wait and earn the trust of our AI overlords.

Fantastic! Thanks for letting us know. We'll be rolling this out into an official release, very soon. Thanks again for your patience and help debugging/testing.

Hi @Mosin Thanks for letting us know. To my knowledge, you're the first report of this. I see that Paloalto Cortex uses AI to determine the likelyhood of a threat. So, it could simply be that nobody has trained it on VIPM 2020.3 yet 🙂 That said, I'd like to learn more. Can you post more details, like a screenshot or copy+paste of the report?

Hey Greg, I've got a new build for you to test. vipm-20.3.2537-mac.zip (this link may stop working in a day or two, as we're working on an official release) This should fixe both issues: read-only files inside the package packages containing files with brackets "[ ]" in their filenames Please try it out and let me know how it works for you. -Jim

Hi there, @Firefly. Thanks for reporting this. I've filed an issue, fixed it, and released a new package v1.0.2. It should be visible for download in VIPM (you may need to refresh your package list / check network for package updates). Please let me know if this works for you. -Jim

You're very welcome, Greg. So, it turns out the NI Current Value Table package has not one (1) but two (2) interesting things inside it that cased the command-line zip approach to choke (and I'm working on fixes): Issue 1) The license file is marked inside the package as READ-ONLY. This happened when the package was build, because the file was READ-ONLY in the developer's source folder. Issue 2) The package has files with brackets "[" and "]" in the filenames and the command line shell was not handling them unless they were escaped as "\[" and "\]". I've filed a couple bugs and am working on a fix. Hopefully, we'll get a build of VIPM for Mac that can handle this package. -- Love VIPM? Don't forget to consider VIPM Pro licenses for you and your colleagues while the 2020 Cyber Monday sale is going on

Oh, that's great news that you were able to get a bit further. Also, I'm (thankfully) able to reproduce the issue with the NI Current Value Table Package (it get's stuck, as shown below, just as you described). I'll dive deeper into this and see if we can find out what's going on. Thanks again for helping test this out and for your patience.

Also, I've been working to share (as an open source project on github) the command-line zip/unzip tools (for Mac and Linux) used by VIPM. The project is here: https://github.com/JKISoftware/labview-command-line-zip-tools Would you be able to download these and try them out? I went through the effort to create a high-level test VI that exercises all the core functionality. As I was making this, I did try running it on Big Sur and got an Error 10 when trying to Create Dir if Exinsistant. I replaced this with a call to the LabVIEW built-in utility Create Directory Recursive and it resolved the error. I've already made that fix and pushed it to the github repo. Note: It seems this issue has to do with macOS tightening the permissions in the temp folder to prevent listing the contents of directories inside the temp folder. This probably aims to make it so that only the creator of files/folder can work with them.

Hi Greg, Would you be willing to run a test on your computer? Please run this VI (Read License Agreement Text.vi): Read License Agreement Text.vi It uses this one support VI Mac Unzip Single File from Archive.vi You can try it out on this package file: jki_lib_rest_client-1.3.3.25.vip Thanks, -Jim

OK, thanks for clarifying that. Do you have the LabVIEW 2019 SP1 runtime engine installed? [Update: I see you said you have LV19.0.1f0 installed, so I guess you do have 2019 SP1 runtime engine installed]

Thanks, Greg. It appears that there's a lot going on -- the first issue seems to be that the native LabVIEW HTTP Client is having trouble dynamically loading a DLL (and it's probably a LabVIEW runtime related thing). It also seems to be some file permissions issues writing to temp files. I'll mention that our focus with VIPM 2020.3 has been getting things working well in 64-bit macOS like Mojave and Big Sur. What did you upgrade from 2020.1, 2017.0, other? (BTW, you can download older VIPM versions here)

Hi There. Thanks for trying this out on Catalina. Can you look in the errors folder to see if there is an error log file? If so, please post it here and I'll take a look. Macintosh HD >> Library >> Application Support >> JKI >> VIPM >> error Thanks, -Jim

Hi @Waleed El-Badry LabVIEW and VIPM on Linux is always a bit tricky to get working. BTW, VIPM 2017 for linux uses the LabVIEW 2017 runtime engine. You can find the VIPM versions for linux here. We're don't have a VIPM 2020 build for Linux yet, but we're working on it. -Jim