VI macros?

[bbean]

3 hours ago, ShaunR said:

Well. The fist thing I will do is fire up the VIM Hal Demo. If that works without having to replace all the VIMs and has meaningful event names; I will be a very happy bunny.

Maybe this can help a little until 2016...Re-label Event Wire Xnode

[hooovahh]

19 hours ago, jeffk said:

To further pique your interest in macros, there is a new one in LabVIEW 2016 / User Libraries / macros  called Norm.vim.

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?

[ShaunR]

13 hours ago, bbean said:

Maybe this can help a little until 2016...Re-label Event Wire Xnode

Nice. You are only 1 femtometer away from replacing the VIM and removing the old-school named cluster.

[jeffk]

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.

[ShaunR]

1 hour ago, jeffk said:

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.

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.

[jeffk]

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

[ShaunR]

46 minutes ago, jeffk said:

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

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?

Edited June 7, 2016 by ShaunR

[jeffk]

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.

[jeffk]

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.

[ShaunR]

9 hours ago, jeffk said:

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.

Sweet.

OK. So the default behaviour is no error (accept everything), each case is then tested at design-time in order to make sure it compiles (using normal primitives and preserving coercion and polymorphism) and there is a little bit of manual fnuggery with two new primitives to force a type error so we can implement our own logic. An awesome, outside-of-the-box solution to controlling permissive types.

If we have a "To variant (Type Only)" does that mean we can wire it directly to this new structure and use it like an ENUM wired to a case statement but for different types? (I'm thinking outside of macros and at run-time here  ) 

[lordexod]

Finally, the right man it is in this forum.

So I ask (without the participation of lawyers) , when will the official (unofficial) support to the "XInterface Component" and "DFIRtoCPP".

[hooovahh]

3 hours ago, lordexod said:

So I ask (without the participation of lawyers) , when will the official (unofficial) support to the "XInterface Component" and "DFIRtoCPP".

I'm not NI, and this is slightly off topic, but in the past NI's answer has been that technical limitations came up when with the licensing of XNodes for public use which caused NI to stop looking into making it open.  It sounded like NI (or some within NI) saw that this was a niche group of developers that would want this, and figured it wouldn't hurt to open it up, but ran into issues which were not easily overcome.  With little reason to continue looking into fixing these issues, and with such a small group of developers who would use it, it sounded like NI wanted to invest in other areas instead.  Being part of this small group I certainly am not happy with the decision and hope it changes, but understand why NI hasn't continued to work on opening it up as far as I know.

[jacobson]

From what I remember about VI macros, the output terminals are kind of unique (I think) in that they will coerce to whatever you wire them into. If this is true, what would happen if you wire the output of a VI macro into one of these new structures? Theoretically if you had a chain of these you would start in the beginning and find out the enabled structure that will be used, this would set the output type which would then determine the input type of the next enable structure and so on. Would the compiler be able to figure this out or would it probably fail here?

I'll be the first to say I have no idea when this would be done, just interested to see what our new toys do.

[lordexod]

19 hours ago, hooovahh said:

I'm not NI, and this is slightly off topic, but in the past NI's answer has been that technical limitations came up when with the licensing of XNodes for public use which caused NI to stop looking into making it open.  It sounded like NI (or some within NI) saw that this was a niche group of developers that would want this, and figured it wouldn't hurt to open it up, but ran into issues which were not easily overcome.  With little reason to continue looking into fixing these issues, and with such a small group of developers who would use it, it sounded like NI wanted to invest in other areas instead.  Being part of this small group I certainly am not happy with the decision and hope it changes, but understand why NI hasn't continued to work on opening it up as far as I know.

I know you're not with NI.

I was hoping for the answer of someone with NI, who appeared recently in this topic.

[hooovahh]

10 hours ago, jacobson said:

From what I remember about VI macros, the output terminals are kind of unique (I think) in that they will coerce to whatever you wire them into. If this is true, what would happen if you wire the output of a VI macro into one of these new structures? Theoretically if you had a chain of these you would start in the beginning and find out the enabled structure that will be used, this would set the output type which would then determine the input type of the next enable structure and so on. Would the compiler be able to figure this out or would it probably fail here?

Not quite.  So the VI macro works like the XNode (cause it is) where an input can have the ability to become any data type, then the type propagation within the VI will go through all the primitives inside, or polymorphic types, or whatever just like it does when you change the type on a wire in a normal VI.  The output changes based on the input, in almost all situations, the reverse is not true.  When you wire the output of an XNode the inputs don't change.  The only exception I know of is with a few XNodes like my Variant Repository, which will look up stream when you wire an output, and then attempt to change the output to be the type that it is wired to.  Another exception to this is the variant to data, where in some rare cases it will change the output based on what is wired to it, and the Type input can be left unwired.  I would not expect this new structure to work this way.  I suspect it just looks at the inputs and sees which cases cause no broken wires, then changes the outputs as needed.  BTW can't wait for 2016 now, along with a few other beta features that will finally be given the attention they need.

[ShaunR]

This is what LavaG is here for.

No-one has even seen this new structure yet and we are already trying to figure out how we can abuse it

[JKSH]

2 hours ago, ShaunR said:

This is what LavaG is here for.

No-one has even seen this new structure yet and we are already trying to figure out how we can abuse it

"Abuse" is such a strong term. I prefer "innovative use", or "thinking outside the box" 

[jeffk]

22 minutes ago, JKSH said:

"Abuse" is such a strong term. I prefer "innovative use", or "thinking outside the box" 

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.  

[jacobson]

Dang, couldn't find this structure in the last LabVIEW build and got 0 hits when trying to find more information about it internally. The thought had crossed my mind that JeffK just made this all up for his own entertainment and while I would be a bit sad, I would definitely respect that.

I guess I'll have to wait patiently with everyone else until release.

[Yair]

On 11.6.2016 at 1:38 AM, jacobson said:

The thought had crossed my mind that JeffK just made this all up for his own entertainment and while I would be a bit sad, I would definitely respect that.

Well, trolling ShaunR is certainly a worthy endeavour...

Plus, you never know. jeffk could just be AQ who managed to get IT to give him a new email address so he can register a new NI account.

[Darren]

On 6/10/2016 at 5:38 PM, jacobson said:

Dang, couldn't find this structure in the last LabVIEW build and got 0 hits when trying to find more information about it internally. The thought had crossed my mind that JeffK just made this all up for his own entertainment and while I would be a bit sad, I would definitely respect that.

I guess I'll have to wait patiently with everyone else until release.

Jeff added 6 .vims to [LabVIEW 2016]\user.lib\macros, including the Norm.vim he mentioned.

[ShaunR]

11 minutes ago, Darren said:

Jeff added 6 .vims to [LabVIEW 2016]\user.lib\macros, including the Norm.vim he mentioned.

That's nice (you tease ). But the big question is "do my 'named events' work properly now?"

 

Edited June 13, 2016 by ShaunR

[Darren]

1 minute ago, ShaunR said:

But the big question is "do my named events work properly now?"

I have no idea.

[Aristos Queue]

3 hours ago, ShaunR said:

That's nice (you tease ). But the big question is "do my 'named events' work properly now?"

I don't understand. Why would you expect VIMs to have changed anything with respect to events? This is an edit-time feature, not a run-time feature. Can you explain the link that you're seeing? 

[Darren]

2 minutes ago, Aristos Queue said:

I don't understand. Why would you expect VIMs to have changed anything with respect to events? This is an edit-time feature, not a run-time feature. Can you explain the link that you're seeing? 

I think ShaunR wrote a .vim that provided the ability to name user events, but it didn't work quite right?