Jump to content

Jim Kring

JKI Team
  • Posts

    2,203
  • Joined

  • Last visited

  • Days Won

    106

Posts posted by Jim Kring

  1. Hello Everyone,

    We recently made the VIPM 2021 public beta available. This is important, since the LabVIEW 2021 public beta is now available and the community will need to use VIPM 2021 to install packages into LabVIEW 2021.

    It's important for Dragon Beta users to know that installing VIPM 2021 beta will remove Dragon from the system. The reason for this is that the Dragon Beta is currently bundled with a special build of VIPM 2021 + Dragon.  So, if you have Dragon installed, do not install the VIPM 2021 public beta, if you wish to keep testing Dragon.

    Note, we're working on a separate Dragon installer that's compatible with VIPM 2021 public beta, but it's not ready yet. Thanks for staying tuned.

  2. We're excited to announce the VIPM 2021 beta! You can Download VIPM 2021 Beta Software Here.

    Note: If you are a JKI Dragon Beta Tester, installing VIPM 2021 beta will remove JKI Dragon. Please do not install VIPM 2021 beta on the same machine on which you wish to continue testing JKI Dragon.

    image.png

    What's New:

    • Supports LabVIEW 2021 beta
    • Main UI layout and usability improvements
    • [build 2732] Fix - Installing packages with deep recursion (e.g. A>B>C>A) was getting stuck and hanging VIPM (e.g. SQLite toolkit). This has been fixed.
    • [build 2732] Fix - Detection of project LabVIEW version was not working well if there were no VIs in project. This has been fixed and the LabVIEW version will be read from the .lvproj file.
    • [build 2732] Fix - Missing Friend Classes No Longer Cause Package Build Errors -  The package builder was raising a dependency missing error if a friend class could not be found. However, friends are not actually required. Now they don't cause a missing dependencies error.
    • [build 2732] Fix - Improved "Please Wait" Dialog - Fixed text cut off in the Please Wait Dialog
    • [build 2732] Fix - Community Edition was not setting the "Restart LabVIEW After Install" flag in built packages (and other Pro features that are available to Community Edition such as pre- and post-build custom actions)
    • And more...
    • Like 1
  3. Can you try typing this into a terminal?

    cd ~/Library/PreferencePanes/

    This will navigate you into the PreferencePanes folder

    then type the following:

    ls

    This should list the contents of the folder.

    Do you see something like the following?

    VI Package Manager.prefPane

    If so, then typing the following may fix the issue (as described here) by removing the "quarantine" flag in the OS security settings:

    sudo xattr -d -r -s com.apple.quarantine "~/Library/PreferencePanes/VI Package Manager.prefPane"

     

  4. Hi Glen, Sorry for the frustration. Mac support has been challenging for VIPM, but we try.

    It looks from your post that you tried all the tips mentioned on the knowledge base entry here: File Permission Errors running VIPM on macOS

    The "AppTranslocation" thing in the file path ("/private/var/folders/w7/rtz9k1m114390vq0fxc21bv00000gn/T/AppTranslocation/54274253-33FC-46D0-A566-B7
    F86CC7D1F7/d/VI Package Manager.app/support/callbacks.llb/Refresh Menus 2013.vi") makes me curious if this is some new kind of file system thing that we're not handling.

    I did some googling of "AppTranslocation" and found a couple interesting reads here and here.

    I'm not sure right this second how to fix this, but we'll look into if. If you're able to figure out a solution, please post back here.

  5. 3 minutes ago, Steven Dusing said:

    @Jim Kring For option A, if a package is built with these settings configured at build time, and someone downloads the package but doesn't have Dragon or is perhaps using an older version of VIPM, will VIPM ignore these settings and install as it does in the current released version of VIPM?

    Yes, that would be the idea -- the flag would simply tell VIPM that global installation is required and the package cannot be installed into a virtual environment. So, if the package is not being installed by Dragon into a virtual environment, then it will be effectively ignored.

  6. Hi @Mariano Aristu, @kosist, @Steven Dusing.

    Thanks for the great idea and discussion. You're right that it needs to be easier for end users of packages to install packages and have them end up in the right (global vs local) locations.

    We're considering the options, which include the one's you've mentioned:

    A.) A setting inside the package (Pros: the package builder knows best and has more control, relatively simple to implement; Cons: requires rebuilding and redistributing the package)

    B.) Making VIPM smarter so that it can tell by looking at the package contents and where things are installed (Pros: would "just work" without having to rebuild packages or add more meta info to the repositories, Cons: Requires a lot of dynamic package contents/rules checking to determine where packages can/should be installed) 

    C.) Making the repository aware of the setting for the package, so that packages do not need to be rebuilt (Pros: Doesn't require rebuilding packages, doesn't require smarts in VIPM; Cons: Requires extending the repo format and VIPM to use it, requires someone other than the package developer to define this setting, doesn't work for users who are off-line and don't have access to the repository).

    Based on this, it seems like option (A) adding a flag/setting in the package builder is a good one and also is compatible with (B) adding more smarts to VIPM in the future.

    Another other options or thoughts around this?

    • Like 2
  7. 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

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.