AF from 2012Beta to 2012Released - what is changed?

[komorbela]

I have used the Actor Framework from the Lv 2012 Beta to make sure I wil be compatible with the Lv2012. But unfortunately there is still a bunch of code that was changed, or at least renamed. Can someone help me what was changed, or hopefully just remaned to what? I uninstalled the 2012 Beta, so it is not straightforward to compare the versions, as I totaly deleted the Beta version

[LVB]

A partial list:

OLD NAME                                           NEW NAME

Message Queue Pair.lvclass	Message Queue.lvclass
Send Queue.lvclass	Message Enqueuer.lvclass
Receive Queue.lvclass	Message Dequeuer.lvclass
Get Queue For Sending To Self.vi	Read Self Enqueuer.lvclass
Get Queue For Sending To Caller.vi	Read Caller Enqueuer.lvclass

Unfortunately this is a manual process.  It would be nice to have a "migration tool" that would allow the user to replace a missing object (VI/class/...) with a new namespaced object.  Any tips on how to script this?

[AristosQueue (NI)]

Yes!

I didn't want to break compatibility, but beta users had a lot of really great suggestions, and after AF becomes part of LV, breaking compatibility would be a much bigger deal. So, for the good of the future, I made the call (with backing from others) that we should bite the bullet.

The biggest change is the rename of the three queue-related classes and the VIs noted by LVB. Best suggestion for migration? Load your project, then rename the 3.07 classes and the VIs so that your VIs get updated, save everything, then delete the (now mangled) VIs/classes and install version 4.x.

We changed the call contract on Actor.lvclass:Stop.vi --- the Stop VI now gets called regardless of how the Actor stops -- both on Stop message and on error. That is just something you have to account for in your code. It makes it a lot easier to say "Pre Launch Init allocates resources, and Stop Core.vi releases those resources, and these are guaranteed to be called for all actors."

[komorbela]

Thank you (both) for the fast answer! I already have started to write a migration tool, but as it loads borken VIs in memory always searches for the non-existing classes, VIs, so the automatic tool still need my interaction to press "Ignore All" So first I wil try with renaming the new files back to old, and than to new from the project window. I will post the easy solution as I find it.

[onnodb]

First of all, congratulations AQ on the release of the AF with LV 2012! I've been playing with it yesterday, and overall, I'm impressed with the integration of the AF 4.0 with LV.

Thanks also for the migration tips. I tried a manual migration of my current project yesterday, but having to go through all of my message classes to fix class references didn't seem very appealing. Your renaming trick seems much more efficient

By the way: Besides prettier icons , what would be the most important reasons to upgrade from the LV 2011 AF to the LV 2012 "MAIN" one?

[KuGr]

In my opinion, the best reason is the fact that back ports to LV2011 version will be from the LV2012 version (AF4.x) and include all of it's new class and method names.  There will be an LV2011 version of AF4.x.  I think AQ is working on that if he has not already released it.  Can't keep up with that guy.

Also, I have multiple projects with the framework, though they are based on a back port of LV2012 BETA2.  I am thinking that deriving and empty Send Queue.lvclass from Message Enqueuer.lvclass (also for Receive Queue and Message Queue Pair from their new AF4.x counterparts) and maintining methods that existed in AF3.x along side the new methods that do the same thing.  Loading existing projects based on this library will still work (crossing fingers).  Then perhaps a script can be writtein to swap out method calls and eventually swap class references.

I have not tried this for AF3.x - yet.  When I moved from AF3.x to LV2012 Beta 2, I did it a brute force and painful way.

Kurt

[AristosQueue (NI)]

There's a modification to the AF to keep the run-time engine from quitting early when one actor hands off to another and the first closes its window before the second one gets open.

The "Send Normal Or Emergency Stop.vi" is new, which lets an actor stop its nested actors using the same priority that it was stopped with.

The contract for calling Stop Core.vi is significantly improved to make it a lot easier to acquire and release system resources safely.

"Launch Actor.vi" has a new optional Boolean input that will cause the FP to open when the actor is launched, which can simplify debugging.

"Equals Not A Refnum.vi" added for both Enqueuer and Dequeuer (formerly Send Queue and Receive Queue).

In 4.1 added Actor:Substitute Actor.vi to support the State Pattern. Also modified Launch Actor.vi to remove any dependency on the LV root loop so that launching an actor doesn't get hung up if the user happens to click on a pop up menu.

[onnodb]

OK, great, thanks a lot AQ! Plenty of reasons to upgrade, then

[Oli_Wachno]

While upgrading my 2011 project from 3.0.7 to 4.1.29 I realized that the inferface of Reply Msg: Do Core.vi has changed:

the Reply output now holds variant instead of object type data.

Before re-coding all Do Core.vi calls in the hierachy, I'd like to know the reason for this change in order to fully understand, what I'm doing

Cheers

Oli

[AristosQueue (NI)]

Oh, right... I forgot about that one...

The reason for the change is use cases. We have very very few actual use cases for a Reply Msg, but in those few cases, getting a Message back was completely useless. In general, Messages are useless unless you have an Actor object to pass into the Do.vi. But when you're using a reply message, it is mostly from one of the appended loops in Actor Core.vi, not from the main message handling loop (because you should generally avoid hanging the main message handling loop if at all possible). In other words, there is no Actor to get the reply. So you end up putting a bunch of accessor methods on a Message class just to access the payload. That's kind of silly. It doesn't save you anything in the way of typecasting because you have to do a To More Specific on the Message class in order to use those methods. Ultimately, the reply is just a type-less data holder, and it is better to use the type-less data holder that we already have (Variant) rather than make everyone create one for each reply msg. If you want to send a Message back in that Variant, go right ahead. But this gives you an option of sending any other data home.