XNodes Prevent Inlining

[DTaylor]

It seems that using an XNode in a VI in which inlining is enabled always generates the error: "This object is not allowed in a VI on which you enabled inlining. Disable inlining or remove this object." Is this always true, or is there some XNode ability that would allow it to be inlined?

[hooovahh]

Okay I think I figured it out.  An XNode gets inlined into your VI automatically.  But there are some functions that aren't allowed to be in an inlined VI, like New Data Value Reference, and property nodes.  So if your XNode contains something that normally can't be inlined, then the XNode is fine, but it can't be in a VI that is inlined.  Make sense?  This is also why VIMs in 2017 can't contain property nodes since they aren't allowed to be inlined.

[DTaylor]

11 minutes ago, hooovahh said:

So if your XNode contains something that normally can't be inlined, then the XNode is fine, but it can't be in a VI that is inlined.

I'm also seeing this if the XNode contains only nodes that can be inlined. It appears that a VI that uses any XNode cannot be inlined, regardless of whether the generated code can be inlined or not.

Edited October 4, 2017 by DTaylor

[hooovahh]

This isn't true for all XNodes so you are right there must be something else going on.  If you drop the Error Ring XNode (made by NI) it appears to work as expected, working on inlined VIs.

[DTaylor]

15 minutes ago, hooovahh said:

If you drop the Error Ring XNode (made by NI) it appears to work as expected, working on inlined VIs.

Hmm Error Ring XNode does work for me, but others that I think should be inlinable are not, like the Butterworth Coefficients XNode.

[smithd]

The xnode right click menu (i forget the ini key) lets you see the generated code. I'd suggest just opening the butterworth generated code and copying it directly onto an inline vi diagram, and see if that works or has an issue.

[DTaylor]

4 minutes ago, smithd said:

The xnode right click menu (i forget the ini key) lets you see the generated code. I'd suggest just opening the butterworth generated code and copying it directly onto an inline vi diagram, and see if that works or has an issue.

I did , and the owning VI shows no error when it's replaced with it's generated code.

[hooovahh]

This really does seem like a feature of an XNode.  Somehow telling the IDE that it can or can't be placed into a VI that is inlined.  Looking at the XNode in a text editor doesn't seem to help, nothing jumps out at me as a value stating it can or can't be inlined.  And the output of the generated code doesn't seem to indicate anything either.  The only hint we might get is from someone at NI...that might be reading this and wondering if they should give the mouse a cookie...the mouse says "yes".

[DTaylor]

4 minutes ago, hooovahh said:

Somehow telling the IDE that it can or can't be placed into a VI that is inlined.

There is a VI in the same directory as the Error Ring XNode named XSFP_ReplaceSelfWithGenCode.vi. I don't know if this has anything to do with this behavior. I've seen some private methods prefixed with XSFP - any idea what it stands for?

That VI is not a member of the XNode, but I agree that none of the XNode's abilities or properties look like they have anything to do with the inlinability.

[DTaylor]

I think there is just a special case that LabVIEW knows the XNode named "Error Ring.xnode" can be inlined. If I rename an XNode to Error Ring.xnode, the aforementioned error goes away.

I wonder if there is a way to whitelist other XNodes.

[Aristos Queue]

I hardcoded that one into the compiler after multiple customers asked for it... pointing out that the common use case was to encapsulate an error in a VI so it can be returned in several parts of the code. I wanted to add a way to tag any XNode but there was aversion to risk at the late date I slipped that in. After that one was fixed, there wasn't any internal pressure to do a more general fix. And XNodes aren't public features, so external pressure doesn't work in feature priority meetings. NI has largely moved away from XNodes in our own work -- much to my personal frustration. 

 

The XSFP VI is the "Save For Previous" VI if you save back to an old version before the XNode was shipping. 

[Aristos Queue]

The problem with auto detection is that XNodes don't generate their code during type propagation, only during compilation, so we would need a new tag/VI/something that declares up front "I am an XNode that will script only inlinable functions."

 

Ok. Mouse has cookie. I'm going back to improving malleable VIs for LV 2018. 

[hooovahh]

13 minutes ago, Aristos Queue said:

Ok. Mouse has cookie. 

You must know the second half of that expression...NOW WHERE'S MY MILK? (sorry for shouting but it felt appropriate).

I'd love for a way for the XNode itself to state that it will or won't contain code that allows inlining since auto detection is mostly impossible.  But it sounds like that will likely never happen.  Thanks for the the help.

