tools for scripting generic code

[Bob321]

Hey All,

I feel like at some point in their time programming, everyone is likely to come upon something like this:

and all they really want, deep down, is to change their function to do this:

but without a coersion dot. There may be ways of implementing this I'm not familiar with, but to the best of my knowledge we have a few options:

• LabVIEW objects--which only really let us modify one of the inputs
• Variant/String casting--slow and inefficient, and we have to figure out the type at runtime anyway
• Creating an X-node, something that the Lava forums seem to suggest is not recommended because of (a)time investment and (b) stability
• Polymorphs for every combination of inputs--this is a pain to do, but is stable, fast, and meets the need.

So, I thought of two ways to get rid of the downside to polymorphs (well one way, implemented twice). That downside is that its a real pain to make a copy of your code for each combination, and its even worse to maintain this code. I decided to try scripting. As with so many scripting-related things, this code is totally not to be trusted. In fact, you might even say it was incomplete. But, since it was a nice little side project to play with while binging watching netflix, I thought I would share.

Version 1:

The first mechanism I thought of was defining a set of "template types" and changing these all up front. That is, if I wanted to switch my code over from using all doubles to all U64, I would specify the double type as my "template" and then do a replace on all instances of that template. This could also be expanded to N types, but I didn't do that here because, well, its a side project. To use this version of the code, you would start from a library like genericizer/GenericFunction_lib, which contains a polymorph, a template function, and a template control.

For this basic example, I'm really just wrapping an add. But, you can see from the above image that the template function doesn't even have to work to run the code. You just have to wire everything up. Then, to script out the copies you run genericizer/GenerateGeneric.vi

you can see from the above that I've elected to script three functions--one with dbls, one with sgls, one with u64s. There is also a configuration for booleans, but this will in fact fail, and so the script will not save that as a new function (it reports error 1). If you run the code exactly as-is, with the two paths filled in, you'll get three new polymorphs, those polymorphs will be loaded into your library, and they will be added to the actual poly VI. If you chain sets of these polymorphs together, you can actually make a pretty dynamic set of code just with one call to the scripting function.

Version 2:

The second thing I came up with was genericize.vi, a quick drop shortcut (defaults to ctrl+L when you copy it to the quick drop directory). The idea here is that you start with some set of code you want to copy, like in the first image (here I am using the function I scripted with version 1 of the code):

Now lets say I change my mind, as above, and want to use something crazy like an unsigned integer:

What the quick drop shortcut does is analyzes the selected region for any polymorphic VIs. Then it locates any terminals which have either broken wires OR coersion dots. It then traces up (or down) the wires to locate the correct type and copies that into a new copy of the polymorph (it actually makes a .ctl in the temporary directory, something I didn't think of for version 1 but which greatly simplifies the process). For simplicity (again, side project) it comes up with a random name to use. It is also not recursive right now (that is, it doesn't look on the block diagram of the selected polymorph for any further polymorphs, something which would probably make writing code like this infinitely more useful). Anyway---when I actually run this, I go from:

to this

With the press of "Ctrl+L". At this point you may notice how useless this the example is. We've just moved the coersion dot inwards. But, in real examples this can definitely come in handy.

My hope is that someone else out there finds this handy, but either way it was a fun little project.