Dynamic Probes for Class Data

[_carl]

Class data is painful, if not impossible, to properly probe when debugging LabVIEW code.

It doesn't need to be this way. Every other programming language I've worked with allows viewing this type of data when debugging.

Currently, by default, you only see probe data based on the wire's edit-time class definition, not it's actual runtime class instance. It would save me weeks (literally) a year if I could simply place a probe on a class wire and view the internal class data of the runtime class, including all levels of inheritance.

I realize it's not a small ask since the probe GUI would need to be dynamic (as data type/GUI elements, not just values, would need to be updated when probe is hit.)

[_carl]

To add to this -- the ability to see nested class data in a manageable(/interactive) way would be huge.  If my class data contains a class, and I'm lucky enough that the top-level class is the exact same class type as the wire that I'm probing (and not a child class), then all I can see, by default, is the icon of the class that it contains in it's data.  There's no way to explore this inner data...

[fefepeto_kb]

I think custom probes for classes would help with this problem, although it requires some manual work to be done for each class.

The custom probes are described in the help: Creating Custom Probes - NI and their use with classes here: Setting the Default Probe for a LabVIEW Class or Interface - NI.

Basically, what the idea is about, in my understanding, is that the default probes would provide all the data inside the class, with dynamic dispatching, and potentially the content of other contained classes too.

But, there are some questions from my side on this:

1. How would the probes behave when DVRs are involved?
2. What to do if, against the recommendation, a class contains a DVR to the data of its owning class, therefore the data is recursive?
3. Is it ok, to bloat the memory with a full copy of a class and all its contained classes recursively for every probe?

[_carl]

@fefepeto_kb

Custom probes would entirely defeat the purpose -- I work on projects with 100s if not 1000s of classes. Manual work for each class is out of the question. The idea is to have something integrated into LabVIEW that makes debugging these classes easier, not harder.

To answer your questions, in reverse order:

3. No, this bloat in a flat structure would not be OK, and would definitely be an issue if this was modeled after the existing probe design.  I'd envision something that allows a degree of navigation/expandability/drill down capabilities.  Either through an expanding structure (like a tree) or through popping out new windows as you drill down (similar to how the tools palette works perhaps).

2. Could be handled through the structure defined in [3]

1. DVRs would ideally expose data in a very similar way as [3], by showing the data at the moment which the display portion was expanded. (Although yes, I'm sure there are corner cases that would need to be ironed out...or, worst case, simply omitted.)

[fefepeto_kb]

I'm afraid that your idea from the 3 does not work without bloating the memory. Consider the following use case:

1. You place the probe and check the values in the top level class.
2. Continue the execution and, one of the owned class' data changes.
3. Now you open the class' data changed in point 2 in the probe you placed in point 1. The following can happen depending on whether a copy of the recursive data is stored in the memory or not:
   1. Bloated memory, all probes contain all the owned class' data too: you will see the data from the actual state where the probe was placed.
   2. Memory not bloated:
      1. Opening the owned class' data is disabled: works as now, so no change. Not desirable option.
      2. The tree item opens, but instead of the status where the probe was placed the current value is shown. Also not desirable option.

The reason for the need of memory bloat is, that LabVIEW will try to inline all the operations, and if the compiler decides that the data is inlineable, then it will be changed in the only memory location it exist.

The alternate might be to only allow accessing the owned class' data if the "Retain Wire Values" option is enabled. This option forces the development environment to keep a copy of every data on every wire that is executed in the VI where it is enabled.

My opinion is, that 2. shall behave in the following way, if supported at all:

1. Opening the child item in the tree would open normally.
2. Opening one of the owners data would take the probe display back to the original display of that object. The reason is, that LabVIEW trees get very slow above a few hundred items and with recursive data it is easy to reach those numbers.

I also know that this is far from ideal, since there might be cases when the top level owner has to be referenced from a class that is nested deeper than one or two levels.

[_carl]

@fefepeto_kb

Yes, that's exactly how probes work now too -- a snapshot of the class data (which is by value), and which includes child class data, is kept in memory by that probe.  This isn't memory bloat, this is by design (and current design, at that).

How you navigate that data is what I'd like to see changed...