[CR] JSON LabVIEW

[Dan B]

  On 7/31/2016 at 12:36 AM, Gribo said:

You need the 64 bit version of the library.

 

Expand  

Well, that's sort of my point. I was pointing to the dll in the 64 bit version of LabVIEW. I was working directly off of the VI's downloaded through VI package manager, installed into the 64 bit version of LabVIEW.

It's as though the dll included in this instance is NOT the 64 bit version of the library.

Maybe the issue is the OpenG library.

If it's just the dll that I need for the 64 bit library, does anyone have a copy they can attach?

[ShaunR]

  On 8/1/2016 at 2:44 PM, Dan B said:

Well, that's sort of my point. I was pointing to the dll in the 64 bit version of LabVIEW. I was working directly off of the VI's downloaded through VI package manager, installed into the 64 bit version of LabVIEW.

It's as though the dll included in this instance is NOT the 64 bit version of the library.

Maybe the issue is the OpenG library.

If it's just the dll that I need for the 64 bit library, does anyone have a copy they can attach?

Expand  

Zlib isn't a dependency of the JSON library, is it? You need to be over here, I think.

[Dan B]

  On 8/1/2016 at 3:58 PM, ShaunR said:

Zlib isn't a dependency of the JSON library, is it? You need to be over here, I think.

Expand  

Ah, your right. I was using it with conjunction with JSON, I thought it was embedded inside one. My mistake.

I'll go pester the right people

[drjdpowell]

The current LabVIEW version for this JSON package is 2011, but I am considering switching to either 2013 or maybe even 2015.  What versions do people need?

[JamesMc86]

2015 would work for me, all my active development is currently in that or higher.

Obviously if the current version could be archived somewhere just in case that would add a bit of security

[drjdpowell]

  On 8/15/2016 at 11:07 AM, JamesMc86 said:

Obviously if the current version could be archived somewhere just in case that would add a bit of security

Expand  

Past versions are all archived on LAVA.

[ShaunR]

  On 8/15/2016 at 11:03 AM, drjdpowell said:

The current LabVIEW version for this JSON package is 2011, but I am considering switching to either 2013 or maybe even 2015.  What versions do people need?

Expand  

Why? 2011 works in all versions up to and including 2016

[drjdpowell]

I have stuff developed for a client in 2015, that I'd like to incorporate into this package, but I'm using the conditional and concatenating options on loop output tunnels (that came in after 2011).  So supporting 2011 requires a rewrite (and a more complex and lower performance solution).

[ShaunR]

  On 8/15/2016 at 1:16 PM, drjdpowell said:

I have stuff developed for a client in 2015, that I'd like to incorporate into this package, but I'm using the conditional and concatenating options on loop output tunnels (that came in after 2011).  So supporting 2011 requires a rewrite (and a more complex and lower performance solution).

Expand  

I don't know if the concatenating tunnel is more efficient. I thought it was just syntactic sugar.

Anyway. You could back-save to 2011 and avoid everyone else from asking for it in an older version . You don't have to develop in the old version. The caveat would be if you wanted to use native primitives (like the parser in 2013).

[Stobber]

I'm using it in 2014.1. I would wait for a major upgrade to break compatibility. Shaun's suggestion of back-saving makes sense to me. I've done that with concat tunnels, and the code generator replaced them with old constructs appropriately as I recall. If you don't wait for an upgrade, then I'd bump the revision by a major number anyway. You even might consider setting the major rev to the version of LV it's developed in.

[Tim_S]

My work that uses JSON is in 2012. I just started shifting my core software to 2015 (though there are a couple things in 2016 that have caught my attention). I'm not running afoul of any bugs in the current revision, so I don't see an issue for me.

[kull3rk3ks]

I am currently wondering about the encoding of strings in JSON, since havine something like this:

 

{ 
	"serverConfig": {  
		"read": {   
			"address": "164.3.157.40",
			   "port": 5010,
			   "bytesToRead": 130,
			   "connectionMode": "Server",
			   "connectionTimeout": 5000,
			   "readTimeout": 2000
		}
	}
}

throws error 1 (Parser error)

and when I remove the quotation marks on the values like so:

{ 
	"serverConfig": {  
		"read": {   
			"address": 164.3.157.40,
			   "port": 5010,
			   "bytesToRead": 130,
			   "connectionMode": Server,
			   "connectionTimeout": 5000,
			   "readTimeout": 2000
		}
	}
}

everything seems to work just fine.

