Malleable Buffer (seeing what VIMs can do)

[ShaunR]

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 November 18, 2019 by ShaunR

[drjdpowell]

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.  

[ShaunR]

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 November 18, 2019 by ShaunR

[Aristos Queue]

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. 

[Aristos Queue]

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.

[ShaunR]

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 November 18, 2019 by ShaunR

[Aristos Queue]

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.

[TomOrr0W]

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

[ShaunR]

5 hours ago, TomOrr0W said:

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

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

[Aristos Queue]

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.

[ShaunR]

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 November 21, 2019 by ShaunR

[ShaunR]

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.

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.

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.

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

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.

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 November 22, 2019 by ShaunR

[Aristos Queue]

I've put the freezing of the bundle/unbundle nodes (including those on the In-Place Element node) into LV 2020.

[Aristos Queue]

The New Data Value Ref and Delete Data Value Ref nodes will be able to be in inline VIs (and thus malleable VIs) in LV 2020.

[Aristos Queue]

On 2/5/2020 at 9:27 PM, Aristos Queue said:

I've put the freezing of the bundle/unbundle nodes (including those on the In-Place Element node) into LV 2020.

This IS fixed in LV 2020, but it got left out of the Upgrade Notes*.

I have posted details here:

https://forums.ni.com/t5/LabVIEW/LV-2020-Upgrade-Note-Altered-rules-for-named-Bundle-and-Unbundle/td-p/4035624

The fix is very healthy for most apps, but we did find one internal-to-NI app that was dependent on the dumb-luck-that-it-sometimes-works behavior. We had to fix that one up by using the Coerce To Value primitive to set a name of the element in the caller. But going forward, such antics should not be necessary... the adaptation rules of named bundle/unbundle are now well-defined.

* My mistake -- apparently my tech writers cannot read my mind; I actually have to hit Submit on bug reports, not just leave them in Draft. *chagrin*

[drjdpowell]

Decided to update this to 2020 and release (this is 0.3; I never posted 0.2):

jdp_science_lib_malleable_buffer-0.3.0.8.vip

[drjdpowell]

I've put 0.4 on VIPM.io.

[Aristos Queue]

Malleable Buffer.zip

James: I did a lot of polish on your library -- cleaning diagrams, finishing out a couple of API points, documentation. I deleted the experiment stuff. You're free to take the attached files and add them to your published VIP if you want.

There was only one real functionality change that I made: a performance improvement to "Add to Buffer (By Value).vi".

Thank you -- this code is quite helpful in my current project.

[drjdpowell]

@AQ,  I've incorporated most of your improvements, and made some changes myself.   Question, though.  These VIMs seem plagued by (in LabVIEW 2020) strange recompile bugs: broken wires that are usually fixed by doing a manual force recompile on the VI.  Though often this still leaves some broken wires in a runable VI?!?  See image.

What do you think causes this and is there a way I can avoid it?  

[drjdpowell]

Put a new 0.5 version on VIPM.io    Remember, this is still beta code.

[Dataflow_G]

21 hours ago, drjdpowell said:

@AQ,  I've incorporated most of your improvements, and made some changes myself.   Question, though.  These VIMs seem plagued by (in LabVIEW 2020) strange recompile bugs: broken wires that are usually fixed by doing a manual force recompile on the VI.  Though often this still leaves some broken wires in a runable VI?!?  See image.

What do you think causes this and is there a way I can avoid it?  

I can't speak for the buffer library, but I've observed this behavior many times with malleable VIs in my own code. One thing (bug?) I've noticed (and reported on the dark side) is that nested type specialization structures within a vim can lead to broken wires. This is generally as a result of an assert vim inside a type specialization structure inside a vim. The callers wires are either visibly broken but otherwise runnable, or just broken even though the input types are supported.

The LabVIEW 2021 SP1 bug fixes mention a fix (bug ID: 1596011) for vims and erroneously broken wires, but I've not tried it out yet. I really hope that's the end of the broken wire quirks with malleable VIs, as they're a really great feature.

[thols]

Quote

The LabVIEW 2021 SP1 bug fixes mention a fix (bug ID: 1596011) for vims and erroneously broken wires, but I've not tried it out yet. I really hope that's the end of the broken wire quirks with malleable VIs, as they're a really great feature.

For me it has improved but is not quite fixed. I still get broken wires on the calling VI when changing anything in some vims. In fact, I have a VI which I copied from the Debug Log.lvlib:Debug Write.vim in vi.lib and made some changes to. My version breaks when I change anything in it, but the VI.lib-one does not. I have force-recompiled and am now trying to make my VI work like the one in vi.lib, but mine still breaks. I just might recreate it and see where/if it breaks then. I don't know if I am unlucky or if that might happen for others too. When the wires do break, it seems like they auto-heal better than before, when I had to rewire at every broken place, but now its enough to just do something that triggers a compile (I think).

[thols]

There were some minor changes in the TSS in that VI between LabVIEW-versions. I just replaced the old TSS in that VI with the new and now it worked. So no broken wires when changing anything in that VI.

[drjdpowell]

On 3/19/2022 at 2:08 PM, Dataflow_G said:

The LabVIEW 2021 SP1 bug fixes mention a fix (bug ID: 1596011) for vims and erroneously broken wires, but I've not tried it out yet. I really hope that's the end of the broken wire quirks with malleable VIs, as they're a really great feature.

Thanks. I see there is also this one that may be the problem I'm having:

1513139        Malleable VIs Are Sometimes Erroneously Broken When Operating on Cluster Data Value References

[drjdpowell]

Tried it on LabVIEW 2021sp1, and it seems to have at least fixed the problem with a broken VI requiring manual recompile.  No working VI with apparently broken wires yet, either.  Possibly I should just up the base version of this package to 2021.