Jim Kring

Thanks for clarifying all the different things you’ve tried. I’m sorry that the instructions aren’t working correctly for Arabic. I don’t have any experience getting this tool working for Arabic, so I haven’t run up against this problem. I’ll ask some of my colleagues if they know anything about it

I haven't tried, but I would assume that it already is compatible with Arabic. There's a documentation guide here to help you out: https://github.com/JKISoftware/JKI-Simple-Localization/wiki Please let us know how this works for you.

Great idea, Joerg. This is not currently a feature, but it's worth considering, for sure. Your use case sounds valid.

Thanks for the clarification on your use case -- it's very helpful (and exciting) to see the code in action that does the automated builds of your VI Packages! We've done some work on a fix for this issue (we're calling it a "bug") and I'll ping you off-line so you can test it out, if you'd like.

Hi Joerg, Great idea. A couple comments/questions: I see that the VI Package Builder GUI defaults to 1 for the major version, yet it allows changing it to 0. It also allows you to build and install such a package (with 0 as the major version), just fine. More so, I see there are several packages in the wild (on vipm.io) that use 0 as the major version number, too. So, it would seem reasonable to allow the VIPM API to support this, too, and it wouldn't introduce any new problems. Which VIPM API VIs are you calling and how you're using it? I'm assuming you probably have an existin

Hi Alex, This may not be trivial, although it's probably technically possible. I'll ping you off-line. -Jim

Ah, OK. Thanks @Sam Grayson. It's helpful to know that the issue may have something to do with .NET.

Hi @Mathilde (CC: @Francois Normandin) Thanks for your interest in code coverage with Caraya. There's not currently a built-in feature for doing code coverage in CaraYA. Do you have thoughts on how you would want to calculate coverage? I've implemented some simple coverage tools in projects by using naming conventions for my tests and enforcing that each public member of a library has a test associated with it.

That's strange. I wonder if there's some kind of permission issue. Does "Everyone" have Full Control on the "C:\ProgramData\JKI\VIPM" folder?

Hi Peter, Can you try exiting VIPM, deleting the cache folder, and then restarting? C:\ProgramData\JKI\VIPM\cache

Hmmm... which "list" are you referring to? The main VIPM package list or the Dragon project's Resources tree/list of packages? Also, can you look in the "C:\ProgramData\JKI\VIPM\error" folder to see if there's any error messages logged?

Hi @Yann. Thank you for sharing how IT resolved the issue for you. That's really helpful to know.

Hi @Sam Grayson and @Yann -- I'm also curious to learn more about how to configure Cybereason so that VIPM will work OK for you. Please let me know if your IT departments are willing to share more information.

Hi @Mario. Great question. As @James@Work point to, VI Package Configurations are a great solution for keeping track of the packages in your project. Additionally, JKI has announced the beta for Dragon, which sits above LabVIEW and VIPM to provide high-level management of LabVIEW projects and configurations of packages used by your project.

Fantastic! Glad to hear you're up and running.

I've seen that before -- sometimes VIPM's local package database doesn't get fully sync'ed Please try this: Open the VIPM Main window by clicking on the orange "VI" Then, refresh the package list in VIPM by clicking the refresh button on the toolbar You should then be able to find OpenG Toolkit by clicking on the link again or searching for it in the VIPM Main window.

That’s a great idea to show the build output, Joerg. I assume by “feed back the progress” you mean that you would like to see some progress text output to the standard output, which the CI is showing in the console?

Totally. I've opened a service request with NI to dig into it some more. I'll post updates, once I find out more.

I was able to reproduce the issue with the help of a colleague who has an RT Target. I've written up some info about this issue here: https://lavag.org/topic/21753-1d-array-to-string-not-compiling-correctly/ OpenG String v4.1.1.16 should fix this issue (although it's simply working around the LabVIEW compilation bug, which could potentially be causing other issues) I'm going to work to report this to NI, since we can reproduce the issue.

Ah, that's interesting. Maybe it's related.

Also, are you able to reproduce this issue right now? I might have a fix/test for you. If you've fixed it locally, maybe you can reproduce by uninstalling OpenG String from 2019 and then re-install OpenG. Being able to reproduce would really help me test a fix.

Oh, that's very interesting! Thanks. Question: is there any possibility that you opened this code on a Mac? (where the EOL character is a "\n" -- note that the EOL character is "\r\n" on Windows).

Hi Antoine, Thanks for posting this. Question: Do you have LabVIEW 2020 SP1 (2020.0.1) installed or LabVIEW 2020 (2020.0.0)? I'm trying to figure out how to reproduce this bug. -Jim

There are the ones that come to mind: C:\Program Files (x86)\JKI C:\ProgramData\JKI C:\Program Files (x86)\National Instruments C:\Program Files\National Instruments

@Mads Toppe, Thanks again. We've created an official knowledge-base entry for this issue: Knowledge Base: VI Package Manager Runtime Engine - Installation Media Required for Repair