Jump to content
drjdpowell

Malleable Buffer (seeing what VIMs can do)

Recommended Posts

On 11/15/2019 at 2:03 AM, ShaunR said:

Never mind. It seems that you cannot have DVRs inside VIMs any more.

Seems VIMs can no longer be used in polymorphic VIs either.

1 hour ago, drjdpowell said:

Maybe we need a "placeholder" type, or "Your Type Here". 

I don't think this is a good idea. The VIMs I've played around with (before the type case structure was introduced) relied on at least one terminal having a type which would dictate the undefined types due to the nature of the internal polymorphic VIs (like a Queue or DVR). This is why I was trying to get a VIM to create a DVR which "should" define the type across all connected VIs which would solve this problem. In a nutshell, I'm expecting this set of VIMs (rightly or wrongly) to behave like the Queue, Notifier et. al. primitives when the Enqueue and Dequeue element terminal is unwired.

Edited by ShaunR

Share this post


Link to post
Share on other sites
5 minutes ago, ShaunR said:

In a nutshell, the VIMs "should" behave like the Queue, Notifier et. al. primitives when the Enqueue nad Dequeue terminal is unwired.

Yes, that is the problem.  If I connect a "Buffer" of a certain data type, the "Data" input should adapt to be that datatype.  That's how Queues work, but there isn't a way I can identify to make VIMs work that way.  Outputs adapt to inputs, but not unconnected inputs.  

Share this post


Link to post
Share on other sites
37 minutes ago, drjdpowell said:

Yes, that is the problem.  If I connect a "Buffer" of a certain data type, the "Data" input should adapt to be that datatype.  That's how Queues work, but there isn't a way I can identify to make VIMs work that way.  Outputs adapt to inputs, but not unconnected inputs.  

I think we've articulated the goal well enough. However, a VIM doesn't necessarily have a reference like Queues et. al. so I'm not sure there would be an "uncomplicated" first order solution for it even though it's a kind of natural progression from singular VIMs to libraries of VIMs. In theory, the second order solution is to use those primitives internally since they have that behaviour which should propegate out but I was unable to see if that worked with DVRs and trying queues didn't illicit the behaviour.

Edited by ShaunR

Share this post


Link to post
Share on other sites
On 11/16/2019 at 8:15 PM, Aristos Queue said:

I have no idea why that limitation exists. I’ll ask on Monday. 

Those two primitives were explicitly tagged to be blocked... none of the people involved are still at NI. The comment says, essentially, “These boded crash sometimes when inlined,” with no useful detail, no steps to reproduce. I’ll look into it some more, but I have no clue what the issues could be. 

Share this post


Link to post
Share on other sites
1 hour ago, ShaunR said:

Seems VIMs can no longer be used in polymorphic VIs either.

Malleable VIs never could go in a poly VI. It's been that way since they were introduced in LV 2017. That's by design: they conflict with the rules of polyVIs for deciding which instance to use. Poly VIs need a fixed list of connector panes.

Share this post


Link to post
Share on other sites
16 minutes ago, Aristos Queue said:

Malleable VIs never could go in a poly VI. It's been that way since they were introduced in LV 2017. That's by design: they conflict with the rules of polyVIs for deciding which instance to use. Poly VIs need a fixed list of connector panes.

Yeah. but it worked n 2009 ;)

Edited by ShaunR

Share this post


Link to post
Share on other sites
On 11/18/2019 at 12:02 PM, ShaunR said:

Yeah. but it worked n 2009 ;)

Malleable VIs didn't exist in 2009. They were new in 2017.

Share this post


Link to post
Share on other sites

@ShaunR: Were you referring to VI Macros when you mentioned LV 2009?

On 10/28/2019 at 6:31 PM, Aristos Queue said:

Malleable VIs, not VI macros. VI macros is a never-released, LV2016-and-earlier prototype feature.

Share this post


Link to post
Share on other sites
12 hours ago, ShaunR said:

Yes. It's a distinction without a difference GregSands found it, the community investigated it and malleable VIs were the productionisation of it.

Major differences: One was an off-the-cuff prototype that frequently crashed, couldn't nest properly, had no well-defined recompile semantics (so you couldn't trust that if you made a change the callers saw it), and didn't integrate with any of the rest of LabVIEW features except by accident (and, in the case of polyVIs, that  accidental interaction was a bug). The other is an actual feature. I don't think we retained any of the original code. Comparing them, especially in the context of complaining about loss of functionality, spreads disinformation to anyone who doesn't know the background history.

