Jump to content

Recommended Posts

That is an interesting idea... I would imagine that being able to work in place could definitely offer better performance for large / nested JSON objects.

 

 

From the poking around I did, the sorting that takes place is an implicit sort when adding the JSON elements as variant attributes to a containing element. They end up getting stored alphabetically (in the variant attribute tree) so when "Get all attributes" is done in the "flattening to JSON string" VI, the objects come out in alphabetical order. The workaround I threw together kept a list of names so that instead of "get all attributes" a "foreach name, get attribute" was done (which preserved original order).

 

So can we not prepend an index to the name in the variant attribute list to enforce a sort order and strip it off when we retrieve?

(I really should download it and take a proper look, but having to find and install all the OpenG stuff first is putting me off...lol)

Edited by ShaunR
Link to post
Share on other sites
  • Replies 240
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

The easiest way by far is to use the [un]Flatten to XML primitives, which can take objects and variants as arguments, and convert the XML to/from JSON. with simple regex/search/replace. Why they didn'

View File JSON LabVIEW JSON is a data interchange format (sometimes compared to XML, but simpler). There are multiple projects to create a JSON package for LabVIEW. T

I tried to use this tool. And it looks great, however the function 'Variant to JSON' fails with a variant inside an object. I made the following changes: -Added support for Variant. By using 'Unwrap

Posted Images

Hi Guys,

 

A couple of issues to look at. I'm happy to look at myself if you want them in.

 

1. Can we rename GET (polymorphic) and SET (polymorphic) to JSON GET (polymorphic) and JSON SET (polymorphic), it would make them easier in quick drop.

2. One I came across today is that there isn't currently support for escaping strings. I remember there is something in the VI.lib extras library for it.

EDIT: Just seen reference to this in the commit history for 1.3, will check this first.

 

Cheers,

James

Edited by JamesMc86
Link to post
Share on other sites

I believe Quick Drop uses the VI Title, rather than Name, so we can easily change the titles without causing any other issues.

 

String values are escaped; however I realized recently that the name strings in JSON Objects aren’t escaped.  That’s on my list of changes to make when I have the time.  

 

—James

 

PS> since we are listing issues that need to be addressed, the parsing fails on empty subObjects, such a {subObj:{},â€OtherItemâ€:1}

Link to post
Share on other sites
  • 1 month later...

The latest JSON package, where I have fixes some issues with corner cases, mostly by changing the string escaping (failed on strings like “C:\\“).  Also extended escaping to the name strings of JSON Objects (which we had neglected to do).   I will make this the latest CR version in a week or so if there is no objection.

lava_lib_json_api-1.3.1.25.vip

Link to post
Share on other sites

Hi,

 

Thanks for the update. The escaping problem turns out to be mine!

 

I've been trying to compare output with that of the JSON library in Node.js. It actually only escapes the bare minimum which does not include / despite there being an escape character, so both are valid JSON, just not comparable.

Link to post
Share on other sites

 It actually only escapes the bare minimum which does not include / despite there being an escape character, so both are valid JSON, just not comparable.

I had never noticed that JSON allows, but does not require, / to be escaped as \/.   Googling suggests this is due to some use of JSON embedded in other formats such as HTML that do use / as a control character.  I believe our library as it stands should accept both versions.   But what should it do on output?

Link to post
Share on other sites

The argument I have seen for not escaping them is because escaping increases the size of the data, in this case necessarily.

 

From my point of view either could work, it just meant I had to change my code and do it properly instead of cheating!

Link to post
Share on other sites

I had never noticed that JSON allows, but does not require, / to be escaped as \/.   Googling suggests this is due to some use of JSON embedded in other formats such as HTML that do use / as a control character.  I believe our library as it stands should accept both versions.   But what should it do on output?

Accepting both and outputting the spec-conformant version seems like the right thing to do, especially if that version is smaller and can be modified by the application to add escaping for that character as needed.

Link to post
Share on other sites

I’ve modified the code to only escape ‘/' if it follows ‘<‘ (so  â€˜</‘ becomes ‘<\/‘), as it’s use in HTML <script>..</script> seems to be the reason that escaping of ‘/‘ is allowed in JSON.

Link to post
Share on other sites
  • 4 months later...

Hmmm. Marked as broken?

 

If i hadn't stumbled into the code repository area by mistake, I wouldn't have known. I wonder when that was reported?

 

P.S

Can we change the spelling of my name in the VI package description? (just noticed)

Edited by ShaunR
Link to post
Share on other sites

It says it was reported on Jan 26 2015.  I am looking into a way to get that notice removed.  I feel it is the kind of complaint that should be discussed before considering a submission broken.  Until then here is what the user complained about.

 

 

 

This file has been reported as broken because: I have started using this JSON tookit, It works really good when input JSON data size is less.

Having issues when i give a JSON data size >60K to "from JSON vi".

On Windows Environment#
After it runs, LabVIEW becomes unresponsive for quite some.

On NI LabVIEW RT(PharLap)#
Actually i used to call the attached vi as one of the subvi from Main VI. Once the application terminate in RT, CPU utilization in RT(PXI) goes upto ~90% communication betwen RT and host becomes unresponsive quite some time and comes back to normal.

