Allow 'This VI' object in inlined VIs

[SteenSchmidt]

Hi,

I propose that we allow the 'This VI' VI Server object inside inlined VIs. Currently dropping a 'This VI' object into an inlined VI breaks it.

The reason for this suggestion is so I can build inlined VIs that automatically gets a valid VI refnum to the caller VI instead of forcing the caller to supply this refnum to me. I.e. instead of having to do this:

I'd very much like just to inline my subVI and stuff the 'This VI' object inside that subVI, in which case that inlined subVI could be dropped into any caller and automatically get the caller's VI refnum (due to the inlining). The above call would just look like this instead:

Surely we could just make the inlined subVI use this piece of code instead of the 'This VI' object then, as that is allowed inside an inlined VI:

...but unfortunately we can't as the above isn't a sound way to get a VI refnum to a clone of a reentrant VI for instance. If you obtain a VI references to a clone by any other means than the 'This VI' object you can get into all sorts of trouble. LabVIEW isn't designed to support this, so it can easily become unstable and crash. Hence, please allow the 'This VI' object inside inlined VIs.

Cheers,

Steen

[altenbach]

I think the main problem is that changing an innocent inline setting would cause a complete functionality change of the subVI. That seems dangerous.

[SteenSchmidt]

That's the case already if you include stuff like the callchain prim. No change there.

/Steen

[drjdpowell]

The need for inlining can be a prominant comment on the BD or Front Panel.  That is preferable to the current method of opening a reference, which can be unstable.  There are several VIs in OpenG that use this technique and could be improved by this idea.  "This VI" is also faster than "Call Chain".

[SteenSchmidt]

Faster by several orders of magnitude. No contest there.

/Steen

[AristosQueue (NI)]

I would strongly oppose the "This VI" being inlinable... but I would support a new function "Caller VI Reference" that could be inlined.

Inlining will someday be something that the compiler decides on its own, as it is in other programming languages. We want to minimize the number of things that change behavior when inlined as a hedge against that day.  When inlining was first introduced, there was a lot of discussion within R&D about whether to ban Call Chain from inline VIs, and it only got through because of its use in debug and error reporting code. The This VI Reference is used for a lot more brat VI type operations, and it would be very problematic if it changed behavior behind the scenes to suddenly reference a whole different front panel just because the compiler was targeting a different platform where it decided that inlining was advantageous. The Caller VI Reference would be something that would work regardless of whether the VI was inlined or not -- and users who didn't understand inlining (and most people shouldn't ever have to) would be much less confused when reading your code.

[SteenSchmidt]

In the current implementation of inlining in LabVIEW there are several situations where enabling inlining changes the code output. One of these is when you use Call Chain. There are two fronts in the inlining debate; one says that inlining a method may not alter the code output ever - it should just be about rolling the code into the caller to avoid the call overhead, and then it's up to the programmer to handle anything that breaks while doing this (peeking the call stack for instance). The other front doesn't want this freedom but instead wants to exclude certain functions from being allowed in inlined methods, namely those functions that would behave differently.

The LabVIEW implementation lands somewhere in between this by allowing Call Chain and disallowing others in inlined subVIs. That's problematic.

I'm mostly in favor of allowing all functions in inlined subVIs, and then 1) make the compiler replace any problematic construct with an alternative construct that will actually work correctly when inlined, and 2) then allow the compiler the freedom to reject the inlining request in those cases where it deems the final inlinable code too mad. Basically as in C++ where Inline is a keyword that requests the compiler to inline but the compiler has the final say in whether the code actually gets inlined or not.

So that's;

1) Change the Inline checkmark from a Do to a Request inlining.

2) Allow all functions in inlined code, and let the compiler sort out what to fix so everything'll work whether inlined or not.

3) Let the compiler decide whether to inline or not. Possibly even at runtime, jump to compiled code A or fall directly through to compiled code B depending on execution history, current resources etc.

I'm definetely not in favor of removing the inline option alltogether and put it solely on the compiler to decide. Mainly because everywhere it has been implemented it just doesn't work too well. In C# for instance there's a static cap on function length that the compiler will inline (32 bytes IL IIRC). How did that come about? No, I don't think the heuristics will be there for many years to come. Then a better approach would be Javas inlining which is most often done at runtime, but there is no true Inline keyword in Java. Sometimes Static methods gets inlined, sometimes Final methods gets inlined (again, IIRC).

