json What do you use JSON for?

[drjdpowell]

  On 10/21/2016 at 1:40 AM, 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?

Expand  

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

jdp_science_jsontext-0.2.0.9.vipFetching info...

BSD license.

[smithd]

cool, will do. thanks

[drjdpowell]

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.

[smithd]

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 August 3, 2017 by smithd

[drjdpowell]

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?

[smithd]

My vipm version is 2017.0.0.2007 feb 03 2017

[LogMAN]

  On 8/3/2017 at 8:50 PM, drjdpowell said:

And, does anyone else have this problem?

Expand  

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

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 August 4, 2017 by LogMAN

[Tim_S]

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

[drjdpowell]

  On 8/4/2017 at 1:26 PM, 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?

Expand  

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.

[Tim_S]

  On 8/4/2017 at 5:01 PM, drjdpowell said:

the new VIM functionality was just too tempting

Expand  

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.

[smithd]

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 August 4, 2017 by smithd

[drjdpowell]

  On 8/4/2017 at 9:30 PM, 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.

Expand  

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.

[drjdpowell]

  On 8/4/2017 at 9:30 PM, smithd said:

but it looked like the VIMs just wrapped the variant functionality

Expand  

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

[Rolf Kalbermatter]

  On 9/29/2016 at 5: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 :/

Expand  

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

[drjdpowell]

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

[smithd]

  On 8/11/2017 at 11:24 AM, drjdpowell said:

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

Expand  

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 August 30, 2017 by smithd

[drjdpowell]

  On 8/29/2017 at 5: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?

Expand  

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 8/29/2017 at 5:50 PM, smithd said:

what was the reasoning behind using 15 digits

Expand  

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

[smithd]

  On 9/4/2017 at 10:06 PM, drjdpowell said:

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

Expand  

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 September 5, 2017 by smithd

[drjdpowell]

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 September 5, 2017 by drjdpowell

[hooovahh]

  On 9/4/2017 at 10:06 PM, 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.

Expand  

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.vimFetching info...

[drjdpowell]

Hooovahh,

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

[hooovahh]

  On 9/5/2017 at 1:30 PM, drjdpowell said:

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

Expand  

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

[drjdpowell]

  On 9/5/2017 at 1:39 PM, hooovahh said:

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

Expand  

Can’t seem to get it to work; must be missing something.

[hooovahh]

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.

[drjdpowell]

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.