[CR] JSONtext

[sprezzaturon]

Examples?  I looked through the "detailed help".  The "JSONtest API example.vi" did a great job at building a json structure and looks like to deconstruct it, you have to already know what the components are.  Are there other examples that I missed?

Thanks

[drjdpowell]

Example are in <LabVIEW>\examples\JDP Science\JSONtext, accessible through VIPM:

 

The JSONpath example might help.   

 

[Filipe Barbosa]

I have been using the From JSON text to write a 2-dimentional array containing an array of cluster as show on the block diagram below.

I have been getting error d91 (Hex 0x5B) The data type of the variant is not compatible with the data type wired to the type input on the From JSON.vi.

Although this error is only flagged when using version 1.4.5.91. When downgrading to 1.4.4.89 the error is not flagged and the conversion to the input happens without an issue.

I'll return to use the older version for now but it would be good to know why is this occuring on the newer version

[drjdpowell]

Can you attach the vi you show?

Nevermind, I've reproduced it.

Edited March 23 by drjdpowell

[drjdpowell]

2 hours ago, Filipe Barbosa said:

I have been getting error d91 (Hex 0x5B) The data type of the variant is not compatible with the data type wired to the type input on the From JSON.vi.

https://bitbucket.org/drjdpowell/jsontext/issues/80/2d-array-of-variants-not-converting

Will be fixed in 1.5.2

Edited March 23 by drjdpowell

[dblk22vball]

I am trying to convert some JSON, but the datatype changes based on the UUT response.

Since I am using the stock "From JSONText" vi, I was using a type def cluster, of a string, and two doubles (as seen in rxample 2).   But if the device has not been configured yet, it responds with 3 strings (example 1), which causes an error in the conversion process since the data types dont match.

Example (pressure and temperature are strings):

