Skip navigation

Community

1 2 3 4 5 Previous Next 8584 Views 70 Replies Latest reply: May 2, 2012 10:59 AM by Kosta RSS Go to original post
  • David Staab Calculating status...
    Currently Being Moderated
    31. Apr 17, 2012 2:16 PM (in response to Daklu)
    Re: Avoiding 'vip hell' with VIPM packages

    Daklu, I don't use LapDog, but I do have internal reusable components that depend on VIPs that are about to be deprecated. I just previewed the next version of one of them (published by a group at NI, no less), and it doesn't properly namespace its typedefs across versions or provide mutation code. That means that installing the new package and opening up my component that depends on it resulted in all kinds of cross-linking issues and "missing VI" errors. So I absolutely see this as a real problem that needs a recommended solution.

     

    Additionally, after spending an hour to review the changes made in this new dependency, I realized that I have no incentive to upgrade my dependent component because the changes (1) don't add any of the features I had to implement myself and (2) don't improve any of the quirks I had to work around in the older version. So now I have the conundrum of either (A) remaining dependent on the older package and suffering version conflicts when I put my component into any project that uses the newer one, or (B) spending a lot of nights and weekends to refactor my component and test it with the new dependency. Designing for SxS installation would fix my problems without doubt.

     

    I don't mean to help start a political movement with this, but I do commiserate on the importance of the issue and the concern that nobody may care.

  • Currently Being Moderated
    32. Apr 17, 2012 2:20 PM (in response to Daklu)
    Re: Avoiding 'vip hell' with VIPM packages

    Daklu wrote:

     

    So other than David Staab, David L, and myself (also David--it's a conspiracy!) I haven't seen comments from others on this thread recognizing the potential for problems when package developers do not allow sxs installations.  That concerns me a bit.  Maybe I haven't communicated the problem well enough, maybe I'm missing out on an existing solution everyone else is aware of, or maybe nobody cares how I go about enabling sxs installation for LapDog.  I can't tell...

    As I previously indicated, yes, I have the same concerns as you, and no, my name isn't David.

  • crossrulz Calculating status...
    Currently Being Moderated
    33. Apr 17, 2012 2:21 PM (in response to Daklu)
    Re: Avoiding 'vip hell' with VIPM packages

    Daklu wrote:

     

    So other than David Staab, David L, and myself (also David--it's a conspiracy!)...

    I'd like to just chime in to say that this is a concern.  And just to add to the conspiracy, my brother's name is David (does that count?).  I've been developing my own reuse library and I would like to design it with these issues in mind.  I don't really have a solution since I have yet to run into the problem myself.  But at least you opened my eyes to the future issues I will likely run into.

  • Currently Being Moderated
    34. Apr 17, 2012 2:24 PM (in response to Daklu)
    Re: Avoiding 'vip hell' with VIPM packages

    Thanks for the clarification David. That is very helpful. By the way, did you find any information on the toolkit version mutation api AQ suggested?

    

    I briefly looked into the Mutation API.  It has some promise, but it will require some work to clean it up and make it safe for public consumption (similar to how we got scripting many years back and more recently Project Providers).  It's on our team's radar to continue investigation, but I can't promise any timeline.

  • Currently Being Moderated
    35. Apr 17, 2012 2:46 PM (in response to Daklu)
    Re: Avoiding 'vip hell' with VIPM packages

    Daklu,

     

    My name is not David and I appreciate the value of SxS installations in LabVIEW.  I think you have communicated both the problems and the solution well.

     

    I am encouraged with the course of the conversation, which started with what looked to me like preciously little support for SxS, and progressed to discussion about best practices.  We have a lot of collective experience with "backward-compatible" upgrades of LabVIEW IP, and significantly less experience with SxS, which makes this discussion hard.

     

    I am not aware of anything that prevents SxS installation in LabVIEW.  I would expect VIPM to work well if the different versions for SxS installation are entirely separate in every way (in which case both LabVIEW and VIPM will be left unaware of the relationship between packages previously described as belonging to a package line).

     

    I am interested in exploring is SxS installations where a package is formally never revised.  For example, let's say that we have IP product called Foo 1.0.  If we elect to create a bug fix for Foo 1.0, it may be called Foo 1.1, so that Foo 1.0 and Foo 1.1 can coexist in SxS manner.  As a user of Foo 1.0, I may like it better than the "improved" Foo 1.1 because I invested time into verifying that Foo 1.0 works within my stack, and I may not be able to verify that Foo 1.1 works as well.  People make mistakes, so practical problem is that Foo 1.1 may have new bugs, and I may like old bugs from Foo 1.0 better. 

     

    If the only difference between Foo 1.0 and Foo 1.1 is a behavioral change without any parameter changes to the VIs, and I like behavioral change, upgrade to the new version is conceptually simple-I would have to replace all elements from Foo 1.0 with corresponding elements from Foo 1.1.  I acknowledge that the time it takes to perform this conceptually simple change may depend on the number of places that reference VIs, typedefs, and other elements from Foo 1.0, but I see that as a separate problem.

     

    What do you think about this:  SxS where we never revisit a version once it is shipped?

  • David Staab Calculating status...
    Currently Being Moderated
    38. Apr 18, 2012 9:34 AM (in response to Daklu)
    Re: Avoiding 'vip hell' with VIPM packages

    Good point, but:

    1. The typedefs from the dependency trickle up to my componenet's interfaces, and some of those typedefs changed while keeping their names.
    2. Lugging around a duplicate of the dependency inside my component bloats code. It's not often a big deal when working with LV's tiny (on disk) binary format, but it's the principle of the thing!

     

    Really, as you said, #1 is what's really going to prevent that from working.

  • Currently Being Moderated
    39. Apr 18, 2012 7:41 PM (in response to David Staab)
    Re: Avoiding 'vip hell' with VIPM packages

    DavidStaab wrote:

     

    1. ...
    2. Lugging around a duplicate of the dependency inside my component bloats code. It's not often a big deal when working with LV's tiny (on disk) binary format, but it's the principle of the thing!

    Unless you want to work with mutation histories, I can't see any other way (unless, of course, you don't want to support SxS )

  • David Staab Calculating status...
    Currently Being Moderated
    40. Apr 18, 2012 7:48 PM (in response to crelf)
    Re: Avoiding 'vip hell' with VIPM packages

    I know, I know.

  • Currently Being Moderated
    41. Apr 19, 2012 8:35 AM (in response to Daklu)
    Re: Avoiding 'vip hell' with VIPM packages

    "Save as" approach works when you have the rights to save another package under a different name and re-distribute the IP from the other package indirectly.  In other words, "Save as" approach may be limited by licensing.

  • Currently Being Moderated
    42. Apr 19, 2012 9:43 AM (in response to Daklu)
    Re: Avoiding 'vip hell' with VIPM packages

    Daklu wrote:


    As a practical matter, I'm concerned the lack of existing LV infrastructure support will result in a very negative experience for the end user if we pursue that option too soon. As you pointed out, switching versions takes a lot of effort, and I'm guessing most users would be fine with automatically upgrading all their Foo 1.0 code to Foo 1.1.

    

    SxS is relatively novel in our context, but it seems to offer promise to solve problems associated with automatic upgrades.  The level of effort switching takes depends on the circumstances, including the manner and extent to which the APIs are used, and availability of any scripting tools to help with the explicit upgrade (and possibly downgrade).  Your guess that most users would be fine with automatic upgrading is supported by prior art. I am interested in how SxS would best address the rest of the users, and whether it can be made to work well for all the users.

     

     

    Daklu wrote:


    They will not be happy if they have to search and replace to receive every simple bug fix. I've thought about creating scripts to automatically search and replace user code when the APIs are compatible, but that is still a cumbersome solution. Someone upgrading from Foo 1.0.3 to Foo 1.0.19 will have to install all 16 intermediate versions and run their upgrade scripts in order.

     

    (Edit: Hmm... maybe it would be possible to write mutation scripts recursively so the search and replace parameters are mutated through all 16 versions but the actual search and replace operation is only done once. That would eliminate having to install all the intermediate packages as long as the mutation code contained the entire history.)

     

    If the interfaces are consistent in all Foo's between 1.0.0 and 1.0.19, I expect that you could write a single script for all upgrade and downgrade scenarios that does not require presence of any intermediate versions.

     

    I am curious about number 19 from the example.  How often do you envision producing bug fix versions?

    Daklu wrote:

     

    The trick is making the upgrade (and downgrade) code replacement automatic for most people, but optional in those cases where a specific user application shouldn't automatically upgrade to the new package version. [...] (And as Jim alluded to early in the thread, it's very easy to change relink an application to a different version of the dependent assembly.)

     

    How would we define "user"?  I am asking because some users may enjoy knowing about dependencies, but others will rely on a high-level library specifically so that they don't have to deal with lower-level details.  The main benefit for all users from the high-level library existing with tightly specified versions of low-level libraries would be quality.  I am assuming here that the high-level library gets tested thoroughly along the low-level libraries it depends on.

     

    I have worked in an environment where it was easy to relink to a different version of a dependent library (with all assumptions listed in Daklu's earlier post), but it was not automatic, meaning that the programmer had to opt in for changes to take place.  I appreciated control I had over timing of opting in.

    Daklu wrote:

     

     

    There's nothing (that I'm aware of) even remotely similar to the GAC currently in Labview, and I expect implementing similar functionality in LV dev environment would be quite time consuming. On the positive side, this is primarily a dev environment issue rather than a run time issue, so maybe that would simplify things somewhat.

      [...]

    All that being said, you mentioned you see changing package versions "as a separate problem." Do you have something else in mind for simplifying the process of changing which package version a project uses?

     

    I don't know enough about GAC to comment on whether I'd like to see it emulated in LabVIEW.  The time for writing scripting tools for changing called versions should diminish with experience.

     

    I agree that this is mostly a dev environment issue, but that it may also be a run time issue.  When I was describing "a separate problem", I was referring indeed for something easier on the user than brute force search-and-replace.

  • Currently Being Moderated
    44. Apr 19, 2012 7:22 PM (in response to Daklu)
    Re: Avoiding 'vip hell' with VIPM packages

    "This can be done right now with VIPM by changing the package name every time, but nobody does it because it is very cumbersome for the package users."

     

    Why is this cumbersome?

More Like This

  • Retrieving data ...

Bookmarked By (2)