OpenG and Object compatibility

[bjustice]

I did a deep dive into JSONtext, JKIJSON, and into EasyXML.
I made a few interesting observations after doing a bunch of work to integrate object serialization into a branch of these libraries.
Basically, beware usage of OpenG LabVIEW Data Palette SubVIs when working with LabVIEW objects

 

1) The OpenG TD doesn't include "LabVIEW Class Instance" (or any of the new datatypes either... maps, sets)

 

2) In the following code, note how the top method produces an error, but the bottom method is fine:

 

3) In the following code, note how the top method produces an error, but the bottom method is fine:

[bjustice]

I now understand why James made this SubVI for his JSONtext library.
I hope that he built this thing with scripting.  Brute force, but seems to work well.

[bjustice]

At an absolute minimum, would there be any interest here in releasing a new update for the OpenG LabVIEW Data VIPM package to include the following datatypes in the OpenG TD?:

• LabVIEW Class instance
• Map
• Set

It seems like this would be an easy and backwards compatible update.
I make this request because legacy code such as EasyXML heavily leverage the OpenG TD.  It would be minor hassle to replace this with the native LV TD.

[Jim Kring]

Ha!

[Jim Kring]

Hi Brent,

I can work with you on this improvement. Yes, it's needed and past due.

I'll ping you off-line.

-Jim

[bjustice]

Relevant test in LabVIEW 2019 SP1.
It looks like the Lo(x) of index:1 is no longer enough information to discern between a refnum and a LabVIEW Class Instance.  I need to figure out how to properly differentiate between Refnum and LabVIEW Class Instance

[Jim Kring]

Does this help?

[Jim Kring]

[bjustice]

yepp, I also found this:

https://labviewwiki.org/wiki/Refnum_descriptor

[Jim Kring]

Hmmm, 0x1E seems to not be listed in that wiki page either. Might be good to ping NI or @Aristos Queue about this.

[bjustice]

Ok, so, now knowing this information, it seems like the following needs to happen:

• Add the following to: "Type Descriptor Enumeration__ogtk.ctl"
  • "Fixed Point"
  • "Map Collection"
  • "Set Collection"
• Add the following to: "Refnum Subtype Enum__ogtk.ctl"
  • "LabVIEW Class Instance"
• Update the holy LabVIEW wiki

It's interesting to learn here that we can't 1:1 match "Type Descriptor Enumeration__ogtk.ctl" to "NI_Data Type.lvlib:Data Type.ctl" since these are inherently different

[Jim Kring]

Right, the NI Data Type abstracted away the type descriptor type codes and subtype codes.

Also, this is the original application note 154 on the topic.

[bjustice]

Well, I just encountered a weird issue with the Fixed Point data type.
Here is code in LabVIEW 2019 SP1 32-bit:

Here is code in LabVIEW 2009 SP1 32-bit:

I'm not immediately sure what to make of this

[bjustice]

Not sure if this is relevant, but here is LabVIEW 2019 SP1:

Here is LabVIEW 2009 SP1:

The hi(x) byte is marked as "Private" within OpenG, but it seems suspicious to me ^

[bjustice]

Per: https://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/

Quote

The first word (16 bits) in any type descriptor is the length, in bytes, of that type descriptor, including the length word. The second word (16 bits) is the type code. LabVIEW reserves the high-order byte of the type code (the xx in the following tables) for internal use. When comparing two type descriptors for equality, you should ignore this byte.

I wonder if the fixed point was in some sort of weird BETA state in LV 2009

[Jim Kring]

I just looked at some statistics and I think it's safe for us to upgrade this library to LV2013.

 

Can you try re-running your fixed point experiment in 2013.

[bjustice]

Interesting, "Only used internal to LabVIEW" was a conscious decision within the OpenG toolkit.

Any notion why this was the case?  Is it time to reverse this decision?

[bjustice]

3 minutes ago, Jim Kring said:

I just looked at some statistics and I think it's safe for us to upgrade this library to LV2013.

 

Can you try re-running your fixed point experiment in 2013.

sure thing, in work

[Jim Kring]

2 minutes ago, bjustice said:

Interesting, "Only used internal to LabVIEW" was a conscious decision within the OpenG toolkit.

Any notion why this was the case?  Is it time to reverse this decision?

Hmmm... that was a long time ago   I'm not totally sure what the thinking was.

I don't see any problem renaming the enum value to "ByVal Class" (or similar).

[bjustice]

I was going to use "LabVIEW Class Instance" in an effort to somewhat standardize with the modern NI datatype palette:

[bjustice]

LabVIEW 2013 SP1 32-bit yields proper behavior for fixed point:

Just to confirm, do we want to continue to build this OpenG VIPM package for LabVIEW >= 2009, or upgrade to LabVIEW >= 2013?

[Jim Kring]

1 hour ago, bjustice said:

I was going to use "LabVIEW Class Instance" in an effort to somewhat standardize with the modern NI datatype palette:

 

Sounds good.

 

38 minutes ago, bjustice said:

LabVIEW 2013 SP1 32-bit yields proper behavior for fixed point:

Just to confirm, do we want to continue to build this OpenG VIPM package for LabVIEW >= 2009, or upgrade to LabVIEW >= 2013?

 

Yes, we'll upgrade the sources to LV2013 (and separate compiled code on all VIs).

Let's do this, first, as a single, separate commit to git.

Then, we can make the other changes.

[LogMAN]

If you are interested in object (de-)composition, I have a library that does most of the heavy-lifting (extracting private data and putting it back together), including functions to work with clusters of any size and shape. I can save it back to LV2017 and post here.

[bjustice]

I would certainly be interested in taking a look.

Internally, we made the early decision that we didn't want to directly access class private data through string flattening or by inspecting the class' *.ctl file.  We felt that this violated the covenant that class data should only be accessed through data accessors.  As such, we moved towards a Project Provider plugin framework that scripts accessing of class private to work with our serialization engine.

[bjustice]

While researching this, I discovered 2 other projects that solved serialization of objects using (de-)composition of private data using the flatten to string and TypeDescriptors:

JSONtext branch with object support:
https://bitbucket.org/logmanoriginal/jsontext/src/lvobjectserialization/

paid 3rd party library "JSON Object Serialization by GCraftsman":
http://sine.ni.com/nips/cds/view/p/lang/en/nid/215788