Jump to content

What do you use JSON for?


Recommended Posts

20 hours ago, smithd said:

The real reason I'm posting is just to bump and see how jsontext is coming. It looks like you're still pretty actively working on it on bitbucket...do you feel more confident about it, or would you still call it "VERY untested"? I'd love to try it out for real when you get closer to, shall we say a 'beta' release?

Also, from what I could tell there isn't a license file in the code. Are you planning on licensing it any differently from your other libraries, or you just never got around to putting in a file?

I’ll call this beta if you want to give it a try:

jdp_science_jsontext-0.2.0.9.vip

BSD license.

  • Like 1
Link to post
Share on other sites
  • Replies 53
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

I've just added the (almost-out-of-beta) 0.8 version of JSONtext to the CR.  I have used it in real-world projects but not exercised every feature.

Note: JSONtext is now on the LabVIEW Tools network.

I’d add: - Work on a stream (i.e. allow the JSON Value to be followed by something else, like the regular Flatten functions have a “Rest of String” output). - Give useful error messages that

Posted Images

  • 9 months later...

I tried to install this new version into 2017 and the library seems to have been improperly disconnected. Lots of those "library does not claim to own this vi" messages. I tried reinstalling, same result.

 

Edit: tried converting to zip and just extracting to VI lib, worked perfectly. Very weird.

Edited by smithd
Link to post
Share on other sites

Might be something to do with the new VIMs.  I couldn’t build the package without excluding examples that used VIMs.  Did you use VIPM 2017?

And, does anyone else have this problem?

Link to post
Share on other sites
16 hours ago, drjdpowell said:

And, does anyone else have this problem?

Works fine for me. No issues during installation and all examples work flawlessly. Absolutely mind-blowing! Thanks so much for sharing :wub:

My versions:

  • VIPM 2017.0.0.2007
  • LabVIEW 2017 17.0 (32-bit)

Edit: I should mention this is the only package I've got installed right now.

Edited by LogMAN
Link to post
Share on other sites
3 hours ago, Tim_S said:

I'm back on LabVIEW 2015, so can't test it... what kind of performance does this have versus the JSON API?

Sorry for the jump to 2017, but the new VIM functionality was just too tempting.   I need to repeat a performance comparison, but here was my earlier tests.  Depends on the use case, but roughly an order of magnitude for the typical cluster to/from JSON use.

Link to post
Share on other sites
37 minutes ago, drjdpowell said:

the new VIM functionality was just too tempting

Perfectly understandable... NI nearly got me to jump to 2016 with a couple of features, but had too much invested in 2015 versus the benefits. Still waiting for the long-term-support version of LabVIEW. :(

Hrm... I like the time improvements. The improvements won't impact how I'm using JSON, though, so no worries.

Link to post
Share on other sites

If you grab the latest code before NI week its been pretty stable for me in lv15, although the 2017 VIs seem to have prettier icons in some cases :)

I didn't dive too deep, but it looked like the VIMs just wrapped the variant functionality, so it probably wouldn't be too much of a challenge to remove the vims and just use one layer lower -- unless I missed something important.

We'll probably eventually bump up to 2017 but its such a chore to update all the devices and json is at the lowest dependency layer.

Edited by smithd
Link to post
Share on other sites
29 minutes ago, smithd said:

I didn't dive too deep, but it looked like the VIMs just wrapped the variant functionality, so it probably wouldn't be too much of a challenge to remove the vims and just use one layer lower -- unless I missed something important.

Actually, you can just back save the entire package and use the VIMs unchanged as regular Variant-output VIs.   The only issue that forced me to use 2017 to build the package was that the VIMs wouldn’t appear on the pallets if I built in 2015.

  • Like 1
Link to post
Share on other sites
33 minutes ago, smithd said:

but it looked like the VIMs just wrapped the variant functionality

Eventually I want to expand the use of VIM features, but getting rid of the variant-to-data boilerplate is a good start.

  • Like 1
Link to post
Share on other sites
On 9/29/2016 at 7:07 AM, smithd said:

Oh meh. How irritating. I don't think the pngs do but its worth checking. Thats the part of the system I haven't really gotten around to testing properly yet :/

PNGs definitely can contain zero bytes in their datastream. It's a fully binary format.

Link to post
Share on other sites
  • 3 weeks later...
On 8/11/2017 at 4:24 AM, drjdpowell said:

