Leaderboard

I suggest changing your workflow. Do all your work in virtual machines. Each virtual machine is one project. So switching between projects means, switching virtual machines. This is what I've been doing for over 10 years now and I'm a more sane person because of it. I still use VIPM because it's the quickest way to install a bunch of tools for a project. But after my tools and libraries are installed. I'm done. When I worked at JKI (a year and a half ago), I was involved with VIPM product management and development on a daily basis. At the time, I considered many new features. Allowing installation of packages inside custom project directories was on the roadmap. Mainly because, as a product manager. You do product marketing. It's what you do. And the product marketing told me that a growing number of customers wanted this. The trick is. How do you expose these two different workflows in your product? On the one hand, you install in this global location. And on the other, you install under a project folder. How about a combination of both? How is this information presented to the end user and how do you make sense of it all? And this is just the tip of the iceberg. There are several other consequences that ripple out from this, that I won't get into. When VIPM came out over a decade ago, only a few in the minority knew what reuse meant in the context of LabVIEW. Some would argue that people still don't know how to do reuse in LabVIEW. So VIPM not only had to survive as a product but also JKI had to educate the population on how to do reuse. In this context, it was best to keep a single workflow and be consistent: Reuse libraries start off as source code. Which can use any SCC technology. You do a "build" of the reuse library into a package. You install the packaged VIs into LabVIEW You use (link to) the installed VIs in your project source. Which also uses SCC. In order to change the reuse library, you must go back to step 1. Make a change, commit to SCC and then go to step 2, etc. It works. It really does. Whether you like it or not, is a different story. VIPM works the way it does because LabVIEW works the way it does. All of the VI libraries and add-ons that install with LabVIEW are beneath LabVIEW. If you open a VI, it automatically links to stuff beneath LabVIEW. For a newbie, this is great. But for someone who wants strict control of their code, this is a nightmare. VIPM provides a solution within this existing operating framework and does a great job. VIPM promotes and encourages the guidelines set forth by NI. As Rolf mentioned. LabVIEW projects (folder of VIs) now work in the context of LVPROJ and LVLIB files. This has fundamentally changed the world that VIPM works within. Over the years VIPM has adapted to this change. But even with these changes. The fundamental concept of reuse libraries has remained unchanged within LabVIEW. You can't "install" VI-based libraries in different project contexts. So in addition to asking for a VIPM alternative. You should also be asking NI to change how LabVIEW handles reuse code. PS: It's nice to see discussions have finally shifted from. Why should we do reuse? to How can we do reuse better?

I got a question asked today: "So... if you don't invoke the Call Parent Node at least once a week, do they start worrying and invoke the Call Child Node?" :-)

I just wanted to give you all notice that the LAVA website will be going through an upgrade process within the next couple weeks. I don't know for sure when. But if you suddenly see things looking very different, then it's because of this upgrade. Some people will love the changes while others will hate them. The nature of LAVA is not changing. Just the code that LAVA runs on. LAVA will still be free and ad-sponsored and all of that good stuff is staying the same. So if you see problems and things that look out of place. Or if you just want to voice your opinion. Let me know in the comments below.

Fast producer, extremely flexible consumer? Object queue (yeah LVOOP is a good choice here). Allows fully flexible parsing with minimal overhead in the producer (deals with no DD VIs). Receiver doesn't need to know ANYTHING about the formatting. BTW if you're thinking you can't send objecty by RT-FIFO, just send a DVR of the object instead. String formatter.zip

Is some restriction of the format specifier syntax acceptable? Namely, do you need to support $ order? Do you need to output some argument multiple times? If the correspondence parameter -> formatted form is 1:1, a loop on an array of variants containing arguments, plus one array of format strings could perhaps do? Or, one array of clusters (index of parameter, format string) to account for reshuffling and repetition, and then concatenate as suggested above?

Can you just do the formats one at a time and then concatenate?