[CR] JSONtext

[smithd]

On 3/9/2018 at 0:19 AM, silmaril said:

I think we should add a convention for line comments: They should only be allowed outside of strings, otherwise we could destroy perfectly valid string values or object names. I would also define that the marker must be preceded by some kind of whitespace (space, tab, CR, LF) or be at the beginning of the file.

 

Dunno if this came up elsewhere, but I just stumbled across this:
https://json5.org

Its a "standard" only so far as "some person put something on github", but it might be nice to adjust the parser half* to accept it, if that fits your use cases -- the changes seem pretty simple and logical. I do hand-write some of my config files, but most of the time I just write a "make me some configs.vi" function and leave it at that. Just thought I'd share.

*ie "be conservative in what you do, be liberal in what you accept from others"

Edited July 17, 2018 by smithd

[silmaril]

On 17.7.2018 at 4:11 AM, smithd said:

Dunno if this came up elsewhere, but I just stumbled across this:
https://json5.org

Its a "standard" only so far as "some person put something on github", but it might be nice to adjust the parser half* to accept it, if that fits your use cases -- the changes seem pretty simple and logical. I do hand-write some of my config files, but most of the time I just write a "make me some configs.vi" function and leave it at that. Just thought I'd share.

*ie "be conservative in what you do, be liberal in what you accept from others"

This looks great!

Not just the comment feature - I think this is even more important: Numbers may be IEEE 754 positive infinity, negative infinity, and NaN.

This is something I am really missing in JSON when working with LabVIEW floating point numbers.

[drjdpowell]

On 18/07/2018 at 7:51 AM, silmaril said:

Numbers may be IEEE 754 positive infinity, negative infinity, and NaN.

That extension to JSON is part of the LabVIEW JSON primitives, and JSONtext supports that.

[smithd]

I see that they made the same choice NI did on that as well...limited to "+Infinity" and "-Infinity" -- it would be nice if it were more accepting (eg "Inf", "-Inf", "+infinity")...same thing with booleans. If I type something manually I always forget if its "true" or "True", and I often forget that it matters. Probably silly to do so, but I eventually just edited jsontext in a branch to support the different cases.

Of course I admit you do eventually reach Yaml-level of parsing difficulties:

y|Y|yes|Yes|YES|n|N|no|No|NO
|true|True|TRUE|false|False|FALSE
|on|On|ON|off|Off|OFF

 

Edited July 20, 2018 by smithd

[ShaunR]

7 hours ago, smithd said:

Of course I admit you do eventually reach Yaml-level of parsing difficulties:

y|Y|yes|Yes|YES|n|N|no|No|NO
|true|True|TRUE|false|False|FALSE
|on|On|ON|off|Off|OFF

 

Just coerce to lower (or upper) case then it's just y|n|yes|no|true|false|on|off|0|1

[Porter]

First of all:  Thanks for sharing!

Do you plan to implement array slice syntax at some point?

For example, $.MyArray[5:20] would return elements 5 to 20 of MyArray. 

 

[drjdpowell]

5 hours ago, Porter said:

Do you plan to implement array slice syntax at some point?

For example, $.MyArray[5:20] would return elements 5 to 20 of MyArray. 

At some point, but it joins a long list of other things it would be nice to have.  I'd like JSONpath filtering, like $.MyArray[?(@.type="MyType")]

[_Mike_]

Is there a possibility in your library to get a sub element as json formatted string. I mean to get from json string:

{
"field1": 1,
"field2": {
    "item1":"ss",
    "item2":"dd"}
}

the item field2, and expect it will return a string containing:

{
    "item1":"ss",
    "item2":"dd"
}

 

 

[smithd]

if I understand you correctly you want to name the field in your cluster <JSON>field2. That is you start with a cluster on your block diagram:

{field1:dbl=1.0,<JSON>field2:string="{"item1":"ss", "item2":"dd"}"}

When you call flatten to json you get:

" {
"field1": 1,
"field2": {
    "item1":"ss",
    "item2":"dd"}
} "

because the library automatically pulls off the <JSON> prefix and interprets that whole string as JSON.

When you unflatten the reverse happens, 

[drjdpowell]

5 hours ago, _Mike_ said:

Is there a possibility in your library to get a sub element as json formatted string.

Yes, that's the basic JSONtext use case: working with JSON:

Working to/from LabVIEW data types is also a use case, and there is the (more complicated) ability to intermix JSON and LabVIEW Types in clusters using the <JSON>-tag method smithd describes, but a basic motivation of JSONtext is to be able to work simply with JSON-formatted strings directly.  

Edited August 17, 2018 by drjdpowell

[RedBeard]

Hello drdpowell,

the lvlib is missing the vi "INI to JSON Test.vi". Is it possible to fix the package?

best regards

Thomas

