[CR] JSON LabVIEW

[drjdpowell]

Looks good to me.  Any other changes before I make a new VIPM package?

[ShaunR]

Looks good to me.  Any other changes before I make a new VIPM package?

 

One thing that I haven't gotten round to yet. If you re operating on a large JSON stream, you cannot process any other JSON streams as it seems to beblocking. I think it just needs setting some of the subVIs to re-entrant, but like I said. I haven't gotten round to looking as yet.

[mcarvalho]

Hello. For 2D Array of strings the VI: "Variant Decode" doesn't if the strings have different Sizes

 

I made some changes using the data string information : nnnnstrstrstr... (4 bytes with string size + the string itself). 

 

Album: Code Examples

1 images

0 comments

 

 

Regards from Portugal.

Manuel Carvalho

 

Edited July 17, 2013 by mcarvalho

[Ton Plomp]

Hi Manual,

 

thanks for the report, the last commit by James should be fixing this.

Shaun, I haven't seen this, by using a quite large JSON set, and parsing it twice in parallel, both methods can the same time.

 

Regards,

 

Ton

[Stinus Olsen]

Hi guys

 

Thumbs up for the good work!

 

I am creating a generic variant based intra-process configuration handler, and are considering using this as one of the user-selectable underlying 'file abstraction layers'.

However - since I plan on using an intermediate variant collection between the user and the file layer, I will need to be able to set new values in the JSON value tree without overwriting all other values.

Currently I don't see any way of doing this (I don't see a "Set sub-Item by names" function)..

 

