What about a "community patch" to LabVIEW?

[Aristos Queue]

Has anyone ever given any thought to the LAVA community creating one single patch for the LabVIEW development environment? In other words, LabVIEW ships from National Instruments and then after installing LabVIEW, a user would then install the Community Patch. What would/could the patch do?

1. Install any number of useful tools in one go: right click framework, quick drop short cuts

2. Add useful OpenG tools

3. Update the configuration file to set settings different from the defaults that LV offers

4. Change the default custom probes

5. Fix bugs that the community has prioritized

There are fewer developers here at National Instruments than exist in the wider LV community, and so it is not surprising that there are many great tools developed by members of the community that significantly improve the LabVIEW user experience. Identifying all the tools that I'd like to pull down and install -- or that I would recommend another user pull down and install -- is hard. Some of them are available as packages, but many others are just one-off VIs posted to a forum, like an improved custom probe. I might read the post one day, think, "Great! Let me grab that." So I copy it into my current version of LV. But I don't remember to copy it into LV on my other computers, and when it comes time to upgrade, I may not remember to copy that VI into the upgrade.

Ideally such things would be flowing back to National Instruments and we in LV R&D would be over time adding them to LabVIEW's own installer. But there are often licensing problems with us picking up VIs from forums, and even when there aren't, the other priorities required to get a release ready often trump pulling such tidbits in. That got me thinking...

Imagine if one of the significant LV users who has a high trust/recognition among the community were to say, "I have created one VI package that installs everything free that I consider valuable to upgrade my LabVIEW experience." That makes it easy for a user to just install one thing and get a set of reviewed improvements all at once. I suspect a lot of tools that otherwise languish in the hands of a few expert users would suddenly have a much wider adoption, and a lot of forgotten niceties would enjoy a renewal. Plus it would give LV R&D one package to review each release, instead of relying on someone happening to have tripped over an interesting post in the forums, which might help get these tools into LabVIEW's own installer.

I have no idea if this has been thought about before, no idea how workable this would be, but it doesn't necessarily have to be all that organized. A lone developer deciding to maintain such a package and add to it whenever he/she saw something interesting on the forums would be valuable. An ad hoc group might form around him/her to advise on "posts that should go into <Your Name Here>'s LV Patch".

Thoughts?

[ShaunR]

In principle it's a good idea. However......

1. All "patches" that I want can only be supplied by NI and, after one year, I have to lump it (I still use 2009 through choice).

2. Isn't most of what you are proposing exactly what the JKI thingy is for? (and I still argue that NI should have their own)

3. One mans meat is another mans poison so what some might see as "valuable" another almost certainly will not (all the items you list in No.1 for me).

4. If I see "useful stuff" it goes on my "G:\" drive which has 3 directories (2009, 2010 and 2011). Each is an exact duplicate of arbitrary "useful stuff" downloaded from forums, bits and pieces I've written and other miscellaneous bits and bobs (2009 is the "source" and gets copied accross to the others now and again). Each installed version on the dev machine(s) has it's search path pointing to the appropriate verson on the G:\ drive (the 2009 dir is backed up in SVN). Very little gets installed in the palletes above and beyond the vanilla install except my own re-use code (there are only 2 of them) and others on an as needed basis for that project (which are uninstalled after completion). This is the way I avoid dependancy and "compiled for later version" hell.

I should perhaps also add that most of my work is on machines that are intentionally not internet enabled so "whoops I forgot to download and install that package" is not a viable proposition (sometimes machines are in different buildings or even in different parts of the country). The 2009 directory copied to a usb stick solves all that.

Edited April 5, 2012 by ShaunR

[jgcode]

Has anyone ever given any thought to the LAVA community creating one single patch for the LabVIEW development environment? In other words, LabVIEW ships from National Instruments and then after installing LabVIEW, a user would then install the Community Patch... ...Imagine if one of the significant LV users who has a high trust/recognition among the community were to say, "I have created one VI package that installs everything free that I consider valuable to upgrade my LabVIEW experience." That makes it easy for a user to just install one thing and get a set of reviewed improvements all at once.