The problem is that the JSON Editor that I use automatically sets quotation marks for non-numeric values. also the first variant passes validation, whereas the second doesn't.

am I missing something?

Edited August 17, 2016 by kull3rk3ks

[JamesMc86]

Are you able to post this as a text file?

I always have quotes around strings using this tool without issues so they are supported and as you point out it isn't valid JSON without it. I am wondering if there are some extra characters or the types of characters that are used that cause the problem.

[drjdpowell]

  On 8/17/2016 at 8:36 AM, kull3rk3ks said:

 

{ 
	"serverConfig": {  
		"read": {   
			"address": "164.3.157.40",
			   "port": 5010,
			   "bytesToRead": 130,
			   "connectionMode": "Server",
			   "connectionTimeout": 5000,
			   "readTimeout": 2000
		}
	}
}

throws error 1 (Parser error)

Expand  

I quickly tried this string and I didn’t get any error.

[kull3rk3ks]

  On 8/17/2016 at 10:36 AM, JamesMc86 said:

Are you able to post this as a text file?

I always have quotes around strings using this tool without issues so they are supported and as you point out it isn't valid JSON without it. I am wondering if there are some extra characters or the types of characters that are used that cause the problem.

Expand  

I just checked the JSON file again, found no error in it and decided to upload it to che cRIO again for testing. Lo and behold it works... I have no idea why.

[JKSH]

  On 8/15/2016 at 11:03 AM, drjdpowell said:

The current LabVIEW version for this JSON package is 2011, but I am considering switching to either 2013 or maybe even 2015.  What versions do people need?

Expand  

I'm using JSON LabVIEW with a 2013 project, but I don't need the latest and greatest library

 

There is one feature I would love to see added though: Support for non-explicit variant conversion. JKI's recently-open-sourced library handles this very nicely:

The black frame represents a subVI boundary.

Several months ago I implemented a JSON-RPC comms library for my project, based on JSON LabVIEW. Because the "data" member can be of any (JSON-compatible) type, I had to expose the JSON Value.lvclass to the caller, who then also had to call Variant JSON.lvlib:Get as Variant.vi manually to extract the data. This creates an undesirable coupling between the caller and the JSON library.

It would be awesome if Variant JSON.lvlib:Get as Variant.vi could use the structure within the JSON data itself to build up arbitrary variants.

Edited August 18, 2016 by JKSH
Add variant comparison

[drjdpowell]

  On 8/18/2016 at 12:08 AM, JKSH said:

This creates an undesirable coupling between the caller and the JSON library.

Expand  

JSON is an interchange format.  Reducing coupling between components is what it’s meant for, so it’s sad that we worry about unwanted dependancies.  The “variants that contain only strings and numerics as basic datatypes” that you are asking for are a much less flexible substitute to JSON text.  I would not be happy if I had to do lots of manual type conversion on everything that isn’t a simple string; that’s an undesirable dependency to me.

Really, the best solution would be for NI to realize the value of a JSON-like datatype and build that into LabVIEW, replacing this library entirely with a much faster solution that can be widely used in interfaces between modules without worrying about unwanted dependancies.

As an alternative, have you considered using the JSON text itself as the thing to pass on, rather than a variant?  Try this: replace your “data” Variant with a string labeled “<JSON>data”.  That tag indicates to the library that you want your “data” subitem as JSON text.  Pass that string across your subVI boundary.  If you are just using strings and numerics, then your Caller can use the inbuilt JSON primitives to convert very quickly into data, so it isn’t dependent on this JSON library.

Personally, I solved this issue by deciding to make this JSON Library a standard component always used in all cases where complex structured data is passed between modules.  But then I did write the library.

[Tomi Maila]

I made the Adapt to Type method public in JKI JSON allowing separation of the parsing from a JSON string and adapting to a LabVIEW type. It's not yet documented but if you look into JKI JSON Deserializer class the behavior should be relatively obvious. First deserialize from JSON string and then call adapt to type when you know what type you need. Thanks drjdpowell for the suggestion!

[drjdpowell]

I’m doing a lot of work at the moment on a “JSON 2.0” version, particularly intended to improve performance in common use cases that I’ve encountered. For example, I have a new VI that flattens a Variant directly to JSON text (skipping the Objects entirely) that works on large arrays of numerics about 30 times faster.   

