Jump to content
News about the LabVIEW Wiki! Read more... ×

Recommended Posts

Is any early adopter using the “From JSON Text.vi” polymorphic vi (or its individual instances)?   I want to completely deprecate those in favor of only using the “From JSON text.vim” malleable VI.   Also, is anyone using any off-palette subVIs?   Because I’m about to reorganize them and make them all private.

Share this post


Link to post
Share on other sites

I’m also considering removing the “Section Cluster” stuff, to reduce the API to support.

Share this post


Link to post
Share on other sites

I am using those VIs because I can't update to 2017, so I guess this is the part where I just keep my fork separate.

Share this post


Link to post
Share on other sites

Hi, has anyone tested this package with double datatype?

Doubles get encoded to JSON, but on decoding the decimal part gets cut off.

This seems a problem of the scan From String operation, which uses the country typical decimal separator. In JSON only the (.) is used.

I suggest to add the format string "%.; %f" to the vi's which decode floating point data.

Perhaps there is other country related stuff (timestamps could be a candiate).

Greetings Tobi

Edited by elsatobias
Investigated problem, added possible solution

Share this post


Link to post
Share on other sites

Sorry about that.   I had put %.; in the array functions but forgot the scaler ones.

Edit> please try the 1.2.6 version just uploaded.

Edited by drjdpowell

Share this post


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

Sorry about that.   I had put %.; in the array functions but forgot the scaler ones.

Edit> please try the 1.2.6 version just uploaded.

Hello,

I have tried the 1.2.6 version. But instead of adding "%.;" (dot), you added "%,;" (comma), what is standard definition on my system. So the problem still exists.

With the new version, nobody could import JSON floating point strings, because even on systems using "." as decimal separator, you forced the converter to use ",".

I'm afraid, you have to change it again.

Greetings Tobi

Share this post


Link to post
Share on other sites

Opps.   I had made it %,; as a way of testing it on my machine with strings like "123,456", but I forgot to switch back!

Edit> added 1.2.7 version; please test

Edited by drjdpowell

Share this post


Link to post
Share on other sites

Hi, I woul like  to discuss an idea to extend the funcionality of JSONtext.

We would like to use JSON as configuration files to replace INI files without the complexity of XML. This works great from the technical point of view. There is only the drawback that JSON does not support comments in the text, which makes it harder for humans to edit the files. The YAML file format supports comments and it claims to be a superset of JSON: http://www.yaml.org/spec/1.2/spec.html#id2759572

I am not asking to build a complete YAML library (even if this would be a great thing, too), but I was asking myself if it made sense to add support for YAML comments into JSONtext.

This might have to be optional, since it would not comply with the original JSON specification. If active, all code searching for the different markers inside the JSON string would have to check for "#" characters that follow whitespace and ignore everything up to the following line end (with the exception of "#" inside strings).

I am not sure about the implication this would have for code writing to the JSON string (the "Merge ..." VIs).

And of course this would lead to the demand for a function that strips the JSON-string of all comments to convert it to valid JSON that can be used with other APIs.

What do you think?

Share this post


Link to post
Share on other sites

Do you want to be able to programatically add comments, or just ignore them on reading?   I am wary of adding features to the core functions as I want to protect its speed and simplicity, but I don't mind additional functions.  In fact, I've been considering a function that is intended to take human-edited JSON and "fix it up", correcting common errors like leaving an extra comma when deleting.  This could easily strip comments.

Edited by drjdpowell

Share this post


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

This could easily strip comments.

If you're considering this, then the next question is: What style of comments?

  • @silmaril suggested YAML, which uses "# ...".
  • JavaScript (which is where JSON came from) uses "/* ... */" and "// ..."

Will you choose one to support? Will you support both (and any other style that might appear in the future)?

Edited by JKSH

Share this post


Link to post
Share on other sites

If it's an additional "fix it up function" then I can support many versions easily.  Might be slower, but one doesn't care about raw speed in a config file use case.   But I'm wary of adding more extended features to the core functions, where I do care about speed and simplicity.  As an example of the simplicity issue, currently one can overwrite whitespace when setting values in a JSON.  I use this to allow quicker setting of items in the JSON, allowing update in place where possible.   If I have 10 char of whitespace and overwrite 4 characters, I now have 6 char or whitespace.  But if I have a 10-char comment, and overwrite 4 char, I now have corrupted JSON.

Share this post


Link to post
Share on other sites
On 7.3.2018 at 1:47 PM, drjdpowell said:

Do you want to be able to programatically add comments, or just ignore them on reading?

The primary use case would be read-only, which could be covered perfectly by a strip comments function.

The drawback of this is that it makes any programmatic changes to the config files impossible... ok, not really impossible, but changing one item destroys all the comments in the file