Whist this is a great idea in practice, I don't see it working as explained.

As ShaunR pointed out, every developer's workflow is different - and what code/tools they prefer/require will vary.

Additionally having a large monolithic installation (one single package) does compromise the advantages of modular releases (see elsewhere for discussion)

I do however, believe that packages (and the both the LVTN and VIPN) solve the proposed task due to their flexibility

Some of them are available as packages, but many others are just one-off VIs posted to a forum, like an improved custom probe.

Of course, it becomes an issue when code is not released as a package (for whatever reasons). This is something I have been trying to work on with the Team LAVA initiative. Firstly, only packages are used as the deliverable. Now instead of focusing on select packages (as proposed, although it makes sense that popular LAVA packages definitely get published), it focuses on quality (and hopefully quantity in the future), which is accomplished through the LAVA-CR and the Compatible with LabVIEW (CwLV) process. All the while it promotes the LAVA community.The more packages the better. Once the code is available on the LVTN (or VIPN in OpenG's case) you can download it and manage it - easily from any PC (with internet connection and VIPM installed) without the need to search the forums etc. Just search VIPM.

Now, if someone wanted to post their recommended community code/tools, it would be as easy as uploading e.g. a .VIPC file (VIPC's are potentially under review to make them better for this task - see here) which references the LVTN/VIPN packages (or could even include other packages). A user code simply download the VIPC file and patch their LabVIEW installation - IMHO this accomplishes the proposed task. Over time, a user could easily upgrade a package due to the modular installation (something that would be more complex to maintain if it was all just a single release).

A few packages have already gone through this process for Team LAVA and I actively encourage any community members who are interested to participate in releasing their code through LAVA onto the LVTN - or if they have any ideas to make this process better - please post!

[vugie]

1. Install any number of useful tools in one go: right click framework, quick drop short cuts

2. Add useful OpenG tools

3. Update the configuration file to set settings different from the defaults that LV offers

4. Change the default custom probes

5. Fix bugs that the community has prioritized

+ customized splashscreen

(I still use 2009 through choice).

How good I'm not alone...

2. Isn't most of what you are proposing exactly what the JKI thingy is for? (and I still argue that NI should have their own)

Maybe JKI should think of something like meta-package? As collection (but not physical) of packages to be installed together. A set of customized collections for different needs (possibly with auto choosing newer versions of updated packages) would be much easier to create and maintain than "one big patch".

[Phillip Brooks]

I would limit the definition of a patch to be changes to NI provided code.

Examples would be a fix of Riffle, updating NI VIs that contain oldvers and compat type sub-vis that NI tells us we should stop using (but they don't ) and fixing the fact that Telnet Buffered Read is not reentrant and causes numerous problems when used with TestStand.

Maybe a template copy of a LabVIEW.ini file with cool features from the wiki disabled and with comments( super-secret baby!)

(We might be able to help more if a few less VIs were password protected )

Edited April 6, 2012 by Phillip Brooks

[Phillip Brooks]

Imagine if one of the significant LV users who has a high trust/recognition among the community were to say, "I have created one VI package that installs everything free that I consider valuable to upgrade my LabVIEW experience."

...

A lone developer deciding to maintain such a package and add to it whenever he/she saw something interesting on the forums would be valuable. An ad hoc group might form around him/her to advise on "posts that should go into <Your Name Here>'s LV Patch".

Are you volunteering?

Aristos Queue's LV Patch has a nice ring to it.

Or maybe The Captain's LV Patch would be better

[Aristos Queue]

Or maybe The Captain's LV Patch would be better

Nah... that one just helps you stop smoking. :-)

[hooovahh]

(We might be able to help more if a few less VIs were password protected )

I think if there was an unofficial patch put out, it would need alot of customization, on allowing the user to select things that it modifies. Because some people may want their VI.lib replaced, and some may not even want the Riffle function replaced.

EDIT: Nevermind read his post wrong.

[Roderic]

I think VIPM provides this additional patch. What we need would be a wider variety of packages available!

[dannyt]

I think the solution to this already exist as several people said in the form of the VIPM when it is used along side VIPC files.

You could have on LAVA and NI community sites people's top VIPC files as voted for by you the public, this would give new users a number of examples of the types of configurations used by experienced user.

The two problems with this solution are, one that not all good extras and add-ons come in the package format, however the use of packages is growing ever stronger. The second problem is that the VI configuration files are only supported in the Professional version of the VIPM and that in itself will stop then becoming a mass market way of sharing.

I really like the VIPM but like ShaunR I still find it amazing that NI never came up with something like this as part of the professional version of LabVIEW

[Onno]

The LabVIEW community has a large number of incredibly useful tools (RCF, QuickDrop extensions, OpenG), but they're rather spread-out, difficult to find for newcomers, and not always very well mainainted. Over the past year or so, I've slowly accumulated a collection of these tools, but it'd be really difficult to explain to a new colleague where I found them all

As such, some sort of "official community patch" sounds appealing: it'd make it way easier for relatively new developers to "upgrade their LabVIEW experience" (hm, that sounds cheesy). And I guess those people would be the main audience for such a patch? (Since most of the people in this topic already have their own sophisticated customizations, presumably).

I do wonder about the technical difficulties, though, given the already mentioned "different workflows for different developers", and the non-trivialities of maintaining a modularized LabVIEW installation.

VIPM may be a perfect implementation of a "community patch" — but that would also mean that more of the already available tools and libraries would need to be packaged. With important parts of VIPM's functionality being reserved for commercial users (esp. the creation of VIPCs), this might be an obstacle.

Nevertheless, I would be interested in seeing how this develops! (If I could help, I would!)

[Olivier Jourdan]

I still find it amazing that NI never came up with something like this as part of the professional version of LabVIEW

I think that VIPM and LabVIEW Tools Network is the solution that NI provide in order to "upgrade LabVIEW experience". It gives access to tools (free or not) with a minimum of "quality" checking.

It's certainly have to be improved but I think that it's done continuously since it was released in LV2010.

[Antoine Chalons]

The LabVIEW community has a large number of incredibly useful tools (RCF, QuickDrop extensions, OpenG), but they're rather spread-out, difficult to find for newcomers, and not always very well mainainted. Over the past year or so, I've slowly accumulated a collection of these tools, but it'd be really difficult to explain to a new colleague where I found them all

I totally agree with that!

The issue is that some of these very useful tools are not available as VIP.

What I do to be able to have all my LV tool on any computer I use is have a VIPC for everything that is available as a VIP and have a installer (that I built from a lvproj) that installs all the tools that are not VIPs.

It would be cool to repackage all the tool as VIP but I'm not too sure about licence issues that it would cause.

[Ton Plomp]

As soon as I read the initial post I was thinking about TotalCommander that has several quite popular patches (TC PowerPack is my favorite), that includes a lot of customization that allows you to integrate the most idiotic features (virtual HDs, torrent downloaders, diff tools, EXIF readers etc.).

Porting this idea to LabVIEW I can think of codesets (OpenG, MGI) additional IDE enhancements (G#, JKI Right Click Framework, or a toolbar framework).

Additionally NI has added things that could have been in a community patch (the Project environment for instance).

What would we want in such a toolset?

Ton

[crelf]

Hmmm, this thread has me thinking, not of a community patch, but of a "crelf patch", or a "VIE TSIG patch" that I can take with me to new versions of LabVIEW. Right now, I have VIPCs that link to packages for our reuse libraries, as well as the latest OpenG "patch", but I've never really organized myself to go much further than that when a new machine comes online. VIPM's behaviour is highly configurable, and is becomming moreso, this might just be a good idea, even if only a local one.

PS: I'd love to see an "AQ patch" - I can only imagine the goodies that would be in there!

[Phillip Brooks]

A great candidate for a <vi.lib> patch distribution from the LabVIEW Minutiae thread on the dark side:

http://forums.ni.com/t5/BreakPoint/LabVIEW-Minutiae-that-may-bite-you-someday/m-p/1973519#M19044