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.

On August 10, 2016 at 4:57 PM, Aristos Queue said:

I assume Jeff K just forgot to create it.

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.

On June 7, 2016 at 8:26 AM, hooovahh said:

I went looking into the 2016 beta I had and I couldn't find this.  Is this a thing that isn't in the beta but is intended to be in the 2016 release?

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

On June 7, 2016 at 2:29 PM, ShaunR said:

Sweet.

Similarly. Many of the primitives have default transformations for type, an example being numerics where we can wire in a double and output an Int (coercion) and this is also apparent on controls and indicators. A case-like feature that detects it's terminals has the potential to "explode" that convenience into umpteen subdiagrams where the type must be explicitly defined. Do you have any thoughts how to keep the generic convenience?

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.

32 minutes ago, ShaunR said:

What is your solution here to the "polymorphic problem" - where we have to define a subVI (or in this case a subdiagram) for every LabVIEW type.

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...

18 hours ago, hooovahh said:

Yeah I like that.  It could fix several things I've been thinking about, like what if you want to adapt an input to a 1D of any kind of data, but it must be a 1D array?  Then you could have a case where you wire your input into a Search 1D array, which would break if a 1D wasn't wired.  Not sure how this would work for performance performing a task with a primitive, whos output isn't used.  The compiler might optimize away code and do strange things.  Want to ensure only a cluster is wired?  Wire that input to an unbundle function.  Want a 2D of something?  Wire to a transpose.  Still there are times when I want more complicated checks, like the input is a cluster, and one of elements is a numeric, and has a label of XYZ, but I guess that's when XNodes could come in.

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.