Jump to content

What do you use JSON for?


drjdpowell

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

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

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

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 comment

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.