Replace PolyVIs with VIMs

[jimkring]

Possible Approach:

• Create VIMs that live side-by-side with the polyVIs. We could have a subpalette for the VIMs and let users opt-in to them. If they have issues (see below) then they can continue using the PolyVIs.
• At some point in the future, if everything looks OK, we deprecate the PolyVIs.
• At some far off point in the future, when there are no remaining issues, we remove the PolyVIs from the library.

Limitations:

• Cannot build a PPL from a Library that has a VIM that is a public member. This would mean openg_array.lvlib cannot be made into a PPL if the VIM's are public members. An alternative approach is to leave the VIMs outside the library -- not make them members.

Known Bugs with VIMs:

• Bug 2401803 - App Builder errors if you have VIMs in VIMs (see here and here)

• Bug 2296528 (fixed in LabVIEW 2023 Q3 patch 1) - LabVIEW Application Build Fails with Error 1003 while building an application if a PPL contains a class that uses malleable VIs.

[jimkring]

Brian Hoover said that we could pull in any of his Array VIMs into the OpenG package: https://www.vipm.io/package/hooovahh_array_vims/

Some notes from Brian:

I have updated some of the functions to work better than the OpenG, and added a couple optional inputs that also help with performance. Like removing duplicates, in a sorted array, filtering an array if there are no duplicates, and Delete Elements From array, if the indices are sorted. In addition to this I tried making some improvements to performance in the Filter 1D and Search functions. The improvements might not be all that substantial but I did some testing on LAVA. Here are some links:

https://lavag.org/topic/22953-delete-multiple-items-from-array/#comment-146622
https://lavag.org/topic/23038-array-manipulation-performance-testing/

As a result the Filter 1D Array is a bit of a monster with various modes trying to figure out what shortcuts can be taken. VIMs of VIMs, and nesting them too deep causes the application builder to crap out. That's why you may see some VIMs in the Filter 1D Array, just have the code plopped down instead of calling the VIM. I put a couple green labels on the block diagram showing the VIMs that the code correspond to. LabVIEW is broken and I can't get NI to fix it so this was the best I could do so users of my package could make EXEs. You may struggle with this in the OpenG re-write.

As for new Array functions I've made, that aren't OpenG equivalent. Inserting into a sorted array, and searching a sorted array can be useful for performance. And the Foreign Key sort shuffles one array, based on another's results. I tend to use this pretty often, for things like an array of files, and an array of timestamps for the files. You can sort the time stamps, and have it sort the files based on that using one VIM. There are other functions but I tend to not use them much and I'm unsure if others find them valuable. Forcing an array size, checking if arrays match in data or size, 2D to 1D, 1D to 2D, Array to Cluster and Cluster to Array, but I seldom use these.

I didn't get into using Maps or Sets and seeing if they were better but I am way less familiar with trying to squeeze out the performance with those data types than I am arrays. Any time I tried replacing a function using Sets/Maps it ended up being way worst in performance.