jeffk

Dragging a vim onto a diagram from windows explorer goes through a different code path which is apparently not working so I would avoid doing that for now. I believe everything works when dropping a vim from a palette or selecting it from the palette "Select a VI..." item. In the latter case you will have to Enable "All Documents" in the dialog box.

Just ran out of time. It's coming in the next release though.

Rules? No rules! The inputs adopt whatever types are wired up to them-- the vim diagram is simply inlined in the caller so type prop works as usual-- whatever gets propagated to the outputs appears on the output wires. If there's a type prop error in the vim diagram (visible using the xnodewizard) the caller vi is broken.

ExternalNodesEnabled=True is needed for LabVIEW 2015 and before, but not for LabVIEW 2016. It looks like StallDataFlow was dropped as a regular subVI rather than as a macro. Perhaps you opened the panel of the .vim and dragged the icon to your diagram? To use a macro you should popup and drop it from the palette or from Select a VI... When you get the dialog you have to enable All Documents in order to be able to select it.

The macros are not part of the Windows LabVIEW 2016 install but they ARE part of the Mac and Linux installs! I will definitely post them here as soon as 2016 is available.

Using something beyond its original purpose can give rise to monstrosity as well as innovation, and being able to tell the difference is very valuable.

Oops. This was added just after beta2 so it looks like it won't be accessible until the release version is ready. Sorry.

Numeric coercion and polymorphism still work as expected. E.g., you can have a subdiagram with an Increment function on it and it will be valid for any numeric, array of numeric, cluster of numeric, etc. That subdiagram will only generate a type prop error if it is connected to a type that is illegal for the Increment function, such as a string or boolean. Using the To Variant (type-only) primitive and the TypeErr pseudo-prim as described above would make it possible to restrict the subdiagram to fewer types. E.g., if you wanted to increment only numerics but not arrays or clusters of numerics you could check for array or cluster and generate a type prop error for that subdiagram, which would then cause the structure to step onto the next subdiagram to see if it successfully type prop'd. In other words, in a macro using the Type Enabled Structure everything is just as polymorphic as always. It is only necessary to use type computation and TypeErr if you want to restrict the polymorphism in some way. I.e., by default there is no explosion; there's only an explosion if you want there to be one, e.g., if you want different behavior for int8, int16, int32, int64, etc.

No good solution in the short term. Longer term I think we need 3 things: the ability to iterate over array dimensionality, the ability to iterate over cluster elements, and the ability to have recursive macros. The first two probably require variations of the for loop while the last probably only needs an enhancement to the xnode that implements macros. Actually, it might be possible to do all 3 by just modifying the xnode. I'll have to think about that some more...

That's the way I've been thinking about it for now. Since the goal is to select the right subdiagram at type prop time it should work fine. The compiler should eliminate the dead code so there would be no performance penalty. For the future I'm considering a more general solution. When you wire something to the To Variant primitive the output is very close to a type type. If the data portion of the variant were eliminated it could work exactly like a type type. It would be a compile time constant so any computations with it could be constant folded away. The only other puzzle piece that would be needed would be a pseudo-primitive (TypeErr) whose only purpose would be to generate a typeprop-time error if its boolean-constant-valued input were true. The technique for making a subdiagram specific to certain types would be to connect the input to the To Variant* producing a type type constant. Check this against the valid types and generate a type prop error if it doesn't match. All the type checking code should get constant folded away so performance would not be affected.

To further pique your interest in macros, there is a new one in LabVIEW 2016 / User Libraries / macros called Norm.vim. It is not meant to be rigorous from a mathematical perspective (it's just my best guess) but rather to illustrate a new (experimental) structure, a variant of the Diagram Disable Structure, called a Type Enabled Structure. It has some interesting properties when used within a macro. Here is how it works. When an instance of the macro is inlined and types are propagated to the inputs, each subdiagram attempts to propagate types; the first subdiagram (in subdiagram order) which successfully propagates types without any errors is enabled and all the others are disabled; the enabled subdiagram is the one which is compiled for this instance of the macro. The new structure is not in any palette yet, nor is there any documentation. It isn't quite ready for prime-time, but you can copy it from Norm.vim and experiment with it and give us feedback.