How to probe private data of actor when running?

[drjdpowell]

mthimm1 wrote:

In my opinion modifying the original Actor.lvlib:Actor Core is even worse than the use of data value references. You might want to preserve the original library in order to replace it by a newer version as drop in replacement.

There is no need to fork the AF. Receive message.vi is called everytime a message is executed. It is called exactly as often as do.vi.

Uh... what are you talking about?  Why would I need to modify Actor.lvlib:Actor Core just to put a probe on it?  I need to get the Block Diagram open, but that can be done with a message.

[mthimm1]

Ah okay sorry I was completly missunderstanding your point. Since unfortunately my LabView Version is german, i did not associate "probe" with a feature of the LV IDE. In addition I do not use this feature at all.

By probing I was thinking of programmatically reading the data.

You are fully right. One does not need to modify AF lib to probe data from the actor private data cluster.

[CaseyLamers1]

I started writing this reply and then decided I needed to rearrange the order of the paragraphs. I had the next paragraph at the end and decided I needed to move it to the beginning.

If you need to test the methods of the actor I would suggest using VI Tester from JKI. You can test the actor, you can test the methods, and you can test the messaging to/from the actor. Best of all, once you build a test case you can run it reproducibly when you edit code. If you are going to spend the time to poke your code and see that it works (which we all do) you should spend that time creating a "Test" that you can show someone and run again in the future.

Here is a video on how to do this stuff: https://www.youtube.com/watch?v=AFNbdF7ZU6s

My preferrence for viewing an actors data is to have the actor send a message to its caller with the data you need. Then create a test to view the data from the dequeuer.

You can also create a test harness where you launch the actor using the "Launch Actor.vi" (not in the pallette) and you use "Obtain Message Queue.vi" and launch the actor with the enqueuer from "Read Enqueuer.vi" and use the "Read Dequeuer.vi" for receiving messages that are sent to the caller.

I use a "Zero Coupled" approach and I check to see if a child of the Data Message is implemented for sending the data to the caller conditionally on that being true.

Casey

[drjdpowell]

To be devil's advocate, the lack of a simple answer to "How can we probe private data of actor when running? " is a significant weakness of the Actor Framework.  Probes are one of LabVIEWs biggest strengths.  More advanced techniques may partially substitute, including things like Tests that are valuable in themselves, but they aren't the same. 

[Brainstorms]

I probe the private data of actors in AF all the time.  It's trivially easy.  So much so, I feel embarrassed at the though of even spelling it out...

And there's nothing special or sacred about AF -- this is an issue of probing the contents of any object in any LV app.  An 'actor' in AF is nothing more than an instance of a class.

Don't make it out to be more than it is.  Don't invent mystery that isn't there...

[CaseyLamers1]

Yes, I probe data too. The only catch is making sure your methods are set in a way such that probing makes sense. Shared clone or non-reentrant would mean you could be probing data from N different actors. Preallocated clone means you need to set a breakpoint and open the VI when running to see the actual instance used within the running actor.

[Brainstorms]

True... But this is "LabVIEW Debugging 101".  Nothing new, nothing special, nothing difficult.

With some additional effort, one can add snippets of code to methods of interest that will trap on particular actors/instances and breakpoint themselves on those specific cases -- which then allows quick probing.

Again, it's not really more that what a developer would do if debugging "traditional" (read: non-OOP, non-AF) LabVIEW code...

[CaseyLamers1]

I guess I am just agreeing with you that it isn't hard.

[Brainstorms]

And I guess I'm just defending LVOOP and AF against the mindset that tries to frame them as something radical and distinctly different from traditional LV dataflow programming. 

In this case, with the complaint that it can't be debugged, or that it's harder to debug, or that it requires something special or complicated or needs unfamiliar techniques to debug.

I'd like to replace that with a greater & more widespread understanding and acceptance -- by both developers and their management. 

[CaseyLamers1]

I exclusively program with AF and every new project I save tons of time reusing what I have already done.

I see debugging as being "not that difficult". I was orignally going a step further and advocating actually creating test cases for the added benefit that the testing persists and can be rerun and automated. When drjdpowell said it was a weakness of the framework I backed it down to saying there is also a very easy way. In response to it being easy you said that is Debugging 101. Maybe that was a complement...

So, in short I too am defending AF and OOP from both sides. Not hard, and as rich as you want it to be.

If there is a shortcoming I would say it is in core training material to get the developer over the initial hump.

I have been kicking around the idea of an AF book, but I am not sure I have the time to do the job I would want to do.

Casey