Is this left out deliberately, or have you guys just not gotten around to it yet?! (or am I missing a point as to why it isn't implemented?)

[Stinus Olsen]

Hi again

 

Regarding the post above I took the liberty of adding the functionality to the project.

I have attached a zip file containing only the VI's I have added or changed (folder structure has been kept) - feel free to add it to the project if you want..

 

Changes:

 + Added VI's for updating an existing JSON Collection Object value - by Array of names

 + Added VI's for removing a JSON Collection Object - by Array of names

 * Changed polymorphic Set VI to include new features .. the 'Set Object' function has been made into a submenu..

 

Best Regards

Stinus

Changes to tcplomp-json-api-labview-0c0d17447fc4.zip

[ShaunR]

Hi Manual,

 

thanks for the report, the last commit by James should be fixing this.

Shaun, I haven't seen this, by using a quite large JSON set, and parsing it twice in parallel, both methods can the same time.

 

Regards,

 

Ton

 

It seems to be blocking with arrays.

 

Here's an example to demonstrate. The text file is made up of giant arrays so it makes it much more obvious (takes about .4 mins to execute)

 

I'll take a closer look on Sunday. A bit strapped for time at the moment.

Hi again

 

Regarding the post above I took the liberty of adding the functionality to the project.

I have attached a zip file containing only the VI's I have added or changed (folder structure has been kept) - feel free to add it to the project if you want..

 

Changes:

 + Added VI's for updating an existing JSON Collection Object value - by Array of names

 + Added VI's for removing a JSON Collection Object - by Array of names

 * Changed polymorphic Set VI to include new features .. the 'Set Object' function has been made into a submenu..

 

Best Regards

Stinus

 

Sweet.

I'll take a gander later.

[Stinus Olsen]

Sweet.

I'll take a gander later.

 

I think Ton is also planning to go over the change this weekend, just to let you know so you don't do any asynchronous work

[drjdpowell]

I’m about to go on holiday for two weeks, so I’m going to post a CR version with just the bug fixes made by James McNally, leaving other issues for later.

[ShaunR]

I’m about to go on holiday for two weeks, so I’m going to post a CR version with just the bug fixes made by James McNally, leaving other issues for later.

Why not just wait until you come back when the others will have been addressed too?

[drjdpowell]

Why not just wait until you come back when the others will have been addressed too?

Just in case someone is urgently needing this bug fixed.

[Ton Plomp]

I went over the code by Stinus, and it looks good and valid.

 

One of the open points in the code is retrieving attributes of waveforms. My proposal is to return each attribute as it's raw JSON string (indicated by a .JSON extension):

Any other ideas?

 

Ton

 

[ShaunR]

Hi Manual,

 

thanks for the report, the last commit by James should be fixing this.

Shaun, I haven't seen this, by using a quite large JSON set, and parsing it twice in parallel, both methods can the same time.

 

Regards,

 

Ton

"Set From JSON String.vi", "Name.vi" and "First Char.vi" are not set to re-entrant.

Just downloaded the latest version and "Set From JSON String.vi" now seems to be reentrant which cures the blocking. The others are still not re-entrant though.

[drjdpowell]

Here is a topic suggesting an increase in the number of digits precision used in formatting floating-point numbers.

[ShaunR]

Added Path case to "Variant To JSON.vi" and updated example.

(See this post)

 

Variant To JSON.vi

Example JSON Variant Tools.vi

 

I think the default case would be able to handle paths if Variant to JSON used OpenG Format Variant Into String.  Why was this not done?

Because the intention is (was?) to remove OpenG dependencies completely...

[PBD_ctrl]

Thanks for the fix!  I wish I had found this thread earlier.  Can anybody create a new build and check it into bit bucket or is that reserved for people on the team?  Can somebody get the fix into a new build?

One thing that I haven't gotten round to yet. If you re operating on a large JSON stream, you cannot process any other JSON streams as it seems to beblocking. I think it just needs setting some of the subVIs to re-entrant, but like I said. I haven't gotten round to looking as yet.

 

 

I have seen similar behavior.  I can try to replicate it if anybody is interested. What I found was that if GetTypeInfo is being called by two separate application instances they block each other because it's non-reentrant.  I don't think we are going to find a work around for that.  This might be a unique situation that I found because of the multiple application instances aspect but I figured it was worth mentioning.

[ShaunR]

Thanks for the fix!  I wish I had found this thread earlier.  Can anybody create a new build and check it into bit bucket or is that reserved for people on the team?  Can somebody get the fix into a new build?

 

 

I have seen similar behavior.  I can try to replicate it if anybody is interested. What I found was that if GetTypeInfo is being called by two separate application instances they block each other because it's non-reentrant.  I don't think we are going to find a work around for that.  This might be a unique situation that I found because of the multiple application instances aspect but I figured it was worth mentioning.

The fix has already been pushed to bitbucket. The others will review it then, if it's acceptable, drjdpowell will fold in any other changes and build a VIP package for the CR (only he can update the CR).

[drjdpowell]

I’m snowed under with work and about to go on holiday for two weeks, but people can check out the bitbucket repo and build the VI package to test it if they want (the VIPM build file is in the repo).

[Ton Plomp]

I have build a new version: 1.1.2 and uploaded to Bitbucket.

 

Ton

[PBD_ctrl]

Thanks for making the build.  I appreciate everybody's help in getting these fixes made.

     -Pat

[PBD_ctrl]

After doing some testing I found that JSON to Variant can't handle empty paths.  The problem is caused by the OpenG Scan Variant From String throwing error #1 because the string it is scanning is empty.  A simple fix would be to add an additional case structure to handle paths within JSON to Variant.  

[ShaunR]

After doing some testing I found that JSON to Variant can't handle empty paths.  The problem is caused by the OpenG Scan Variant From String throwing error #1 because the string it is scanning is empty.  A simple fix would be to add an additional case structure to handle paths within JSON to Variant.  

 

I think the OpenG Scan Variant From String is obsolete since JSON to Variant can handle all types now (apart from refnum and path-which are easily added). We should consider removing the OpenG Scan Variant From String completely. I would also suggest that for the unknown data type we output a string type and raise a warning  rather than an error..

Edited February 28, 2014 by ShaunR

[PBD_ctrl]

I think the OpenG Scan Variant From String is obsolete since JSON to Variant can handle all types now (apart from refnum and path-which are easily added). We should consider removing the OpenG Scan Variant From String completely. I would also suggest that for the unknown data type we output a string type and raise a warning  rather than an error..

 

Sounds good to me.  I am new to BitBucket so excuse me if this sounds stupid but do I have to be part of the "Team" to download the source?  I have SourceTree installed but I think I am blocked from contributing.  

 

If I had access I would be glad to make these changes.

[PBD_ctrl]

I have a few ideas kicking around about how to handle refnums.  Anybody else want to see the class work it's way into the string for readability?

[PBD_ctrl]

I just committed my code to BitBucket for handling paths and refnums.  Should the commit be showing up in BitBucket before it's reviewed?  This is my first BitBucket project and I am trying to make sure that I didn't screw up and step on anybodies toes.  Let me know...