But back to my idea here; Yes, This VI (or more likely the caller refnum from Call Chain) is most often used for brat VIs. But why should inlined VIs be kept from controlling their callers? Brat VIs are more removed from the dataflow paradigm than most in LabVIEW, but so are callbacks and events for that matter, and those are powerful concepts we shouldn't cut out of LabVIEW either. Will a new "Caller VI Reference" primitive solve my problem? Only if it behaved differently whether it was in an inlined subVI or a called subVI. But for this I can just use the Call Chain function instead, preferably with the small change I request here .

Cheers,

Steen

[SteenSchmidt]

I almost forgot: For really slick brat VIs it would be great with a variant of the Call Chain prim that returned the refnums instead of the names, or possibly a Caller refnum property in the VI class analogous to the Owner property of the Control class. And all still inlinable preferably, but Property nodes of course aren't currently...

/Steen

[Intaris]

I don't see the parallels between "Call Chain" and "This VI" in the sense that the function "Call Chain" is a top-down routine which has a guaranteed validity.  It's also populated dynamically.  It's always available because without an application instance to run the code, we have no code.  The "This VI" is different because it targets a specific tier of the hierarchy which may or may not be present (depending on Inlining or not).  "This VI" refers to something specific.  Something with a defined (and sometimes in the case of inlining) absent scope.

For me this is the reason why I think a new primitive would be the solution here.  If I am targetting a specific tier of a hierarchy and by inlining I will no longer be able to target that (because it won't exist) then I want LabVIEW to tell me.  The only things LabVIEW tells me which I actually pay attention to are errors.

If, on the other hand, I specifically use a function which is documented to behave differently in an inlined VI versus a standard VI then I am making the conscious choice to do so and the compiler can also know my intentions instead of having to second-guess them.  While I think the LV compiler is fabulous (Mega kudos to the compiler team) I think a lot of the "But it's clear from my code that X is my intention" doesn't hold for people who think differently.  And I tend to think differently.  I even think differently to myself at times. 🙂

So to cut a long story short, I agree with AQ

[SteenSchmidt]

I draw the parallel between Call Chain and This VI at the point where Call Chain level 0 is This VI. For sure, Call Chain returns its qualified name, and This VI returns the refnum - but they're properties of the same object.

The validity of Call Chain and This VI is equal as I see it. For sure, you always have a call chain (sometimes with a fake top-level VI as for async called VIs for instance), but it's always present (otherwise as you put it, without call chain no call, right?). But that must be true of This VI as well. This always points to myself, and I am always here (if I am a VI of course). If I get inlined I am suddenly part of a new me which This now points to - i.e. documentable variable behavior between inlined and not inlined functionality. But This is well defined in both cases.

I'm not saying I don't agree with Stephen, I'm just taking the debate one step further towards a general review of inlining. I get the feeling that Stephen maybe wasn't so hot for allowing Call Chain in inlined VIs either, but it was maybe seen as the least of two evils at the time. I'm then saying that if you allow Call Chain the same arguments could be used for This VI. But if you view those two functions not by themselves, but in the context of most common use cases, then the differences between them gets more. And that could tip the scales (and obviously have).

Then again, my experience with this idea exchange tells me that this is not the place where we get big things done, we can only ever hope to influence the details. I have tons of improvements suggested for poly VIs, the execution priority system etc., but all that is of course async to what goes on in R&D, so we'll never be able to cooporate with NI on that level through the idea exchange. Hence, my remarks here regarding inlining will just remain that - remarks and footnotes. They will never influence the development of LabVIEW. This last paragraph was actually sad to write .

/Steen 

[AristosQueue (NI)]

> I get the feeling that Stephen maybe wasn't so hot for allowing Call Chain in inlined VIs either

I argued vigorously for both sides. This was one of those where I had no loyalties other than getting all the arguments on the table. I probably would have opposed it if I had known about the hack/trick/technique/whatever of using the Call Chain primitive to get a VI name to use for Open VI Reference. As long as Call Chain was just a documentation thing for debugging and error reporting, it was easy for me to argue either way. Once I understood the brat VIs use case, I became more reluctant (though I conceed that ruling it out would be a serious blow to error reporting).

> Then again, my experience with this idea exchange ... This last paragraph was actually sad to write.

I think you might be surprised how much the exchange has been driving things, down to specific comments. There are long delays between any given section of LV getting upgrades. PolyVIs are, for example, slated to get a pretty deep review sometime in the next five versions of LV... let's wait and see how many of idea exchange suggestions get incorporated. The prioritization of areas to work on has definitely been driven by the exchange -- witness the work done on events in LV 2013.