Jump to content
News about the LabVIEW Wiki! Read more... ×

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

First of all: :worshippy: 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. 

 

Share this post


Link to post
Share on other sites
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")]

Share this post


Link to post
Share on other sites

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

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

Hello drdpowell,

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

best regards

Thomas

MissingVI.png

Edited by RedBeard

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

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