{"attributes": {
"flow": "<unset>",
"pressure": "<unset>",
"temperature": "<unset>"
}

 

Example 2 (pressure and temp are doubles):

{"attributes": {
"flow": "100",
"pressure": 5.235,
"temperature": 25.5
}

 

I can use two type def clusters, and if I get an error with one, try the other.   But I figured there might be a more elegant way to handle it.

[drjdpowell]

You could ignore the error, with NaN as default pressure and temperature.  Or you could read flow first, and only get pressure/temperature if flow isn't "<unset>".

[Rolf Kalbermatter]

Would it be a lot to ask, for this library to support C++ style comments? Basically any text after // would simply be ignored until the EOL.

I know that JSON strictly speaking doesn't support comments but JSON5 for instance does support those C++ style comments. 

Edited June 17 by Rolf Kalbermatter

[Aristos Queue]

The subVIs that "Merge Cluster into Object.vim" calls support pretty printing, but the terminal is not exposed to callers. Please add?

[drjdpowell]

2 hours ago, Aristos Queue said:

The subVIs that "Merge Cluster into Object.vim" calls support pretty printing

The various Insert functions, like the subVI on the Right, don't support Pretty Print.  I suggest you try Reformat, which can Pretty Print the resulting JSON.  Or in the latest 1.6.5 version, just released, try the new "Pretty Print" function, which is faster and supports Comments.

[Aristos Queue]

Block diagram of "From JSON Text.vim" is shown below.

1. What is going on in the error case of the case structure? Why do you need to call the same node but bypassing the error cluster? Why not just wire the default value through the case frame and leave out the call to Variant to Data entirely?
2. The error cluster tunnel going into the case structure can be changed into the ? terminal, thus avoiding forking the error cluster wire and making it just slightly clearer what's going on in this diagram.

[Aristos Queue]

Next question:
Why does "Get String" have two different inputs, one for the LV Type and one for the default value? The default value terminal does not appear to be wired anywhere in the toolkit, and all callers have to do their own selection after the call to pick the default value.

[drjdpowell]

18 hours ago, Aristos Queue said:

Why does "Get String" have two different inputs, one for the LV Type and one for the default value? The default value terminal does not appear to be wired anywhere in the toolkit, and all callers have to do their own selection after the call to pick the default value.

This was originally a method in the early prototype API of JSONtext (pre public release), which is why it has a "default" input.   However, I used this (now private) method internally whenever a LabVIEW type is stored as a JSON string (should really have made a separate method).  In such use, I found a problem of needing a better description of the error if conversion failed, and for that I needed the actual LVtype.  This is not really how I would design it from scratch, but it happened incrementally.

Edited July 13 by drjdpowell

[drjdpowell]

3 hours ago, Aristos Queue said:

What is going on in the error case of the case structure? Why do you need to call the same node but bypassing the error cluster? Why not just wire the default value through the case frame and leave out the call to Variant to Data entirely?

Ah, this can be illustrated with this image:

JSONtext does not follow the common error rule of returning default value on any error.  Instead, it returns best-efforts, with only sub-elements that produce errors being returned as the supplied default.  Here it is only the "B" element, requested as a Float but a String in the JSON, that is returned as default (as explained in the error message).

Thus we are doing the Variant-to-Data even on error, in order to get this partial conversion of JSON to Data. 

 

 

[drjdpowell]

On 6/17/2021 at 10:19 AM, Rolf Kalbermatter said:

Would it be a lot to ask, for this library to support C++ style comments? Basically any text after // would simply be ignored until the EOL

Note: latest version supports comments.

https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-6/m-p/4146235#M39

Edited July 14 by drjdpowell

[Aristos Queue]

I am getting this error when going to JSON. This seems like an error that should only occur when going from JSON. The error comes out of whenever the "$Path or Item Name" terminal is an empty string.

Now, for one thing, I'm not convinced empty string should be an error at all... using empty string as a field name is legit JSON so far as I know. But even if it is illegal, I would prefer a different error here, something that says "the field name cannot be empty string." Is that reasonable?

Note that I did try passing "$." instead of empty string... that gave me the same error.

Is there a way to add a field that has a name of ""?

 

[drjdpowell]

That is a case that needs (at least) a better error.

Try the path $.""

By using the quotes, the name is any JSON string, and can thus handle any name.  The unquoted form is for convenience and can't handle all edge cases.  

BTW, what JSON are you feeding in to that node.  It has to be an Object if you want to insert at $.""

Edited July 14 by drjdpowell

[Aristos Queue]

33 minutes ago, drjdpowell said:

BTW, what JSON are you feeding in to that node.  It has to be an Object if you want to insert at $.""

I'm feeding it legit object JSON. As long as the field name wasn't empty, everything worked. 🙂

[Aristos Queue]

This subVI violates the "never copy all or part of the input JSON string" rule. There's no such thing in LabVIEW as an array of substrings. I would suggest that the next version of the JSONText toolkit should include a VI named something like "Get all Object Item offsets.vi". It would return two arrays of clusters of two integers: start offset and length. The first would be the names and the second would be the object data. (After looking at the JSON spec again, I note that the name string can contain escaped characters, so maybe go ahead and return the names as you are doing now because otherwise people are going to forget that step and just get substrings and think they have valid names and the copies out of the main JSON will have to happen anyway.)

[Aristos Queue]

The handling of variant attributes is asymmetric. I can serialize the variant and its attributes are recorded as fields of an object. But on deserialize, the attributes are not recovered. I suspect this is because there isn't any type information to tell us what type each attribute should be, but I'm not sure. Why isn't the deserialize handled? Can it be handled?

[Jordan Kuehn]

I think AQ is enjoying this role as the end user instead of the LV programmer 🤣 I do appreciate following these edge cases though. I use this tool widely and it is fantastic. 

[drjdpowell]

15 hours ago, Aristos Queue said:

The handling of variant attributes is asymmetric.

The To-JSON behaviour was copied from the previous LAVA-JSON library.  That library had the reverse operation, but it only worked if one provided same-named attributes in the default value.  As you point out, this is because we need to know what type to convert the JSON to.  Personally, I found this kind of useless, as the whole point of attributes is to have unknown items of unknown type.  I had also developed "subJSON"  for exactly this use case, and never use Variant Attributes at all.  So it kind of got stuck in limbo.   

I note that the newer Set and Map support doesn't run into this issue, as Sets and Maps have Type.

Options:

1. Leave as is, not really supporting Variant Attributes
2. Deprecate the current To-JSON support and fully not support Attributes at all
3. Save Type in the JSON somehow (I don't like this)
4. Use limited JSON types when converting from JSON: String, Float, Boolean
5. As in LAVA-JSON, but using (4) as a fall back if type not supplied

Added later: see https://bitbucket.org/drjdpowell/jsontext/issues/39/support-json-to-variant-when-no-datatype where it was proposed to do (4), I think.

Edited July 21 by drjdpowell

[Aristos Queue]

I generally prefer #4 straight up. If you add #5, anyone not supplying the types will be slowed down by the code checking the input variant for "Did you provide a type for this attribute? How about this attribute?" and getting a "no" answer each time. It's not slow, but it is an unnecessary hiccup. Anyone who knows the types can get them from the generated variant.

The one difficulty that makes me lean toward #5 is objects. If we parse "a":5 then we know to add attribute "a" as an integer. But if we hit "a":{ ... } then that can be a cluster of those elements, another variant attribute table, or an class. In those cases, I'd like to leave it to the Serializer to decide how to parse what is between the braces. If it can detect that the stuff between the braces is an object or a known cluster and deserialize it, great. And if it cannot, it yields to its parent implementation which pulls it in as a variant attribute table.

Does that make sense?

[Aristos Queue]

14 hours ago, Jordan Kuehn said:

I think AQ is enjoying this role as the end user instead of the LV programmer 🤣

It has pros and cons. It is definitely a nice change of pace. 🙂

[ShaunR]

@Aristos Queue

Off topic I know. But whatever happened to

AQ Character Lineator INI Serializer/Deserializer

Didn't that do JSON?