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 post
Share on other sites
  • Replies 103
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

View File JSONtext Package for working with JSON.  Uses high-speed text parsing, rather than building an intermediate representation as with prior LabVIEW JSON librari

working on it

Definitely on my list of JSONtext additions.  Ideally, I would want to implement RFC 7396: JSON Merge Patch, with the ability to generate a "patch" of the differences between two JSON texts, then appl

Posted Images

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

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

 

 

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

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.  

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! :)

Link to post
Share on other sites
  • 3 weeks later...
 

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.

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

  • Similar Content

    • 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 drjdpowell
      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. 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.]
      Submitter drjdpowell Submitted 10/04/2012 Category General LabVIEW Version  
    • 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.