Aristos Queue Posted June 20, 2012 Report Share Posted June 20, 2012 For the last two years, I have been sharing with the community ongoing updates to the Actor Framework using VI packages. In LV 2012, the AF version 4.0 is going to be a standard part of LabVIEW's vi.lib. However, G libraries can rev faster than LabVIEW itself, and shortly after LV 2012 releases, we're going to have a new version of the AF available. The previous versions of AF install into user.lib. The official version will install in vi.lib. Where should the new version install? After a lot of advice from various sources, I have decided that the right thing to do is to install version 4.1 into user.lib, leaving vi.lib unchanged. This gives users who are wanting to use the new versions the ability to do so without messing up their core libraries, in case they receive a VI from someone else that uses the previous version. Even though VIs written for 4.0 are compatible with 4.1, this keeps things cleaner. Version 4.1 also wants to install an example VI to show off one new feature of the updated version. I have told VIPM to put these files into "OS User Home" in "Actor Framework\examples". And now, here's where the fun starts: 1. VI Package Manager is creating a single .vip file for me, but when I open that file, there are two items listed: "Actor Framework v4.1" and a dependency "Actor Framework (System) v4.1". What this means is that if I install, both parts install, but when I click Uninstall, only the core files uninstall, not the example files. Is there any way to tell VIPM to just make this a single part? 2a. There are files in user.lib that will have the exact same name, including namespacing, as files in vi.lib. When VIPM installs the examples directory and runs mass compile on it, the files are not found at the paths saved inside the VIs, so Mass Compile searches for the missing files... and the first directory it searches is vi.lib. And it finds the files. And that means they are now cross-linked. 2b. Similar to #2a, the VI search path doesn't include user.lib at all, so any of the dependencies that are in user.lib are simply not found, which means the user is prompted to find them manually when they open the example. --- Is there any way to get VIPM to set the paths correctly back when the package is being built so that Mass Compile doesn't have to search and already has the right paths saved? Everything is being installed in the correct locations, but not built in the right locations. 3. Is there any way to add a .ctl file to the Function palettes other than creating a merge VI whose only purpose is to wrap the constant? It seems silly to have a wrapper VI just for that purpose, and it means I have to copy the text of the control's Description into the Merge VI so that it shows up in Context Help when viewing the palettes. 4. I would like to create three forks of version 4.1. One will have stabilized features that we expect to someday add to LabVIEW itself. One will be the same as the stabilized version but will add code to the diagrams to support a debugging framework for actors, code that we would not want to include in the release framework but might want to temporarily install and then back out again. The third will be a truly experimental version for "what would you think if we added something like this?" features. There may be, in the future, many variations of that third branch for "AF with networking" or "AF with serialization" or "AF with money laundering", etc. I would like to use the "Incompatible Packages" feature of VIPM to help users keep from accidentally stacking these up, since they all install different versions of the same files, but they are not ordered versions. Let's call these "variations" instead of "versions". Since I do not know how many of these variation packages might exist, I can't declare them all up front and then make them all mutually exclusive in the VIPM. There doesn't seem to be a way to declare an exclusion against a family of packages, so here's the idea I came up with: --- Create a package named AFBlocker. --- Make all the variations of AF incompatible with AFBlocker so that they won't install if AFBlocker is already present. --- Make all the variations of AF install AFBlocker so that after they install, no other AF can install. Will that work? Has anyone else tried something like it? 5. Is there a more preferred location for example files than "OS User Home" ? I'd really like to put them in the "LabVIEW Data" directory, but I've got no idea how to reliably tell VIPM "use the LabVIEW Data Directory function". Link to comment Share on other sites More sharing options...
David_L Posted June 20, 2012 Report Share Posted June 20, 2012 1. The System package contains any files that install outside of the LabVIEW folder. I don't think there is a way to combine them, short of not installing any files outside of the LabVIEW directory (See bullet number 5 below) 2a. Since I assume that your VIs and such are in libraries, can you change the name of the library to something like "Actor Framework (web).lvlib"? This would avoid namespace conflicts, however might cause upgrade problems for people going from 4.0 to 4.1. 2b. Not sure about this offhand so I defer to others. 3. Not that I know of, but you can't really do this in the LabVIEW Menu editor either. 4. I think the problem with this approach will be that AFBlocker will install with each flavor of Actor Framework, but won't automatically uninstall when you remove the current flavor of AF. So the common use-case might be 1) Install AF-A, AF Blocker gets installed. 1) Unisntall AF-A, AFBlocker remains. 3) Install AF-B and get an error saying it's not compatible. 4) Be confused. Also, if AF-A and AFBlocker are installed and the user gets a message that AF-B is not compatible with AFBlocker, they may just uninstall AFBlocker ad leave AF-A causing cross-link problems. However, is it a good assumption that anyone installing any of the flavors of AF will be fairly competent LabVIEW developers? If so you might just have a disclaimer on each document saying that these are not compatible with each other and having them installed side-by-side will cause problems. This might be good enough for the general use-case. 5. We tell all toolkits that install to the LabVIEW Tools Network to install their examples into a directory in LabVIEW\Examples. You can also add a create a bin3 file in LabVIEW\Examples\exbin so that theyshow up in the example finder. Doing this may also resolve problem #1. Link to comment Share on other sites More sharing options...
Aristos Queue Posted June 20, 2012 Author Report Share Posted June 20, 2012 5. We tell all toolkits that install to the LabVIEW Tools Network to install their examples into a directory in LabVIEW\Examples. You can also add a create a bin3 file in LabVIEW\Examples\exbin so that theyshow up in the example finder. Doing this may also resolve problem #1. THIS SOLVED #1, 2a, 2b, and 5!!!! So, as long as I install into "<labview>\examples", then the VIP creates a single package for install and uninstall, and the paths are set up correctly so that mass compile finds the right version without any conflicts! Woohoo! Link to comment Share on other sites More sharing options...
Aristos Queue Posted June 20, 2012 Author Report Share Posted June 20, 2012 3. Not that I know of, but you can't really do this in the LabVIEW Menu editor either. Yes, you can do it in the LabVIEW Menu editor. Selecting the .ctl file to add to the Function palettes puts the ctl item in and when you drop it on the diagram, it drops as a constant. Link to comment Share on other sites More sharing options...
David_L Posted June 20, 2012 Report Share Posted June 20, 2012 THIS SOLVED #1, 2a, 2b, and 5!!!! So, as long as I install into "<labview>\examples", then the VIP creates a single package for install and uninstall, and the paths are set up correctly so that mass compile finds the right version without any conflicts! Woohoo! Glad to be of service Yes, you can do it in the LabVIEW Menu editor. Selecting the .ctl file to add to the Function palettes puts the ctl item in and when you drop it on the diagram, it drops as a constant. I see. I thought you meant you wanted a control terminal to be placed. Looks like VIPM just yells at you if you try to select a ctl. Looks like an Idea Exchange request to me... --David Link to comment Share on other sites More sharing options...
Aristos Queue Posted June 21, 2012 Author Report Share Posted June 21, 2012 I see. I thought you meant you wanted a control terminal to be placed. Looks like VIPM just yells at you if you try to select a ctl. Looks like an Idea Exchange request to me... Done. http://ideas.jki.net/topic/115121-allow-users-to-add-ctl-vis-to-the-palettes/ Now, I still need a solution to the mutual exclusion problem. Link to comment Share on other sites More sharing options...
Aristos Queue Posted June 21, 2012 Author Report Share Posted June 21, 2012 So, I tried implementing my mutual exclusion idea. I created a mutex package. I updated the AF package to use that one as a dependency. And then I tried to install the AF package. And you know what? Even though I did not have the needed dependency, VIPM installed the AF anyway! ARGH. I was really expecting it to say, "You cannot install this unless/until you find that missing dependency." Since that's not the behavior, I'm back to square one on this variations problem. Link to comment Share on other sites More sharing options...
Aristos Queue Posted June 21, 2012 Author Report Share Posted June 21, 2012 OK. New idea. I'm going to use the Pre-Install VI to check for the existence of the Actor Framework files and, if they already exist, return an error, which stops the install before it even happens! Link to comment Share on other sites More sharing options...
David_L Posted June 21, 2012 Report Share Posted June 21, 2012 OK. New idea. I'm going to use the Pre-Install VI to check for the existence of the Actor Framework files and, if they already exist, return an error, which stops the install before it even happens! Ya, that is probably a good path to go down. I do something somewhat similar with an obsoleted package (Third Party Licensing & Activation Toolkit Run Time) on the Tools Network. If someone tries installing the newest version from scratch or upgrading to it from an earlier version, it throws an error with instructions on how to get the proper new installer. Good luck, Link to comment Share on other sites More sharing options...
Michael Aivaliotis Posted June 25, 2012 Report Share Posted June 25, 2012 I assume you found the incompatible packages feature? This should do what you want. Link to comment Share on other sites More sharing options...
Aristos Queue Posted June 26, 2012 Author Report Share Posted June 26, 2012 I assume you found the incompatible packages feature? This should do what you want. I discuss the "incompatible packages" earlier. It doesn't suffice for the problem. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.