I’d like to claim R&D tax credits on the work I do on this (which is otherwise unpaid), and to do that the result of the work needs to be owned by my limited company, so I’d like to release the new version under “JDP Science Limited”, rather than “LAVA”.   I would put a BSD license on the new version, and properly comply with the BSD license of the current LAVA version.  I hope none of the contributors of "JSON LabVIEW” object?   The R&D credit would work out to about 30% of charged rate (if I do the tax math right, which is far from obvious).  30% is a lot better than zero.

 

[ShaunR]

  On 9/16/2016 at 11:35 AM, drjdpowell said:

I’m doing a lot of work at the moment on a “JSON 2.0” version, particularly intended to improve performance in common use cases that I’ve encountered. For example, I have a new VI that flattens a Variant directly to JSON text (skipping the Objects entirely) that works on large arrays of numerics about 30 times faster.   

I’d like to claim R&D tax credits on the work I do on this (which is otherwise unpaid), and to do that the result of the work needs to be owned by my limited company, so I’d like to release the new version under “JDP Science Limited”, rather than “LAVA”.   I would put a BSD license on the new version, and properly comply with the BSD license of the current LAVA version.  I hope none of the contributors of "JSON LabVIEW” object?   The R&D credit would work out to about 30% of charged rate (if I do the tax math right, which is far from obvious).  30% is a lot better than zero.

 

Expand  

I've no idea what you are talking about (R&D Tax credits?) so it's difficult to make a judgement but you appear to want to take sole ownership rather than be the caretaker of a community project. So I object on that basis. Am I able to claim these credits too?

There is nothing in the BSD licence that says you cannot take the current software and create a derivative as long as the licence is followed.I would prefer you create a new product derived from the current.to mark a distinct change rather than an attempt a seamless absorption. In time, people will probably move to your new product in preference  but I think a distinction should be made and the current project control handed over to LavaG admins.

I'm not suggesting that you don;t deserve most of the credit for the library. only that a distinction is made that it is no longer the same community software in order for you to benefit..

[drjdpowell]

  On 9/16/2016 at 1:14 PM, ShaunR said:

I've no idea what you are talking about (R&D Tax credits?)

Expand  

https://www.gov.uk/guidance/corporation-tax-research-and-development-tax-relief-for-small-and-medium-sized-enterprises

  On 9/16/2016 at 1:14 PM, ShaunR said:

I would prefer you create a new product derived from the current.to mark a distinct change rather than an attempt a seamless absorption. In time, people will probably move to your new product in preference  but I think a distinction should be made and the current project control handed over to LavaG admins.

Expand  

I was thinking of that as an option.   The LAVA community one would be version 1.4.1.  I’m afraid I’ve checked in some things starting with a switch to 2013; you should ignore those and branch from the last 2011 checkin.   I’ll set up a new repo and a new project name.  

[JamesMc86]

I thought the concept is that you would still own the copyright on your contributions anyway, if you happen to license it under open source (as you are obliged to if you have derived from most open source license) that doesn't have ownership implications so I wouldn't expect that to be necessary (although I'm not familiar with the in's and out's of R&D credits as I haven't found a project for them yet).

Either way I am happy for you to do this but I do think it would be a shame to split to 2 projects as it tends to cause more confusion (jenkins vs hudson for example!)

[drjdpowell]

JSON LabVIEW is BSD licensed.  It’s not “Copy Left”, so one doesn’t have to open-source any derivative work.  

BTW, what I’m working on is a major change, that gets rid of the intermediate representation as LVOOP objects entirely.   The only representation is text.  So I may be able make it an independent package that can be used in parallel with the LAVA JSON library.

 

[ShaunR]

  On 9/19/2016 at 5:29 PM, drjdpowell said:

JSON LabVIEW is BSD licensed.  It’s not “Copy Left”, so one doesn’t have to open-source any derivative work.  

BTW, what I’m working on is a major change, that gets rid of the intermediate representation as LVOOP objects entirely.   The only representation is text.  So I may be able make it an independent package that can be used in parallel with the LAVA JSON library.

Expand  

What is the criteria for the Tax exemption that requires this move? What makes this toolkit a good choice over, say, you messaging library which has little or no collaborative contributions  so far?

Edited September 19, 2016 by ShaunR

[drjdpowell]

  On 9/19/2016 at 5:57 PM, ShaunR said:

What is the criteria for the Tax exemption that requires this move? What makes this toolkit a good choice over, say, you messaging library which has little or no collaborative contributions  so far?

Expand  

I’m recording my work on Messenger Library and all other reuse libraries, and hope to claim at least some of them also.   JSON just happens to be what I am working on right now.