The "Launch Actor" vi

[Brainstorms]

LarsM wrote:

> Any reason why you couldn't keep a copy

None. It's just that it would be nice if it were updated with the other stuff.

Sure...  One of the really nice things about AF being all source code is that you can make your own hybridized methods for AF, to do things like make a version of "Launch Actor.vi" that does "the other stuff" as you like.  And that can be brought forward into future versions with your source code.

But this also allows you to backport fairly easily, too.  I've backported my LV 2014 Actor Framework library to both 2013 and 2012, giving me "Launch Root Actor.vi" and "Launch Nested Actor.vi" that work in those earlier LV versions. 

That was particularly helpful when I was given a task that had already started in LV 2012 and was required to continue in LV 2012, but hadn't had OOP or AF elements added yet.  So I used my backports.  Now there won't be rework issues or deprecated method VI issues if/when it gets updated to a later LV version.  (And I don't mentally have to keep track of AF version differences when I move between these 3 versions of LV on different projects -- another plus.)

One other thing I did: Since I'm now maintaining the AF library in these earlier versions of LV, it added no additional maintenance headaches for me to bring the LV Error cluster forward to the 21st Century and morph it into an LVOOP object -- with enhanced reporting & handling of exceptions (while still being backward compatible).

[AristosQueue (NI)]

Brainstorms wrote:

it added no additional maintenance headaches for me to bring the LV Error cluster forward to the 21st Century and morph it into an LVOOP object -- with enhanced reporting & handling of exceptions (while still being backward compatible).

It's kind of nice, isn't it?

I have the same thing on my personal machine. Unfortunately, I'm not going to release it, even at work -- having a disparate error experience across libraries causes all sorts of complications. The languge either moves forward or it doesn't. But, fear not, I have plans... Mwuhahaha... oh, wait, not supposed to do that in front of customers. 🙂

[AristosQueue (NI)]

LarsM wrote:

So actor enqueuers must be handled manually from now on? Not saying it's a bad decision, just wondering if that's what you're going for.

What do you mean by an actor enqueuer being handled manually? I have no idea what you're referring to.

If you have an actor being launched under another actor, use Launch Nested Actor.vi.

If you have an actor being launched under a non-actor, use Launch Root Actor.vi.

If you need to get messages OUT of a root actor, initialize it with some communications channel. The problem with using the actor enqueuers for this purpose (which is Launch Actor's solution) is that it's nearly impossible to catch data out of a message meant to be received by an actor when you aren't an actor. There's a whole discussion thread in the forums about why this went away. The vast majority of customers have told me they're very happy with the change. (Which isn't a surprise considering that it was driven by the community discussion.)

[Brainstorms]

AristosQueue wrote:

It's kind of nice, isn't it?

I have the same thing on my personal machine. Unfortunately, I'm not going to release it, even at work -- having a disparate error experience across libraries causes all sorts of complications. The languge either moves forward or it doesn't. But, fear not, I have plans... Mwuhahaha... oh, wait, not supposed to do that in front of customers. 🙂

I would say, "Brilliant!" 

And there's "releasing" and there's "sharing with the Community" -- in an unofficial capacity, of course...  (That was how AF was initially introduced and developed, wasn't it?)

I am very interested in your plans...  In part because I don't want to build tracks leading away from them.  Do please share...

[AristosQueue (NI)]

I did release to the community in 2010 an early version. That lead to problems. The issue is that it's very hard to have two different error systems in the same application, and some early users got themselves in a bind switching back and forth between error APIs. The AF was a new API. The error is largely a replacement for existing APIs.

So I have continued to do this work with community members but on a much more limited basis, but it is mostly frameworking so that real extensions are possible once it is released, and that aspect can move forward with full community feedback. That project was *supposed* to be in LabVIEW 2015, but it has been moved out (no promises of release dates).

[Brainstorms]

I can understand that.  I'm experiencing the same thing with introducing some team members to what I've produced.

From NI's timeline, it sounds like I shouldn't wait.  That's okay; we'll adapt when something official is released.

[AristosQueue (NI)]

Brainstorms wrote:

From NI's timeline, it sounds like I shouldn't wait.

No, you shouldn't. I really thought this would be the year but something happened. Hope springs eternal.

[dsavir]

AQ, what test harness VI found in the palettes? where is it?

Thanks,

Danielle

[AristosQueue (NI)]

[dsavir]

Thanks, I'll start using it

However, this doesn't launch the actor, correct? So I can't use it to test the actor if I have any helper loops in the actor's actor core.vi.

For example, I have an actor that encapsulates a TCP/IP connection to some hardware. The TCP/IP read/write loops are in the actor's actor core. I need a test that will launch the actor, send it a message to pass to the hardware, and get a reply back. For this I can't use the launch root actor. If there was no "launch actor" vi, I would need to either create a Test Actor to launch the actor under test as a nested actor, or log everything and check the log.

I admit that I already have a logging system which I'm using, but I still think that having a simple option to launch an actor and get messages back is important. Perhaps add a Launch Test Actor.vi? That would hide all the message queue code that confused everyone but still leave this option open.

Thanks,

Danielle