If there is some elegant way to simply ignore comments and keep them in place when changing values without slowing down the core functionality - that would be great! But I do understand that this is very difficult at least.

And I have to admit that I currently don't have any use cases where config file changes have to be written programmatically, so your suggestion sounds like the appropriate solution to this.

 

On 8.3.2018 at 6:29 AM, JKSH said:

What style of comments?

  • @silmaril suggested YAML, which uses "# ...".
  • JavaScript (which is where JSON came from) uses "/* ... */" and "// ..."

That depends on the way you look at your file. If it's "JSON with comments", the JavaScript style is appropriate. If it's "the JSON part of YAML with comments", the YAML style is the way to go. I am in favour of supporting all three of them in the additional "fix it up function". As James pointed out, performance is no concern in this use case.

 

To get into the technical details: This would mean we have two kinds of comments:

  • Line comments: start with a marker symbol sequence; end with the next EOL or EOF.
  • Block comments: start with one marker symbol sequence, end with another marker symbol sequence.

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.

 

Share this post


Link to post
Share on other sites

I have a variant of an Enum that I want to convert from JSON text.

When using JSONtext, not only the Enum datastrings are lost, but also the datatype is changed (from unsigned long to signed long)

I also tested "JSON API" with the same data, and that worked just fine.

Am I doing something wrong?

JSONText - Enum data and typedef are lost in json to enum variant conversion.png

Edited by SGI

Share this post


Link to post
Share on other sites

What are you trying to do?   Are you trying to load "Page 2" of your tab control?  Because the number 1 will be converted by "Variant to Data" to your "Page 2".

With JSONtext, I placed speed over making the Variants perfect.  Variants are a means to an end.  I did the fastest, lowest-overhead way that will produce a Variant that can be converted to your datatype correctly.   For an enum, an integer converts correctly and is probably an order of magnitude faster than what JSON API does.

Why are you using the Variant version of that VI, anyway, rather than the VIM (which hides the variant stuff away entirely)?

 

 

 

Share this post


Link to post
Share on other sites

JSONtext is really a great help in our work - thank you very much, James!

I was missing a function to merge JSON objects together recursively (since "Merge into Object.vi" is only considering one level of the data structure), so I wrote a VI that does this (see attached VI).

I am sure this isn't the most efficient way to do this, so I am open for suggestions to improve the code.

Would you consider adding this functionality to JSONtext?

 

For anyone wondering why one would need this kind of merge function: Our use case is a modular configuration file structure, in which a complex configuration resides in one large JSON object. Each JSON file may contain references to include other JSON files into the current configuration. This enables us to structure the test configuration for about a hundred similar but different items in a reasonable way. Even if wrote "large", the JSON files are still small enough that the performance of the merge function is no issue for us.

JSON_Merge_Recursively.vi

Share this post


Link to post
Share on other sites

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 apply the patch to one text to get the other. 

  • Like 1

Share this post


Link to post
Share on other sites

I wasn't aware of this RFC - thanks for the link!

One interesting aspect: It uses null-values to delete items, which means we should write our software to behave in the same way for a null-item and for a nonexisting item.

In some cases this might leave us with the problem of how to correctly save a NaN value.

 

Share this post


Link to post
Share on other sites

I have problems converting the data back from JSON to the correct variant data type, even when using the VIM instead of the VI and using 'Variant to data'.

At the moment, I have no alternative for using variants as my data type.

 

Any other suggestions for making this work?

JSONtext - issues reading variant data type from JSON.png

JSONtext - issues reading variant data type from JSON.vi

Share this post


Link to post
Share on other sites

My questions remain the same as back on June 15: what are you trying to do?

Share this post


Link to post
Share on other sites

I'm trying to use JSON to store control and indicator values of which I don't know the datatype.

I use dynamic VI calling, I set controls using VI Reference -> Set Control values, run the VI, and get the indicators using 'Get Control values'; those need an give back variants, which I want to load from JSON and store back to JSON.

 

Edited by SGI

Share this post


Link to post
Share on other sites

I think you may be misunderstanding how "Variant to Data" works and what it is for.  Providing a type inside a Variant to the top input does nothing; instead you need to connect the actual type.  It converts variants into a specific data type.   You don't need "Variant to Data" at all for your Controls, as they stay as Variants.  And names never matter; if you get the data structure right, it will work.  "Variant to Data" and "Set Control Value" both ignore that actual names in the data.  

I do Controls to/from JSON all the time, so I will try and dig up an example.

Share this post


Link to post
Share on other sites

An example (using and array of control references, but you can make Get/Set Control Values work similarly):

To JSON:

Controls to JSON.png

From JSON:

JSON to Controls.png

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

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