[CR] JSONtext

[Jasmine Rodriguez-Wagner]

I ended up writing a wrapper that incorporates the read, then checks if the output Template Used = True, then uses the Write function, else, do nothing. I also added code before the read function, to check if the directory to the file location exists, and creates the directory recursively if it doesn't. 

[Scatterplot]

Is it possible to use "Set Item" recursively? For example, starting with an empty JSON string, I'd like to be able to set tell it to set a nested item, and automatically create all of the levels it needs to. Say I want the following JSON to be created from scratch:

{
  "Templates": {
    "Generic": {
      "Voltage": 14
    }
  }
}

I would've thought I could use "Set Item" with a Path of $.Templates.Generic.Voltage, but that gives error 402840, "Unable to Insert at .Templates.Generic.Voltage".

 

If I stack multiple Set Items, it works as expected- the first would set Voltage to 14, then set that to Generic, then set that to Templates.

 

The second way is a lot more cumbersome. I'm using JSON for a config file, and I'd like each module to be able to read its own settings from the config file. If it doesn't find its own settings, it uses a default value (which currently works great) but it can't make its own value without doing multiple adds. Am I doing something a dumb way? Or perhaps I'm just formatting my $Path wrong?

 

[drjdpowell]

See if "Unflatten JSONpath Array to Object" will do what you want.  It will create the extra levels if needed.

[Scatterplot]

That seemed to do it, thanks! I wrapped that up in another VIM that tries the standard way first, then if it doesn't work it uses the Unflatten function. Thought it might help someone else out.

 

Is there any reason to NOT want this behavior, by the way? I'd guess to detect badly formatted files, perhaps?

Set Item (as LVtype) multilevel.vim

[drjdpowell]

15 hours ago, Scatterplot said:

Is there any reason to NOT want this behavior, by the way? 

Not necessarily, but it is trickier than it looks because of those "multipoint paths" that unflatten does not support.  A path like $.a.[new,old].b[4].c.d, for example.  If all paths were straightforward like $.a.b.c.d then it would be easy.

Although I use JSON for configuration, I'm not using it in the same way you are doing, so it hasn't motivated me to solve this issue. Sorry.

[Scatterplot]

No apologies necessary, this tool is absolutely wonderful and I have no right to demand anything

 

I hadn't used the multipoint path functionality before and wasn't actually aware it existed. Mind if I ask how you're handling config file initialization? My go-to behavior has been for the "reader" code to check for a valid entry, and if it's not found, use a hard-coded default value (either a "good guess" or a sentinel such as NaN) and write it to the config file. When the user modifies it, the config file gets updated with the correct value.

Do you either hand create or have another program to initialize the config files? How do you handle "entry not found" errors? I'm always open to other approaches, and if this hasn't come up with any other users since this tool was published then I'm guessing I'm the oddball here.

[Zyl]

Hi @drjdpowell!

Thank you very much for your powerful lib !

We actually encounter a small problem with it. We do a lot of TestStand development, and therefore we create PPL for our code modules.
The fact is JSONText lvlib contains lots of VIs where there is code in Disable Structures. When a Disable Structure contains a VI (like Treatment of NaN and Inf.vi) and you build a PPL, the PPL list the VI as a dependency but doesn't embed it (whatever the flags we use).

The only way to make the PPL sucessful when it calls JSONText lvlib files is to completely remove the Condition Structures.

Do you think it would be possible to release a version without 'dead code' into it?

Cyril Gambini (aka CyGa, LV Champion, CLA, CTA).

[X___]

[Bug Report/Feature Request]

The following diagram is self-explanatory:

It returns an error 402843:

JSONtext.lvlib:Scalar JSON text to Variant (not inlined).vi:5750001<ERR>
Unhandled Type: "Double Complex"

At least it does return an error. When the complex numbers are within an array inside a cluster, the corresponding data is ignored and the default (empty array) is returned instead without any error.

Note that the To JSON text.vim doesn't complain and outputs the expected "1 +2 i" string.

 

Edited December 20, 2023 by X___
added information

[daenglis]

How does JSONtext handle null strings? Like

{"User":null}

Apologies if this has been answered. I searched but couldn't find it.

[Phillip Brooks]

15 hours ago, daenglis said:

How does JSONtext handle null strings? Like

{"User":null}

Apologies if this has been answered. I searched but couldn't find it.

 

[X___]

On 12/20/2023 at 2:30 PM, X___ said:

[Bug Report/Feature Request]

The following diagram is self-explanatory:

It returns an error 402843:

JSONtext.lvlib:Scalar JSON text to Variant (not inlined).vi:5750001<ERR>
Unhandled Type: "Double Complex"

At least it does return an error. When the complex numbers are within an array inside a cluster, the corresponding data is ignored and the default (empty array) is returned instead without any error.

Note that the To JSON text.vim doesn't complain and outputs the expected "1 +2 i" string.

 

Raised here: https://bitbucket.org/drjdpowell/jsontext/issues/103/what-to-do-about-complex-numbers

[drjdpowell]

On 12/21/2023 at 10:45 PM, daenglis said:

How does JSONtext handle null strings?

Can you give a more specific question?

