Jump to content

Recommended Posts

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 by smithd
Link to comment
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.

Link to comment

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 by smithd
Link to comment
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

Link to comment
  • 4 weeks later...
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")]

Link to comment

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"
}

 

 

Link to comment

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, 

  • Like 1
Link to comment
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:

Basic JSONtext.png

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 by drjdpowell
  • Like 1
Link to comment
  • 2 weeks later...
  • 4 months later...
  • 1 month later...

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:

2019-02-28_11-26-25.png.6890e17c365b411ea9658e5ea8481885.png

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

2019-02-28_11-29-08.png.4afe802bf64332d3d567969caa5c0f57.png

 

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.

Link to comment
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.  

Link to comment
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! :)

Link to comment
  • 3 weeks later...
  • 4 weeks later...

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.

 

image.png.6e9ecdb26a028eac20e6d10116db7fb8.png

 

Am I stuck up poop creek without a paddle here?

 

 

Link to comment
  • 2 weeks later...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.