drjdpowell

Having problems building my EXE.  Generates this error sometimes (when it doesn't just silently crash):

Does someone know what the long-meaningless-named VI might be (a vim instance, I'm guessing).  

Any help appreciated.

-- James

There is a page on Path notation too:

Quote

JSON Path notation in JSONtext

Paths specify an item in a tree of nested Elements, and start with $. Each element is either in the form .name, for Object items, or [n] for Array index ([*] for all elements). Multiple Array index can be specified ([n1,n2,n3,...]), and multiple Object items can be specified by the list form .[abc,def,...].   All elements/items can be specified with a * ([*] for Array elements, or .* for object items).

If the Path input does not start with a $, then it is interpreted as a single Object Item name, rather than a path.

Path Elements:

$	Root JSON Value
.name	Object item "name"
.[name1,name2,..]	Object items
.*	All Object items
[n]	Array index n (negative n counts back from end; -1 == last element)
[n1,n2,n3,...]	Multiple Array indexes
[*]	All Array elements
[#]	For appending to the Array, indicates element past the end

Example JSON:

{"A":[{"C":123,"D":4},{"C":567,"D":8}],"B":{"F":9},"E":true}

• At path $.A[*].C are 123 and 567
• At path $.A[1].C is 567
• At path $.B (or just B) is {"F":9}
• At path $.B.F is 9
• At path $.[B,E] are {"F":9} and true
• At path $.* are [{"C":123,"D":4},{"C":567,"D":8}], {"F":9}, and true

Object items can also be specified as their proper JSON string.   This allows the use of characters in names that would otherwise not parse correctly.  For example:

$."My Name that contains \"quotes\", []brackets, and dots." 

Note that this must be proper JSON (thus the escaped quotes in the example).

Lastly, please note that JSON Path is not standardized, and will differ from other path implimentations.  

For support please see [CR] JSONtext.

2 hours ago, jed said:

I looked at several JSONtext pages but could not find this answer... is there any documentation that would tell me how to use that <JSON>variables element?  I am still uncertain whether this just populates the string automatically with JSON or if the <JSON> tag causes this.

Did you look at the detailed help on teh JSONtext VIs?  They should all contain links to further documentation pages (or you can go to Help>>JDP Science>>JSONtext...). The "<JSON> tags" page explains:

Quote

<JSON> tags in JSONtext control labels

<JSON> tags at the front of labels of many string outputs of JSONtext functions serve to mark those strings as being JSON text, rather than standard LabVIEW text.  Functions that input LabVIEW types (including clusters and arrays of those types) look for these tags and treat such strings as already being in JSON format.  

For example, the string control "MyString" with value '123' will be converted by "To JSON Text.vim" to the JSON String "123", but the string control "<JSON>MyString" with the same value will be converted to the JSON number 123.

For support please see [CR] JSONtext.

Just a comment, but I have noticed that people very often deal with JSON by looking for the "monster cluster" that completely converts the JSON into a monolithic LabVIEW structure.  I suggest people think a bit more modularly in terms of "subJSON".  The first question I would ask you if I were working with you on your actual project is why do you need (at this code level, at least) to convert your variables from their perfectly reasonable JSON format to an array of clusters?

You've solved your problem, but this is the solution I just did:

I've put 0.4 on VIPM.io.

I reported that in 2018: CAR 605085.  I don't think they are planning on fixing it.  Must use C strings under the hood.

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>".

BTW, one other use case I've had is "Multiple applications read/write to common config file", which requires careful thinking about preventing one App from overriding changes made by another App.

48 minutes ago, Antoine Chalons said:

I started thinking about variant attributes to handle them (text and position) but it quickly gets tricky so for now I've accepted to either only read or lose comments.

I think you just need an extra string for each item to hold end-of-line comments, plus a "no item" data type to allow full-line comments.  See how teh NI INI Library does it.

There are actually multiple different use cases of config files, and multiple ways to implement those uses cases.

My most common use case is "Computer writes config; Human reads and may modify; Computer reads config".  The way I do this is mostly:

• Read config file into Application data structures.   
• Later, convert Application data structures into config file. 

Comments don't exist in the Application data structures, so comments get dropped.  

Another (used, by the NI/OpenG INI libraries, and I'm guessing your TOML stuff) is:

• Read config file into intermediate structure
• Query structure to set Application data structures
• Update intermediate structure with changed values from Application data
• convert intermediate structure back to a config file

Here, the intermediate structure can remember the comments in the initial file and thus preserve them.  But, IMO, this is also less clean and more complex than the first method, as you have an additional thing to carry around, and the potential to forget to do that "update" part.

Currently, with the latest version of JSONtext (now available!), I haven't really developed this second, comment-preserving method. I am more thinking of another, less common but important, use case: "Human writes (possibly from a template); Computer reads", where the computer never writes (this is @bjustice use case, I think).   Here, the human writes comments (or the Template can be extensively commented).

But I do intend to support keeping comments.  It will probably involve applying changes from the new JSON into the original config-file JSON, preserving comments (and other formatting).  But that is for the future.

Note added later: the config-file JSON with Comments is now available in JSONtext 1.6.5.  See https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-6/m-p/4146235#M39

23 minutes ago, bjustice said:

Those cyan VIs are from the JDP utility VIPM package

Note: that package also has RFC3339-compliant Datetime format VIs, if you haven't already done Timestamps.

1 hour ago, Francois Normandin said:

The SMO Process has a "passive watchdog" that monitors a single-element queue and gracefully exits if the asynch process completes normally... but it will stop the whole asynch thread if the queue reference goes idle. 

Messenger Library uses the same watchdog mechanism, although I just trigger normal shutdown via an "Autoshutdown" message ; I don't call STOP.  I would have thought 500 ms is too short a time to wait before such a harsh method.  

A "queue" is a first-in-first-out mechanism.   Don't be confused by specific implementations; the LabVIEW Event system is just as much a queue** as the LabVIEW "Queue".  

**Specifically, the "event registration refnum" is an event queue.

As thols says, the best practice is to NOT share things between loops, but if you do, I'd suggest a DVR.

9 hours ago, X___ said:

Have you talked with NI about that?

Like most problems, once I had a workaround, I no longer spent any time thinking about it.

There are quite a lot of other message-passing frameworks that you might want have a look at.  DQMH, (my own) Messenger Library, Workers and Aloha are on the Tools Network, for example.  AF and the QMH template are not the only things out there.

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

Can you attach the vi you show?

Nevermind, I've reproduced it.

Your attribute Values need to be valid JSON.  You are inputting just strings.  Convert your strings to JSON first.

Do you check for an error coming out of SQLite Close?  SQLite will not close and throw an error if unfinalized Statements exist on that connection.  The unclosed connection would then continue to exist till your app is closed.

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

The JSONpath example might help.   

Have you looked at the examples?