AF Experiment - Launch Root Actor and Launch Nested Actor

[AristosQueue (NI)]

Attached is a .zip file. Yes. Ug. I can hear you asking, "Why is this not a VIPM?" Because I've completely hosed VIPM's ability to work on my machine by hacking various things just to see what happens and I don't feel like reinstalling today this week.

Now, with that out of the way... in the attached .zip VIP file, you will find a new version of the AF saved in LabVIEW 2013 2012. IT SHOULD BE FULLY COMPATIBLE WITH LV 2013 (yes, the VIs are saved in LV 2012, but this includes all the changes made for LV 2013). I did not -- to the best of my knowledge -- break any existing functionality in making these changes.

It includes a deprecated Actor.lvclass:Launch Actor.vi and two new VIs:

• Actor.lvclass:Launch Root Actor.vi
• Actor.lvclass:Launch Nested Actor.vi

It also includes a new protected scope VI for "Actor.lvclass:Send Launch Nested Actor Msg.vi". You can read the Context Help for that VI for more information.

Please check the connector panes of the two VIs and the deprecated VI and the Context Help. Do these new names help? I took from the discussion on the forum thread where there seemed to be greatest consensus.

If this meets with community approval generally, I'll request to submit these changes for LV 2014.

[EDIT] I made context help changes per comments.

[EDIT] Moved Launch Nested Actor.vi to be protected scope.

[EDIT] Now saved to LV 2012 and moved to a VIPackage.

[fabric]

LV2012 perhaps?

[AristosQueue (NI)]

LabVIEW hates trying to save things from vi.lib into previous versions. It fights me. I didn't feel like tricking or bribing it.

Somewhat serious tangent: I thought every customer had the SSP these days. Don't you have 2013? I understand not using it for day-to-day work if you've got legacy systems, but I kind of hoped everyone would be able to evaluate this modification and then, if we decide we like this mod, then I'd take the time to make SFP and VIPM work.

[fabric]

Yes I have SSP, but I'm also supporting 50 odd systems running massive 2012 projects...

One day I'll get around to installing 2013. Or maybe I'll just jump straight to 2014. Whatever happens, I'll be resisting the urge to dive into a new version for as long as possible, because that will bring the inevitable pain of a massive field update.

Anyway, I was hoping it would just be a relatively painless Save for Previous on your side, but it seems things are rarely that simple...

[tst]

