Jump to content

Steven Dusing

Members
  • Posts

    6
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Steven Dusing

  1. I would like to see VIPM be smart enough to know to put project providers, quick drops, etc into the global environment for us so that we don't need to rebuild existing packages (or hope that others update their packages).  VIPM should know from the build spec where it's going to put file.  If VIPM can simply differentiate between locations that only work well in the global environment vs custom or standard locations for source code (vi.lib, user.lib, etc), that would take the burden off of everyone to make the decision, as it would be handled automatically.

    • Like 2
  2. Apologies if this is the wrong place for this post, but I'm quite puzzled by something I'm seeing.  I expected a test that I just ran to potentially reveal a limitation of installing packages in the global AND virtual environments, but it is in fact working as I would like, and I would love to understand why this is possible... so if anyone will humor me, here goes:

    Here's my situation:

    1. I use the PaneRelief toolkit, so I have that installed in my LV2020 environment (globally).
    2. PaneRelief depends on a number of other packages, like Panel Manager, so I also have to install those into the LV2020 environment.
    3. I added a breakpoint to the Panel Manager code in the global environment (you'll see why)
    4. I want to use Panel Manager in my project too, so I added the package to the my virtual environment.
    5. I wrote a vi that uses the Panel Manager vi's from my virtual environment, so I know these vi's were pulled into memory.  I confirmed by checking my lvproj's dependencies
    6. While this vi is open, I use the quickdrop shortcut to launch PaneRelief.. I expected it to load its Panel Manager dependencies from the virtual environment since those were already in memory.
    7. However, and much to my delight, it did in fact hit the breakpoint, indicating that PaneRelief loaded its Panel Manager dependencies from LV2020 vi.lib.

    I guess I'm curious why this did not cause a conflict or load from the incorrect location - I'm normally used to seeing LabVIEW always defer to a vi in memory with the correct name rather than load from file, but that doesn't appear to be what I'm seeing.

    Thank you!
    Steven

    • Like 1
  3. Firstly, Kudos to the JKI team.  Dragon looks awesome, delivers on the promises, and truly is a work of art.  I've enjoyed using it so far and really look forward to this going live.

    One small feature request I've come across - I'd like the ability to multi-select items in the Resources view.  I'm converting a few packages and needed to uninstall a bunch of packages from the global location, but Dragon only lets me select one at a time.  My work-around was uninstalling through VIPM, so not a big deal, however it would be nice if Dragon supported that natively.  Same request would go for "Add Package to VIPC."

    image.png.2ffe4f0caa2fe2703d63f4c0f58ed43d.png

    • Like 2
    • Upvote 1
  4. Every time you build a VI Package, you are prompted to specify release notes.  These are not very usable at the moment though.  To read these, you need to right click on the package, select "Get Info" and then read the specific version's release notes. If you're catching up on a new version of package that's more than a couple versions newer than what you've been using, it can take a long time to understand what the impacts to that package are.  I would like to propose VIPM have an option to view aggregated release notes. This would be exposed in a right click option on a given package, and aggregate all individual release notes for all versions of the package that are in the library.

    The goal would be to have an easy way to see something like the following:

    My Package

    • v2.0.0.1 - New Release with some groundbreaking features
    • v1.2.0.1 - Minor update made to feature Z
    • v1.1.1.1 - Patch for bug X
    • v1.1.0.0 - Minor update to add feature Y
    • v1.0.0.0 - First release of my cool tool


    image.png.b32b1259b88c687819a41de5f598418e.png

    image.png.8e093844ef9ca1f3440cadc41972a8c8.png

  5. Currently you have two options for Package Dependency version constraints: >= or ==
    I propose VIPM should use or allow Semantic versioning.  That way, if a dependency package has a breaking change, the dependent package can know that it is not compatible with the updated version.  This is a big missing piece to VIPM's dependency management, since it currently assumes that a package will forever be able to support future versions of all dependencies, which simply is not the case in real life, as breaking changes do happen from time to time.  Allowing for semantic versioning will help identify and prevent breaking code.
    image.png.3abc8a5e7c24ecd3ea350c8adeb654af.png

    image.png

    • Upvote 2
×
×
  • Create New...

Important Information

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