[Aristos Queue]

I'm unfamiliar with the saying.

 

The big problem is what happens when someone says "This XNode will be inline safe" and then scripts non-safe code. It's so late in the compile sequence, I'm not sure what the behaviors would be. 

[hooovahh]

“If you give a mouse a cookie, he’s going to ask for a glass of milk. When you give him the milk, he’ll probably ask you for a straw. When he’s finished, he’ll ask you for a napkin.”

I was asking for an explanation, full well knowing it might lead to me asking for other things.  But I do agree that the result of an XNode stating "I'm inline safe" and then not being, might lead to a crash or other unexpected behavior.  Still I sorta feel like that is the result of a poorly made XNode, and while NI could protect for it, there are plenty of places I can force LabVIEW to crash doing something stupid and NI can just respond with "Don't do that." because I'm at fault for not abiding by the documentation.

[DTaylor]

18 hours ago, hooovahh said:

I'd love for a way for the XNode itself to state that it will or won't contain code that allows inlining since auto detection is mostly impossible.

I think you can! It looks like the compiler exception doesn't check the fully qualified name. You can put your inline-safe XNodes inside libraries to namespace them, and name them all Error Ring.xnode.

[DTaylor]

Why stop there? It seems like there are a few nodes that disallow inlining even though it seems like it should be fine. Now we can just wrap them in an Error Ring.xnode!

[Aristos Queue]

On 10/5/2017 at 7:23 AM, hooovahh said:

I was asking for an explanation, full well knowing it might lead to me asking for other things.  But I do agree that the result of an XNode stating "I'm inline safe" and then not being, might lead to a crash or other unexpected behavior.  Still I sorta feel like that is the result of a poorly made XNode, and while NI could protect for it, there are plenty of places I can force LabVIEW to crash doing something stupid and NI can just respond with "Don't do that." because I'm at fault for not abiding by the documentation.

There should be exactly two of those things in released features: the Type Cast primitive and the Call Library node. And maybe System Exec.vi. But otherwise, no, we treat anything that can crash LabVIEW as something we messed up on.

 

On 10/5/2017 at 10:57 AM, DTaylor said:

I think you can! It looks like the compiler exception doesn't check the fully qualified name. You can put your inline-safe XNodes inside libraries to namespace them, and name them all Error Ring.xnode.

Thank you for reporting that bug. Found and fixed in LV 2018.

[hooovahh]

4 minutes ago, Aristos Queue said:

There should be exactly two of those things in released features: the Type Cast primitive and the Call Library node. And maybe System Exec.vi. But otherwise, no, we treat anything that can crash LabVIEW as something we messed up on.

Wish I would have known that earlier, could have filed a couple hundred CARs by now.  When LabVIEW is stable I'd say it crashes a couple times a week, but it isn't a big concern because the fix is generally to start it up again.  I also think variant to data could help invoke crashes too by converting things to things it shouldn't and then acting on those things.  I just tried a few things I know used to crash LabVIEW when messing with registering for events but couldn't get it to occur so maybe that one was fixed. 

10 minutes ago, Aristos Queue said:

Thank you for reporting that bug. Found and fixed in LV 2018.

It's not a bug its a feature.  One I'll admit I wouldn't use, but still.

[Aristos Queue]

1 minute ago, hooovahh said:

Wish I would have known that earlier, could have filed a couple hundred CARs by now. 

Please start now. Only squeaky wheels get grease.

Quote

I also think variant to data could help invoke crashes too by converting things to things it shouldn't and then acting on those things. 

Not Variant To Data... that has full checking on it for coercion legality. It isn't a raw Type Cast. I suppose you could get a backdoor Type Cast using the Unflatten From ____ nodes... on refnums. Casting refnums is the heart of the problem. I should have phrased it more broadly -- the two things you can do to crash LV that aren't R&D's fault are moving refnums onto wires that don't match their real types and calling outside of LabVIEW (to DLLs, Sys Exec, etc) in ways that inject back into LabVIEW.

6 minutes ago, hooovahh said:

It's not a bug its a feature.  One I'll admit I wouldn't use, but still.

If a user writes a piece of LabVIEW and gets behavior that contradicts intended design, including failing to get an error when they should, that's a bug. Some are small enough compared to the effort to fix such that we let them go without being fixed, but they're still a bug. And changing the one line of code from "FileName()" to "QualifiedName()" is a pretty low-hanging fix.