Edited August 28, 2018 by RedBeard

[PBD_ctrl]

Why is "Get all Object Item Offsets.vi" in JSON Text marked as private scope?  Any chance you can add it to the API?  I really need the functionality and don't want to hack my install. 🤔

[drjdpowell]

Can you explain your use case, and why the public API is inadequate for it?

[e_schneider]

Hi, I think a found a bug (JSONtext-1.2.11.78). The pretty print for 2D-DBL-Array is not working correctly. There is a wrong wire connection in "Variant to JSON Text.vi", see screenshot.

best regards

Elmar

 

[drjdpowell]

Thanks Elmar. Issue 27.

[Sam_Sharp]

Hi,

Is anyone aware of any LabVIEW 2018 stability issues when using this library? I am working with a couple of projects and am getting hard LabVIEW crashes when running my application in the development environment and also executables that hard-crash when launched. A mass compile seems to resolve the IDE crashes temporarily but it can sometimes take reboots/LV restarts/mass-compiles to get the executable to run when built. Issue is present in LV2018, f2 and 2018 SP1 with versions 1.2.11.78 and 1.2.13.82 of the library.

I'm pretty sure it's this library since that's the common denominator between the projects (3 projects..one PC GUI, one RT and a project from a separate developer where the only common library is this and a DAQmx configuration library based on JSONtext) and I have a suspicion it's because of the Malleable VIs?

Also, I have noticed a couple of bugs:

1) Pretty print misses a line-feed (I think when merging objects but there is no pretty print input on the merge) and this isn't picked up/fixed with the 'reformat' VI:

2) From JSON with a 2D array errors if the array is empty:

 

Overall, I think this is a really nice library with lots of flexibility for manipulating the JSON - I use to use the MGI/OpenG read/write anything for configuration but I'll be using this more in future for configuration. We're using it here for storing application and DAQmx configuration information and also as the framing for TCP/IP communications between the Target/Host.

[drjdpowell]

Are you using 2018SP1f1?   This sounds like the horrible compile bug present in 2018 before SP1f1 that tended to hit VIMs heavily (CAR 715018).  The f1 patch fixed this.

[drjdpowell]

6 hours ago, Sam_Sharp said:

Pretty print misses a line-feed

Pretty Print is designed to keep small objects compact.   Anything less than 40 characters.  I think it's more readable, especially for arrays of small clusters.

[drjdpowell]

7 hours ago, Sam_Sharp said:

2) From JSON with a 2D array errors if the array is empty:

That's inherited from the NI JSON function, which I used for fast array parsing.   I may have to spend the effort to develop and alternate solution, or develope better guards for corner cases..  There are a lot of edge cases mapping LabVIEW's strict types to JSON.  

[drjdpowell]

BTW, the VIMs in JSONtext are all simple wrappers to make the API easier; you can use the Variant conversion functions available under the "more" menu to avoid all VIMs if needed.

[Sam_Sharp]

On 2/28/2019 at 6:30 PM, drjdpowell said:

Pretty Print is designed to keep small objects compact.   Anything less than 40 characters.  I think it's more readable, especially for arrays of small clusters.

Ah ok - that makes sense.

On 2/28/2019 at 6:26 PM, drjdpowell said:

Are you using 2018SP1f1?   This sounds like the horrible compile bug present in 2018 before SP1f1 that tended to hit VIMs heavily (CAR 715018).  The f1 patch fixed this.

No - 2018 f2 but I'm updating now so I will see if that fixes it. I did already go through and replace all of the JSONtext VIMs but I'm using other VIMs anyway so will see if that helps.

On 2/28/2019 at 7:25 PM, drjdpowell said:

That's inherited from the NI JSON function, which I used for fast array parsing.   I may have to spend the effort to develop and alternate solution, or develope better guards for corner cases..  There are a lot of edge cases mapping LabVIEW's strict types to JSON.  

Yeah, I definitely think that throwing an error for an empty 2D array is unexpected behaviour so it would be nice if I didn't have to work around it.

Thanks for the responses! :)

[drjdpowell]

 

Yeah, I definitely think that throwing an error for an empty 2D array is unexpected behaviour so it would be nice if I didn't have to work around it.

Please try the new 1.3.0 version in the LAVA-CR.

[kull3rk3ks]

Does anyone have issues with blocking calls when used in parallel processes?

I would like to deserialize data in multiple parallel processes, but the "from JSON Text", that in turn calls the "JSON text to Variant" function which uses the NI utilities for determining variant data types.

These are set as non-reentrant and as they are protected, there is no way to change that.

 

 

Am I stuck up poop creek without a paddle here?

 

 

[smithd]

i think those variant functions should be a tiny meaningless fraction of the overall execution time. Have you profiled it?

[RogerSaele]

There is no support for fixed-point numbers.