I feel there seems to be an issue in memory free after the big data is parsed, please let me know if what needs to be done on this...

I dont know how to attach my code in this report, I would like to share the input data to "from JSON.vi"

Thanks & Regards,
Venkatesh.C.S
Link to post
Share on other sites

I got a PM from the user, Venkatesh.C.S,  and we found that the issue was only on LabVIEW 2014.   No problem on 2013.  I'm not working with 2014 yet so I haven’t followed up. Venkatesh consulted NI tech support, I think, but they hadn’t yet responded.

Link to post
Share on other sites

I got a PM from the user, Venkatesh.C.S,  and we found that the issue was only on LabVIEW 2014.   No problem on 2013.  I'm not working with 2014 yet so I haven’t followed up. Venkatesh consulted NI tech support, I think, but they hadn’t yet responded.

I don't have a Pharlap target, so I won't be able to investigate. However. If I had to guess at a starting point; I would be looking at the variant  type library since it uses UI (orange) calls to LabVIEW.

Link to post
Share on other sites
  • 8 months later...

Any chance of adding support for Inf and NaN to this API? I want to move off of the native LV prims because of their rigidity with data type and missing items in a JSON stream, but I can't let go of their support for these DBL values. Maybe you can add a property node to the JSON Value class that sets whether or not to allow these values in numeric fields?

 

Edit: Let me clarify, since playing with the API further shows that there is some support for those values. When I try this code on a stream that doesn't have the "updated period " field in its clusters, I don't get NaN out. I get the default value for the data type, instead.

 

O0634lT.png

Edited by Stobber
Link to post
Share on other sites

Any chance of adding support for Inf and NaN to this API? I want to move off of the native LV prims because of their rigidity with data type and missing items in a JSON stream, but I can't let go of their support for these DBL values. Maybe you can add a property node to the JSON Value class that sets whether or not to allow these values in numeric fields?

 

Edit: Let me clarify, since playing with the API further shows that there is some support for those values. When I try this code on a stream that doesn't have the "updated period " field in its clusters, I don't get NaN out. I get the default value for the data type, instead.

 

O0634lT.png

 

It was discussed in the past. The problem is that the JSON spec forbids it specifically.

Link to post
Share on other sites

And that's that, huh? No interest in making it interoperable with the LV API by "supporting LV's extensions to JSON"?

 

Not at all. Just saying it's been discussed before and there was no consensus. People were more worried about NULL :P

Edited by ShaunR
Link to post
Share on other sites

Is consensus among the original authors needed to act, or is there a public repo I can fork to add the feature?

 

Got for it :D

 

Hmm.

The version in the CR is later than in the repository. Maybe drjdpowell is building off of his own branch?

Edited by ShaunR
Link to post
Share on other sites

Any chance of adding support for Inf and NaN to this API? I want to move off of the native LV prims because of their rigidity with data type and missing items in a JSON stream, but I can't let go of their support for these DBL values. Maybe you can add a property node to the JSON Value class that sets whether or not to allow these values in numeric fields?

It looks easy enough to add a Boolean to enable use of NaN, Infinity, -Infinity.   It will have to be default False, though, as the default should be to meet the JSON standard.  I would like to see this myself, as I use JSON mostly LabVIEW-to-LabVIEW.   Maybe this should be an enum instead of a boolean, in case we want an alternate extension in the future?

Edit: Let me clarify, since playing with the API further shows that there is some support for those values. When I try this code on a stream that doesn't have the "updated period " field in its clusters, I don't get NaN out. I get the default value for the data type, instead.

 

O0634lT.png

 

Not sure we can get default values of clusters in arrays (also, which array element should be used?  First? Same Index?).   As a work around, you can just index over the JSON Array elements in a FOR loop and convert each to a Cluster individually.  Then you can either provide the same cluster as default, or have an array of different default clusters.

Link to post
Share on other sites

It looks easy enough to add a Boolean to enable use of NaN, Infinity, -Infinity.   It will have to be default False, though, as the default should be to meet the JSON standard.  I would like to see this myself, as I use JSON mostly LabVIEW-to-LabVIEW.   Maybe this should be an enum instead of a boolean, in case we want an alternate extension in the future?

FWIW, I'd stick to the Boolean. There's no reason to assume any other extensions would need to be mutually exclusive from the LV numeric extensions. An enum would enforce that exclusion.

 

 

Not sure we can get default values of clusters in arrays (also, which array element should be used?  First? Same Index?).   As a work around, you can just index over the JSON Array elements in a FOR loop and convert each to a Cluster individually.  Then you can either provide the same cluster as default, or have an array of different default clusters.

Same index, of course. I'm specifying the default value of the aggregated data structure. If I want all elements to have the same default values, then I'll either need an interface that lets me specify the element type of the array (instead of the array), or I'll have to use the "Initialize Array" prim.

Link to post
Share on other sites

 There's no reason to assume any other extensions would need to be mutually exclusive from the LV numeric extensions. An enum would enforce that exclusion.