Any comments on the new JSONtext library?  Bugs?  Unclear or confusing parts?  Missing functionality?

For moving to 2017, was it just VIMs on the palette? Or did you encounter actual bugs with vims in 2015? (I ask because I have my own internal branch of yours, and I just put the vims in as drop VIs). Edit: It looks like my approach did not work -- the vim's don't auto-update. Maybe before they polished it in 2017, vims couldn't adapt if their type was variant? I know that polymorphs have trouble with variants so maybe its similar.

I also removed the private marker for variant to json text. Its still useful on its own, and making it private broke backwards compatibility with my code. Realistically this probably only effects me, but it is vexing when people make useful things private (for example my bitbucket request for a public version of the "json type.vi" function)

With the numeric formatting, what was the reasoning behind using 15 digits (%#_15g) vs say, 20?
Edit: I saw this on the wiki-- "This gives from 15 to 17 significant decimal digits precision. If a decimal string with at most 15 significant digits is converted to IEEE 754 double-precision representation, and then converted back to a decimal string with the same number of digits, the final result should match the original string. If an IEEE 754 double-precision number is converted to a decimal string with at least 17 significant digits, and then converted back to double-precision representation, the final result must match the original number."

Edited by smithd
Link to post
Share on other sites
On August 29, 2017 at 6:50 PM, smithd said:

For moving to 2017, was it just VIMs on the palette? Or did you encounter actual bugs with vims in 2015?

In 2015, the “VIMs” just worked as regular Variant-typed VIs.  You would have to use Variant-to-Data primitives to convert to desired type.

On August 29, 2017 at 6:50 PM, smithd said:

what was the reasoning behind using 15 digits

As in the wiki, beyond 15 digits not every decimal number has a IEEE 754 representation.   

Link to post
Share on other sites
3 hours ago, drjdpowell said:

As in the wiki, beyond 15 digits not every decimal number has a IEEE 754 representation.   

I would interpret that the opposite way...the point of a serialization format like json isn't to go string->data->string and have the strings match, its to go data->string->data and have the data match. According to that line in the wiki, that would seem to require 17 digits. 15 digits only handles the s->d->s use case.

Edited by smithd
Link to post
Share on other sites

But is JSON a serialization format for IEEE floating-point binary numbers?   Or is it a decimal notation format for data that can be used as interchange between programs (or humans) that are not necessarily using IEEE numbers?  My humans are going to be annoyed that the number 0.6 they intended is saved as 0.59999999999999998.  

Edited by drjdpowell
Link to post
Share on other sites
19 hours ago, drjdpowell said:

In 2015, the “VIMs” just worked as regular Variant-typed VIs.  You would have to use Variant-to-Data primitives to convert to desired type.

That's not true.  In 2015 (and several versions back) you could rename a .VI to .VIM and the inputs and outputs would have type propagation throughout the subVI just like it does in 2017.  The difference is that in 2016 and older it was implemented as an XNode and had issues with class (something XNodes have a problem with) and as a result working with the XNode and forcing an update also wasn't as easy.  Oh and the wires wouldn't break if there was a type problem, it would just not work and tell you the subVI was broken, but wouldn't allow you to see the VI or know which wire types it didn't accept.  VIMs worked back then, but not nearly as well as 2017 and I wouldn't really recommend using it.  I presented on XNodes and VIMs at NI Week 2016.

EDIT:  Apparently you also need this in your LabVIEW.ini:  ExternalNodesEnabled=True

Remove Duplicates 2015.vim

Link to post
Share on other sites
9 minutes ago, drjdpowell said:

Doesn’t VIMs in 2015 require the VIMs to be saved in User.lib?   

Nope you can just drag and drop the VIM I attached to a BD and it works as expected.

Link to post
Share on other sites

Oops, so there is apparently an INI key I had that I didn't realize made this work which might be another reason to not use it.  You need this:

ExternalNodesEnabled=True

With that you can wire an array of strings to the VIM I attached earlier in 2015.

Link to post
Share on other sites

I had the INI key.  I eventually found that I had to have the VIM in user.lib/macros, and drop the VIM from the palettes (dragging from the project or other source doesn't activate the VIM feature).

Having to save in user.lib is very problematic, so I am not going to back save JSONtext to 2015. 

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



×
×
  • Create New...

Important Information

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