Regarding the tangent, remember Jack Dunaway's "against all odds" rant? That applies not just to getting LV, but to installing it as well. Installing LV, with all the relevant drivers, modules and toolkits, is a pain. And a pretty long one, too - assuming you know what you want to install (which is far from a given), it probably takes about 4-10 minutes to go through the installer screens and then another 2-6 hours to go through the actual installation (with DVD swapping in the middle). And that's without even going into issues like not touching a working system or keeping older versions working (for instance, I did install 2013, but the new DAQmx version doesn't support LV 2009, so now I will have to support 2009 apps which use DAQmx through a VM).

[vishots.com]

You should just accept the fact that in our world, the only way to develop is through a VM. I've been doing that for years. I can't remember when I last developed on real computing hardware. But I think 2-6 hours is an exaggeration. But even if it really was that long, if you are installing on a VM, you don't feel it since you can still work in another VM while it's installing.

[tst]

I only looked briefly at the actual VIs, but I think they're OK. I have some not too strong feelings on some points:

I don't like that the two actor inputs are adjacent, but I understand why it was done. Here are a couple of alternatives:

I think I prefer the top one, but I don't really like either of the three.

The language on the launch nested VI is confusing in first glance, because the first paragraph is the same as the the root VI and it talks about a top-level VI, which threw me a bit, because "it's not a top level actor". I got used to it after looking at it a couple of additional times and I don't have an idea for better language at the moment.

The second paragraph also strikes me as something which could be confusing to some people, but I have no actual suggestions there either, other than that it would probably be useful if it pointed to the help page which would show a diagram of the tree.

I was going to suggest a greater difference between the two icons, but I'm not sure how much that's actually needed.

In general, is it possible (or even correct) to remove the entire message queue pair palette and make it private? This would prevent people from being confused (good), but would preclude people from writing their own dequeue code (bad?). In any case, I'm assuming that's not really possible because it already shipped on the palette in 2013. Correct?

[tst]

6 hours might be an exaggeration, but I'm pretty sure it's not, because I install on a decent machine and even without installing many of the additional stuff which other people might I got ~2-3 hours.

And I still find working on a VM to be a pain relative to working on the host, partly because of overhead (launch it, RAM consumption, etc.), partly because of hardware support (USB, PCI, etc.) and partly because of convenience. I usually prefer to use the current versions directly on the host and leave the VMs to specific situations, but I'm happy it's working for you.

[AristosQueue (NI)]

I'll work some more on the documentation -- it'll get a pass by a tech writer also, which generally helps a lot. As much experience as I have in technical writing, they do it for a living. 😉

Anyone else have thoughts on the conpane?

tst wrote:

In general, is it possible (or even correct) to remove the entire message queue pair palette and make it private? This would prevent people from being confused (good), but would preclude people from writing their own dequeue code (bad?). In any case, I'm assuming that's not really possible because it already shipped on the palette in 2013. Correct?

                   

I was thinking I would drop the queue stuff entirely into the advanced palette. I *can* remove it entirely -- that's not an issue from a support standpoint -- but it is useful for interop with non-actor systems, and the raw Enqueue is needed in many advanced messaging scenarios, so I think it should stay somewhere.

[Daklu]

Conpane:

I don't have a problem with it, and to be perfectly honest I don't fully understand Yair's concern.  It seems to follow standard LVOOP conventions with the top left terminal being the input for the object that will execute the method, which in this case is launching a nested actor.

Message Queue Pair:

I strongly believe it would be a mistake to make the message queue pair private.  Moving it to an advanced palette is a good compromise.

"Top level VI" language:

Even though the language is correct--each dynamically launched actor *is* a new top level vi--I had the same initial reaction as Yair.  In my (admittedly limited) understanding of the AF I don't think users need to think in terms of "top level vis" when using it.  The actor tree replaces the vi tree.  As long as the actors are taken care of correctly the vis will take care of themselves.  I'd consider removing the references to "top level vis."

I'd also put some text in the Launch Nested Actor context help explaining autostop behavior for nested actors.  (i.e. "Nested actors automatically receive Stop messages when the owning actor exits.")

[AristosQueue (NI)]

Daklu wrote:

I'd also put some text in the Launch Nested Actor context help explaining autostop behavior for nested actors.  (i.e. "Nested actors automatically receive Stop messages when the owning actor exits.")

                   

Good catch.

[AristosQueue (NI)]

I'm going to move Launch Nested Actor.vi to be protected scope. Launching a nested actor as a public operation is not valid, since it can only be done from within an already-launched actor.

[AristosQueue (NI)]

The version I just posted is saved to LV 2012.

[tst]

Daklu wrote:

                       

Conpane:

...to be perfectly honest I don't fully understand Yair's concern.  It seems to follow standard LVOOP conventions with the top left terminal being the input for the object that will execute the method, which in this case is launching a nested actor.

                   

My problem was with the two actor inputs being next to each other. I think it can be confusing, so I moved the nested actor one input further away. Like I said, I'm not a huge fan of either.

[fabric]

Another minor connector pane observation: "Launch Root Actor" and "Launch Nested Actor" are not pin compatible. I'd like to see the "target" actor always at the 2nd input terminal from the top.

[AristosQueue (NI)]

fabric wrote:

                       

Another minor connector pane observation: "Launch Root Actor" and "Launch Nested Actor" are not pin compatible. I'd like to see the "target" actor always at the 2nd input terminal from the top.

                   

Reluctant to do that. That request conflicts with the much deeper convention that the top-left corner is always the object performing the action. In the case of Launch Root Actor, that's the actor itself. In the case of Launch Nested Actor, that's the caller.

But it is possible to move the input down on Launch Root Actor. What do others think?

[tst]

AristosQueue wrote:

                       

But it is possible to move the input down on Launch Root Actor. What do others think?

                   

Here's my image from the other thread, where the launched actor is always at the third input. I think it looks OK, but that's just my opinion:

[AristosQueue (NI)]

Alright... I'll bump it down to position 2 (not 3 as in tst's image).

[fabric]

Yes that's what I meant - I guess my comment wasn't clear...

If it is moved to position 2 on Launch Root Actor then the "target actor" is in the same position as for Launch Nested Actor.

[AristosQueue (NI)]

I have submitted the changes for LabVIEW 2014. When the beta program starts in a couple months, please check my work.

[CharlesB64]

I quickly made a VI package of this new release for LV 2011, to be downloaded here.

The palette is roughly the same as original vip, except for the "advanced" subpalette (too lazy to recreate everything).

Installing it will uninstall AF 4.1.0.29, which is the latest version of AF for LabVIEW 2011.

Of course it is completely unofficial and unsupported!

[AristosQueue (NI)]

Thanks, Charles.