I mean alternate treatments of Inf, -Inf, and NaN.  I can think of alternatives that are arguably better than the choice made in the LabVIEW primitive.  Personally, I would choose NaN==Null, Inf/-Inf==“Infinityâ€/“-Infinity†(strings), as this would be valid JSON.  The LAVA JSON package should already be able to read this (I think).   Regardless, other JSON packages that we may want to interact with may have made other choices.

Link to post
Share on other sites

Here is a Beta version with a new “Treatment of Infinity/NaN†terminal on the JSON write functions.

Three options:

-- Default JSON: write all as nulls.
-- Extended: use JSON strings for Infinities ("Infinity", "-Infinity"); NaN still null.
-- LabVIEW extentions (compatable with the LabVIEW JSON primatives): Infinity, -Infinity, NaN (not in quotes)

Note that the LabVIEW extentions are not valid JSON.  The Extended option IS valid JSON, but not all JSON parsers will process strings as numeric values.

 

lava_lib_json_api-1.4.0.28.vip

  • Like 1
Link to post
Share on other sites

Here is a Beta version with a new “Treatment of Infinity/NaN†terminal on the JSON write functions.

Three options:

-- Default JSON: write all as nulls.

-- Extended: use JSON strings for Infinities ("Infinity", "-Infinity"); NaN still null.

-- LabVIEW extentions (compatable with the LabVIEW JSON primatives): Infinity, -Infinity, NaN (not in quotes)

Note that the LabVIEW extentions are not valid JSON.  The Extended option IS valid JSON, but not all JSON parsers will process strings as numeric values.

 

Is this no longer on Bitbucket? Where is the repository now?

  • Like 1
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.

  • Similar Content

    • By drjdpowell
      View File JSONtext
      Package for working with JSON.  Uses high-speed text parsing, rather than building an intermediate representation as with prior LabVIEW JSON libraries (this is much faster).  Allows easy working with "subitems" in JSON format, or one can convert to/from LabVIEW types.  Uses the new "malleable VIs" of LabVIEW 2017 to convert to any LabVIEW type directly.
      JSON text makes use of a form a JSON Path notation, allowing easy and rapid access to the subitems of interest.
      Requires LabVIEW 2017 and install by VIPM 2017 or later.
      Original conversation about JSONtext.
      On the LabVIEW Tools Network.
      JDP Science Tools group on NI.com.
      Copyright 2017 JDP Science Limited
      Submitter drjdpowell Submitted 08/02/2017 Category General LabVIEW Version 2017 License Type BSD (Most common)  
    • By drjdpowell
      Package for working with JSON.  Uses high-speed text parsing, rather than building an intermediate representation as with prior LabVIEW JSON libraries (this is much faster).  Allows easy working with "subitems" in JSON format, or one can convert to/from LabVIEW types.  Uses the new "malleable VIs" of LabVIEW 2017 to convert to any LabVIEW type directly.
      JSON text makes use of a form a JSON Path notation, allowing easy and rapid access to the subitems of interest.
      Requires LabVIEW 2017 and install by VIPM 2017 or later.
      Original conversation about JSONtext.
      On the LabVIEW Tools Network.
      JDP Science Tools group on NI.com.
      Copyright 2017 JDP Science Limited
    • By ThomasGutzler
      Hi,
      I'm receiving a JSON string from a web API, which I'm trying to convert into a cluster (of clusters) but I've run into some problems:
      1) Sometimes the order of the elements in the JSON string changes, which causes my conversion to fail.
      2) Sometimes the "object" returned via JSON is null, which causes my conversion to fail if I use clusters within clusters. It works with variants in clusters but then I need to convert the all the variants manually
      Is there any way to improve my code to fix those problems? The attached snippet is a simplified version. In my project, the first JSON string to data is done in a library. The second conversion from "result" variant to data is done in my application. This makes a direct conversion from JSON string more difficult.

    • By drjdpowell
      JSON is a data interchange format (sometimes compared to XML, but simpler). There are multiple projects to create a JSON package for LabVIEW. This is yet another one motivated by this hijacked conversation originally about a different project to convert JSON into LabVIEW Variants.

      This project uses a set of LVOOP classes to match the recursive structure of JSON, rather than variants. It allows conversation to and from JSON. All functionality is available through two polymorphic VIs: Set and Get. In addition to Get and Set VIs for common data types, one can also convert directly to or from complex clusters via variant-JSON tools.

      Copyright 2012-2016 James David Powell, Shaun Rumbell, Ton Plomp and James McNally.
      [Note: if you are using LabVIEW 2017, please also see the JSONtext library as a an alternative.]
    • By Pavanb
      Hi There 
      I want to go from TestStand's output i.e. database to HTML5 SPC charts. Sorta like http://moderndata.plot.ly/using-plotly-from-labview-via-python/ Has anyone done this or used Bokeh or Enthough's data tool before?  What about these tools with TDMS or HDF5?
      Thanks. I appreciate it.
      Best,
      Pavan 
      By the way, https://www.enthought.com/services/consulting/case-studies/TAIPAN/ (like TestStand without TestStand)
       



×
×
  • Create New...

Important Information

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