If you meant it as a joke, you forgot your </joke> tags. I did not find your semantic antics amusing.

Share this post


Link to post
Share on other sites
2 hours ago, Aristos Queue said:

Major differences: One was an off-the-cuff prototype that frequently crashed, couldn't nest properly, had no well-defined recompile semantics (so you couldn't trust that if you made a change the callers saw it), and didn't integrate with any of the rest of LabVIEW features except by accident (and, in the case of polyVIs, that  accidental interaction was a bug). The other is an actual feature. I don't think we retained any of the original code. Comparing them, especially in the context of complaining about loss of functionality, spreads disinformation to anyone who doesn't know the background history.

If you meant it as a joke, you forgot your </joke> tags. I did not find your semantic antics amusing.

Just because you refactor something doesn't make it a "new feature". And just because something is buggy, doesn't mean the the bug-fixed feature is different. The history is laid out in the thread I linked including discussion about the ""Type Enabled Structure" (which, although buggy;  appeared in LV 2016, IIRC) and some thoughts on addressing our requests for usage by JeffK (including polymorphic VIs). Even the file extension has remained the same (shouldn't it now be MVI?). I would accept it as being a "newly supported feature" from 2017 onwards, though.

It wasn't a joke but now you just seem to be gaslighting us. Malleable VIs are clearly the productionised implementation of VI Macros and I doubt "Malleable VIs" would exist without us discovering VIMs and discussing it here (they'd been around since about 8.2). That's not to be dismissive of all the work that has gone into getting them working properly - which is undoubtably immense - but some of us are just getting round to using the "Malleable VIs" in anger and of course the first thing we will do is go back to the code that we wrote for VIMs to find out any new limitations and what's been fixed.

Edited by ShaunR

Share this post


Link to post
Share on other sites
On 11/16/2019 at 9:50 AM, drjdpowell said:

Question for AQ: I'm trying to use "Unbundle by name" to access the elements of the cluster (the buffer array and the index integers).   This works, but if the User accidently connects a cluster without the right-named elements, the unbundles can get scrambled, and not properly reset to the right names when a proper Buffer cluster is attached.   The only solution then is to delete that VIM instance and re-drop it from the pallets.  I can't find a solution and may have to switch to an unnamed unbundle, using the positions in the cluster.  That is less than ideal, and won't work in NXG (you know my negative opinions on cluster changes made in NXG).

I think I've come across something similar with named clusters and am not sure what the behaviour should be (but with events). The behaviour is difficult to describe but I'll have a go.

I have this setup. I'm not sure how the name "Data" is chosen for the scaler type name, but it's the name of the event terminal on the VIM so that makes sense if you have to call it something.

1.png.5f2ba7e1be96ded413e59421e48e2eb0.png

Deleting the Uint32 wire and wiring the cluster works sort of as expected with the ""Data" changing to "String" (i.e. one of the cluster elements). Popping up on the event data terminal reveals both cluster elements (String and UInt32). So far so good.

2.png.600f809956a366e781a8a5eb49c5a6c3.png

Deleting the cluster wire and reattaching the Uint32 however doesn't change the event data terminal (remains as "String")and the VI is broken. BUT, popping up on the terminal shows the correct data type in the menu, which can be selected, and the VI is once again not broken. Note also that replacing the VIM yields the correct event data terminal type (called "Data"). OK. Not really a problem, but unexpected.

3.png.4a1c0e1003ffb928a0b960c14ff9b46a.png

So. Reattaching the cluster we get back to the second image (event data terminal is "String") as before. Now I change the cluster element name from "String" to "Value". But the event data terminal doesn't change, it remains as "String". The VI is not broken and popping up on it reveals the previous items "String" and "Uin32". The name change hasn't propagated nor can it be selected from the popup menu. It is recoverable, though  although I'm not sure what would happen if I tried to generate the event with a string named "Value".

4.png.1be2d1925b021b8cdcd46ae8c78c5658.png

Deleting the cluster wire and reattaching causes it to appear in the menu popup (broken VI with "String" as the event data  terminal) so selecting it brings us back to a functioning VI.

5.png.b003d9525263c11cf20ac94cfbd847ad.png

However. If instead of just deleting the wire, the VIM is replaced completely, then everything changes as I would expect (the "String" event data terminal changes to "Value" and the VI is unbroken with the correct popup menu entries).

Arguably just a another example of "left handed scissors" but the cluster name selection and propagation strikes me as another manifestation of what  drjdpowell is describing.

srevent.vim

 

Edited by ShaunR

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.