Initializing Actors

[AristosQueue (NI)]

Thanks, David... I've been trying to write more of this sort of content to feed to the tech writers who are trying to document this behemoth for the LV release. I may have accidentally mislead them by saying there were only about 20 public VIs to the framework -- I didn't realize they were using that as the estimate of how long it would take to document the API. 🙂

[AristosQueue (NI)]

DavidStaab wrote:

I introduced an Alliance Member to AF today, and within 30 minutes of digging into it he asked me if "there's an easier way to debug these things".

Yep. I've asked the same thing of many many developers, both within and without NI. You should see the LAVA thread on this question (which actually developed a useful tool for aborting reentrant instances, although it is clunky).

The next revision will offer some assistance, but my biggest admonition is "Stop trying to test and/or debug your whole application in one go."

The actors are by-value objects. Many of them can be tested by just directly calling their methods one by one. Some actors really need to be tested with a full launch of their Actor Core.vi... in those cases, the actors can be launched in isolation by a test harness. The test harness feeds it messages and listens for responses. It's amazing how far you can get just testing one actor at a time, and then the whole system just magically works when you bring it all together. (Useful scripting tool if someone wants to build it: Auto generate at test harness for an actor + set of messages).

[AristosQueue (NI)]

niACS wrote:

And yes, ToddLesher, stepping into a Send Message is pretty useless.  But the problem is rarely in getting messages to the recipients, so you can go right to the corresponding method in the recipient and pick up the trail there.

Someone suggested a flag that can be set on Message.lvclass that trips a breakpoint when that particular message gets dequeued. The twin problems are that

1) there's no way to set that flag while the app is running (probes cannot write back to the wire).

2) the code that would check that flag would be in the Actor Core all the time.

Paired probes that use some sort of variable to share data seem like a possible solution here.

Also looking for mechanisms to pause all VIs in memory simultaneously. One of the biggest pains is you set a breakpoint in Actor 1 but Actor 2 keeps running and generating messages. I really want to pause all the actors at once. No clue how to do that at the moment.

[dougku]

In the table with 3 ways to initialize actors, should there be a fourth method?  What about using one of the actors methods to launch a nested actor.  Then initialization could occur in a different method.  If the initialization method is successful, then a message can be sent to the launch method using (for example): Get Queue for Sending to Self.

[AristosQueue (NI)]

dougku: Once an actor is launched, the actor is already -- by definition -- initialized. Anything that you do using messages is happening on an already-running actor. So, no, I wouldn't call sending a message later "initializing".

[dougku]

Right, but nested actors aren't necessarily initialized yet. I was trying to get at the drawback for Launch MyActor.vi that "Users are not guaranteed to launch the actor using this VI."  I see that my suggestion has the same problem (it doesn't matter whether a nested actor is launched from Actor Core or one of the Actors methods). I have added my actors to a library and made the higher level actor public and nested actors private. Then the user can only launch the higher level actor, guaranteeing that the nested actors intitialize the way I want them to.  However, I guess this really isn't a guarantee in the sense that you meant.

I understand the difference in terminoloy between child actors and nested actors, but I am not sure what to call the actor that launches a nested actor.

[AristosQueue (NI)]

dougku wrote:

but I am not sure what to call the actor that launches a nested actor.

We've generally been calling it the "caller actor".  It's the best anyone has come up with, and it does accurately describe an actor that is at the other end of the actor-to-caller queue.

[dougku]

Great, caller actor it is.  I have been introducing the Actor Framework to a freshman class of 80 University of Kansas Mechanical Engineering students. I'll let the community know how it goes.  Projects are due next week that will integrate one or more components from Android smartphones, Wii remotes, and Lego NXTs.

Thanks

Douglas Kieweg

[SteveChandler]

AristosQueue wrote:

We've generally been calling it the "caller actor".  It's the best anyone has come up with, and it does accurately describe an actor that is at the other end of the actor-to-caller queue.

What about "director"?

[justACS]

AristosQueue wrote:

dougku wrote:

but I am not sure what to call the actor that launches a nested actor.

We've generally been calling it the "caller actor".  It's the best anyone has come up with, and it does accurately describe an actor that is at the other end of the actor-to-caller queue.

I'm rather partial to "owner", myself, for the specific case of the actor that creates and destroys a nested actor.