bjustice

Now is the time to do it, TOML just released a v1.0 spec. I, for one, would buy you a beer at NI week

Yep! TOML is like INI file syntax learning how to do everything that JSON can do... with comments. I'm a fan. I've also been using the Erdosmiller library. I've found a few bugs, it's not full-feature, and it's not TOML 1.0 compliant. (TOML just 1.0'd recently). It's the best I've found thus far though, and it's been working well enough for me.

Correct, they don't sell licenses anymore. Just trying to be helpful and provide another datapoint. I'm in the same boat at the moment - looking for a good Python/LabVIEW integration solution, but there doesn't seem to be anything that has been able to eclipse the capabilities of the Enthought toolkit.

I've been a big advocate for the Enthought Python integration toolkit in the past. Unfortunately, the product was discontinued when LabVIEW introduced the native python node. I'm still scraping by on this product as I've not found a good alternative, and the built-in LabVIEW python node doesn't meet my needs. Under the hood, the Enthought product was just a TCP link to Enthought's flavor of python called Canopy... which has also been discontinued. This product was fantastic for a few reasons: Canopy environment could be packaged into a lightweight Python runtime engine, which can be zipped up and passed around with LabVIEW executables. Made it easy to deploy the code to many machines. 32/64 bit LabVIEW compatible fast read/write of large data to/from Python Relevant link: https://support.enthought.com/hc/en-us/articles/360035630192-Toolkit-End-of-Life-Porting-to-LabVIEW-s-native-Python-support I recognize that this probably isn't helpful... but a datapoint

Ahh, I did not realize that they were located there. Thanks!

Thanks, great thread! Does anyone know how I might be able to get ahold of, or export all of these cool symbols as BMP files? It looks like all of the extended symbols in the special MCL are stored as "built-in symbols" for the MCL. As such, I can't seem to export them using the method: Custom Item Symbols:Get Symbol. (This method returns an empty data array.)

Kudos, this is very cool

Ha! I now feel silly for responding to your first post with a link back to your own JSONtext branch. Did you encapsulate your object (de)composition into a reuse library of sorts? Or is it pretty entangled in your JSONtext branch? I read through your code and did indeed find that wiki page. Very cool stuff. There are certainly large benefits to doing it the way that you did things in your JSONtext branch. You don't have to inherit from a base class, so all classes become inherently serializable. And there is no need for scripting or creation of data member accessors to allow for the library to do its job. Yeah, we noticed some pretty big limitations to the "Flatten to XML" primitive as well. This tends to leave out fields in the output XML if they are default value in the object.

Thanks JDP for the background information. I just kudo'd your idea.

Our code supports nested and arrays of classes that inherit from the base "Serializable.lvclass" gracefully. Classes are represented as a nested cluster in the serializable string (JSON, XML, TOML) Objects that don't inherit from the base "Serializable.lvclass" are treated in the same manner as JSONtext handles objects... flatten/unflatten from string. If error on unflatten, then return default object

We adopted the notion that classes must inherit from a base "serializable.lvclass". This activates the Project Provider plugin (project tree scripting methods). We didn't see a convenient way around this, and we didn't see this as too much of an inconvenience. Where we noticeably diverged from AQ Char Lineator is that we (through scripting) create a "SerializableData" cluster typedef that gets dropped into the class private data. Only data within this cluster is consumed by the serialization framework. all other data is ignored. This simplified things in that we only need a single future-proof data read/write accessor for this cluster. A user can update serializable data by only editing this typedef... they don't have to touch any VI source code. Pros and cons to this solution.

Yes! Did a deep dive through that code as well. We're taking a similar approach

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

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.

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?

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

sure thing, in work

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?

Per: https://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/type_descriptors/ I wonder if the fixed point was in some sort of weird BETA state in LV 2009

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 ^

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

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

yepp, I also found this: https://labviewwiki.org/wiki/Refnum_descriptor

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

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.