[drjdpowell]

15 hours ago, X___ said:

Raised here: https://bitbucket.org/drjdpowell/jsontext/issues/103/what-to-do-about-complex-numbers

I will fix the inconsistance, either by making comlex numbers full not supported or fully supported. 

[X___]

11 hours ago, drjdpowell said:

I will fix the inconsistance, either by making comlex numbers full not supported or fully supported. 

I have given up on using complex numbers in JSONtext after discovering this problem, so I am fine with either way but if there was a way to throw an error for unsupported types, this could prevent people like me from building on sand (of course I should have more testing of my code, but I am a one man orchestra, so that is not always an option).

 

Note: the last point appears somewhat related to this issue:

https://bitbucket.org/drjdpowell/jsontext/issues/108/from-json-textvim-does-not-return-an-error

Edited December 23, 2023 by X___
added note

[Peter Grant]

Hi James,

I use JSONText lots in a large project, that uses classes as its main data type being converted to/from JSON using the serializer class very successfully.

Do you see an update on the horizon to move the Serializer class to an interface, and then its just a case of ensuring the class we want to convert inherits from this interface as well, rather than having to make a separate Serializer class to manage the conversions? 

Cheers, and thanks again for a great tool.

Peter

[drjdpowell]

Yes, at some point I intend to make an interface that has "to JSON" and "from JSON" methods, that one can inherit from.  But at the moment JSONtext is based in LabVIEW 2017.

[Peter Grant]

11 hours ago, drjdpowell said:

Yes, at some point I intend to make an interface that has "to JSON" and "from JSON" methods, that one can inherit from.  But at the moment JSONtext is based in LabVIEW 2017.

Excellent, I look forward to it.

[luissimm]

Hello guys, I dont know if this was already reported as an issue or not, but I found some curious behavior when using the JSON text library. If I use it to convert a cluster, the order of the data is kinda shuffled in the json string, but when rebuilding the original cluster, the information is correct. I use the json string as a "human readable" part and it was confusing me. I've tried to fix this but some subvis from the library are password protected (and I understand that). JFYI, I've replaced the deprecated VIs as it was recommended and the behavior still the same.

Please find attached the difference between two different convertion tools.

It doesn't matter if I use the pretty or raw data, both cases present the same shuffled data.

Any suggestions?

[Phillip Brooks]

34 minutes ago, luissimm said:

Hello guys, I dont know if this was already reported as an issue or not, but I found some curious behavior when using the JSON text library. If I use it to convert a cluster, the order of the data is kinda shuffled in the json string, but when rebuilding the original cluster, the information is correct. I use the json string as a "human readable" part and it was confusing me. I've tried to fix this but some subvis from the library are password protected (and I understand that). JFYI, I've replaced the deprecated VIs as it was recommended and the behavior still the same.

Please find attached the difference between two different convertion tools.

It doesn't matter if I use the pretty or raw data, both cases present the same shuffled data.

Any suggestions?

 

 

You seem to be using the JSON API Library from the LAVA group. This forum is for the JSONtext library by JDP Science.

To answer your question, the pretty JSON function you used internally stores the item names in a variant attribute. When the function calls Get Variant Attribute, an array of keys is returned with the names sorted.

LabVIEW does this, not the writers of the libary.

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/functions/get-variant-attribute.html

[luissimm]

20 hours ago, Phillip Brooks said:

You seem to be using the JSON API Library from the LAVA group. This forum is for the JSONtext library by JDP Science.

To answer your question, the pretty JSON function you used internally stores the item names in a variant attribute. When the function calls Get Variant Attribute, an array of keys is returned with the names sorted.

LabVIEW does this, not the writers of the libary.

https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/functions/get-variant-attribute.html

I see my mistake regarding the libraries, I'm sorry about that and yes, you are correct, thank you for letting me know and for the quick response.

I understood what labview is doing and I'll try this library by JDP Science

 

[Jens S.]

Hey!

I'm working with WAMP right now and need to flatten/ unflatten a lot of data into JSON arrays and/or objects. With named objects or arrays of named objects everthing is fine. But I have to deal with a lot of arrays like this one (a rather small and simple one)

[13, [1], "7c3c6113-9d26-4354-8e6d-412597b96f0c", false]

Right now I do something like this:

Is there a better solution to unflatten these arrays into LabVIEW data structures? I would love to use a typedef for unflattening my data but I could not find a better solution.

[Phillip Brooks]

3 hours ago, Jens S. said:

Is there a better solution to unflatten these arrays into LabVIEW data structures? I would love to use a typedef for unflattening my data but I could not find a better solution.

Create a cluster prototype of the data and use the 'From JSON Text' function.

[Jens S.]

I knew there was a simpler solution. I don't know what I did wrong, but I felt like I had tried exactly that and it didn't work. Thanks for the quick reply.

[Vortexhunter]

This is a simplification of one of the JSONs I am parsing, I am baffled by this, not sure if I am missing something obvious?

[Antoine Chalons]

23.1 is between double quotes, which make it a string, not a numerical.
if you remove the double quotes, then is will be a numerical value.

hope this helps

Edited October 3 by Antoine Chalons
add image