[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.