08-27-2013 05:00 PM
see: http://lavag.org/topic/17056-monitoring-actors/
Here is a tool that I developed to help debug in the Actor Framework. See my LAVA post for more details.
Edit: I've got an updated version that installs as a package. In addition, it installs the "monitored actor switcher" in your tools menu. This makes switching between actors and monitored actors super easy.
08-29-2013 03:20 PM
This is a really good direction. Imagine if we just had a debugging tool that temporarily interjected this into your inheritance trees and then could strip it back out when you were done. No changes to the core framework, no changes to your source code other than that inheritance, but with just that change, we get substantially improved debugging. With LV 2013, the Monitored Actor can override the new Receive Message.vi method and I think go even further.
This is good stuff.
08-29-2013 03:36 PM
Yeah I was excited when I saw the AF changes in 2013. Whats the performance of the "Get Class name" like? With that + a Receive Message override it'd be pretty trivial to create a log of all the messages that your actor is processing.
08-29-2013 03:42 PM
DerekMGI wrote:
Yeah I was excited when I saw the AF changes in 2013. Whats the performance of the "Get Class name" like?
Multiple orders of magnitude better than any previous mechanism. I added it explicitly to support deserialization mutation effects and logging.
09-16-2013 12:15 PM
Any plans on adding better debug tools natively to AF. I tried the DEBUG fork and It didn't do anything for me (may have even introduced a bug after I uninstalled it)
09-17-2013 11:56 AM
Jeannius wrote:
Any plans on adding better debug tools natively to AF. I tried the DEBUG fork and It didn't do anything for me (may have even introduced a bug after I uninstalled it)
We've talked about it. This Monitored Actors idea is a better approach than any suggested thus far. The DEBUG fork doesn't work in 2013. I need to go put a note about that -- and it doesn't work because something inside 2013 changed that makes it impossible for me to repair the DEBUG fork. (We were using an undocumented feature of LV to make it work, and that undocumented feature changed.)
Note that when I say "we", I mean the community here on this forum. Actor Framework is being handled a bit differently than any other feature of LabVIEW has ever been handled. It is an experiment of mine. National Instruments is the publisher of the official AF, but what I push up to the AF comes from the work of the community. The community does include myself, niACS, MattP and other NI folks, but not as part of our regular jobs.
As such, this framework moves forward as tools get developed and the community decides that this is worth promoting. There's no particular democratic process. It's just that when I judge that people see enough benefit in something and it has gotten enough tender-love-care from the group then I take the effort to move it into LabVIEW's main branch.
As I say, this is an experiment in getting the LV user community more involved in LabVIEW's developement. It is a strategy by which a valuable framework that isn't really core to National Instruments business models can get wider distribution.
Given all that --
If you like the monitored actors approach, before we would really ship it with LabVIEW, we almost certainly want a new Tools menu item or a provider pop up menu for "Change all classes in hierarchy to inherit from Monitored Actor for debugging" and the menu item to undo that modification when debugging is finished. If you have spare bandwidth to help write the scripting code to make those transitions, I suspect it would be easy enough to wrap that scripting code in the project provider plug-in that niACS has been building so that it becomes a popup menu item on classes.
10-07-2013 11:58 AM
AristosQueue wrote:
Jeannius wrote:
Any plans on adding better debug tools natively to AF. I tried the DEBUG fork and It didn't do anything for me (may have even introduced a bug after I uninstalled it)
We've talked about it. This Monitored Actors idea is a better approach than any suggested thus far. The DEBUG fork doesn't work in 2013. I need to go put a note about that -- and it doesn't work because something inside 2013 changed that makes it impossible for me to repair the DEBUG fork. (We were using an undocumented feature of LV to make it work, and that undocumented feature changed.)
Note that when I say "we", I mean the community here on this forum. Actor Framework is being handled a bit differently than any other feature of LabVIEW has ever been handled. It is an experiment of mine. National Instruments is the publisher of the official AF, but what I push up to the AF comes from the work of the community. The community does include myself, niACS, MattP and other NI folks, but not as part of our regular jobs.
As such, this framework moves forward as tools get developed and the community decides that this is worth promoting. There's no particular democratic process. It's just that when I judge that people see enough benefit in something and it has gotten enough tender-love-care from the group then I take the effort to move it into LabVIEW's main branch.
As I say, this is an experiment in getting the LV user community more involved in LabVIEW's developement. It is a strategy by which a valuable framework that isn't really core to National Instruments business models can get wider distribution.
Given all that --
If you like the monitored actors approach, before we would really ship it with LabVIEW, we almost certainly want a new Tools menu item or a provider pop up menu for "Change all classes in hierarchy to inherit from Monitored Actor for debugging" and the menu item to undo that modification when debugging is finished. If you have spare bandwidth to help write the scripting code to make those transitions, I suspect it would be easy enough to wrap that scripting code in the project provider plug-in that niACS has been building so that it becomes a popup menu item on classes.
two things:
1. I don't view the tool you mentioned as manditory. I think it would be useful in certain specialized cases. My original idea is that monitored actor would contain some conditional disables that made all the monitoring code a bunch of no-ops in runtime, and I'd leave it running in dev mode. This would add a bit of code to your executable, but it would be a negligible amount. Monitored actors would be a desktop only thing, so I think that's a fairly safe assumption.
2. One of the things I debated about when writing this tool was "Is the actor monitor window an actor?" In the version that I published here, it is. I'm starting to regret this decision, and I think it's causing some race conditions. I think I've got enough evidence to justify switching it to a non-actor based implementation. I think this would clean up some of the monitoring code as well as eliminating this race condition. These problems all stem from the fact that I can't launch the actor monitor in the pre-launch init of another actor, which is where I really need to do it.
Curious on other people's thoughts of these two issues.
10-09-2013 04:33 PM
DerekMGI wrote:
These problems all stem from the fact that I can't launch the actor monitor in the pre-launch init of another actor, which is where I really need to do it.
Can you use an Asynch Call By Ref call to Launch Actor.vi to do it inside Pre-Launch Init.vi? That would allow you to launch it -- it wouldn't start running until you left Pre-Launch Init.vi, but it would be up and running. Is that sufficient?
04-29-2014 01:42 PM
Hi All,
Okay, I've run into a problem stopping an actor. I had the actor inheirit from Monitored Actor.lvclass, I see the actor in the list of monitored actors. When i exit my code, the Monitor UI closes, but not the problem actor's UI and problem actors Actor.lvclass:Actor Core.vi is also still running. I know that Stop Core should not be called because this happens outside of the main loop in Actor.lclass:Actor Core.vi.
I've checked and double checked that the actor is indeed running and is inheirting from Monitored Actor.lvclass. I've placed breakpoints on the wires exiting from Actor Core parent call and they never get hit.
Any ideas why the Monitor UI would close when monitored actors are still running? I will deal with the problematic actor that won't shutdown.
NOTE: The probematic actor has no parent actor, it is an actor that is launched along side my main actor to allow me to see event as they happen for debugging.
Thanks,
04-29-2014 01:53 PM
Here's what I think. I'm guessing a little here, and I wont be able to say for sure without looking at your code.
I think your Stop Cores are hanging up. You're calling the parent stop core (which will take the actor out of the monitor window) but then you're running code after which is hanging up. This means you're call-to-parent actor core will never stop.
It's possible that Monitored actor is doing this, but I haven't seen it. I've got an updated version of monitored actor that may help.