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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

 

Annotation 2019-01-04 094443.jpg

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


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

Share this post


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

Share this post


Link to post
Share on other sites

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.

Share this post


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

Share this post


Link to post
Share on other sites

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.