Jump to content

drjdpowell

Members
  • Posts

    1,964
  • Joined

  • Last visited

  • Days Won

    171

Everything posted by drjdpowell

  1. LabVIEW Clusters and Arrays do not map directly onto JSON Objects and Arrays. LabVIEW Clusters are fixed-size ordered sets of optionally-named values JSON Objects are variable-size, unordered sets of must-be-named values LabVIEW Arrays are variable sized ordered sets of values all the same type JSON Arrays are variable sized ordered sets of values that can all be different type So a LabVIEW Cluster with unnamed elements cannot map onto a JSON Object, but can map onto a JSON Array. Similarly, mixed-type JSON Arrays cannot be converted to a LabVIEW array, but can be converted to a LabVIEW cluster (assuming you know the number of elements and types). JSONtext thus supports two mappings for LabVIEW Clusters, as explained in Help>>JDP Science>>JSONtext...
  2. People who wish to use Variants and JSON generally want to do this: Put Static-Typed Data in a Variant in a larger data structure Convert larger structure to JSON Send the JSON somewhere Convert JSON back to larger structure (containing Variant) Convert Variant to Static-Typed Data But Step (4) is a big problem, as at that point we don't have access to the Type-description information to rebuild the Variant. But I say do this: Convert Static-Typed Data to JSON Assemble larger JSON from this subJSON Send the JSON somewhere Extract the subJSON Convert subJSON to Static-Typed Data This avoids the problem, as we only need the Type at the first and last steps,where we statically know the type.
  3. I've had multiple requests to "support Variants", but there is a mismatch between Variants (Data plus full type description including name) and JSON (Data with only weak type info: string, number, etc.). To support unflattening JSON to Variant would require a form something like this: { "VarA":{"Variant type":"long","name":"TypedA","Value":123}, "VarB":{"Variant type":"long","name":"TypedB","Value":456} } But this is a rabbit hole I'm not going down. I'd rather ask "Why are you using Variants here instead of subJSON?" This gives you the behaviour you expect:
  4. That is arguably not a bug, as Variants involves two names: the name of the Variant, and the name of the data contained in the Variant. In your case your empty Variants contain unnamed void data, and JSONtext flattens clusters of unnamed elements as JSON Arrays. It is not obvious if it is the best choice to use the data name rather than the Variant name. However, I am sort of tied to the behaviour of the Variant-to-Data node that I use internally to convert Clusters to Arrays of Variants. See this example: Note that Typed clusters and Clusters of Variants containing Typed Data both convert identically, while Variant elements of a cluster never retain the names of the Variants themselves, just the name on the Data in the Variant). The produced JSON matches these choices, made by the programmers of the Variant-to-Data node.
  5. The Object thing is not where I would spend limited effort in performance improvements, as I would expect the User to actually use the item Values and thus require a copy at some point. I would rather improve the JSONpath search algorithm.
  6. I hope Users can do whatever they want using the lower-level functions plus subJSON with the <JSON> tag.
  7. There is support for Sets and Maps in the latest version; I wouldn't want such things require any kind of "hook".
  8. Alternative (6): all attributes are returned as JSON values. Rather than get the attribute as the actual type, the User would get the attribute as a string, then use From JSON to convert to type. One could make VIMs that combine these two steps, and these VIMs might possibly be made to work with non-JSON attributes as well.
  9. 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: Leave as is, not really supporting Variant Attributes Deprecate the current To-JSON support and fully not support Attributes at all Save Type in the JSON somehow (I don't like this) Use limited JSON types when converting from JSON: String, Float, Boolean 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.
  10. 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 $.""
  11. Note: latest version supports comments. https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-6/m-p/4146235#M39
  12. 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.
  13. 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.
  14. "Git Branches aren't branches; they're just tags pointing to commits" is the first thing one needs to understand about Git.
  15. 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.
  16. Not sure I understand. The data type is just an array in a cluster; it's not actually protected in any way. It makes a copy if you want an ordered array, but not if you want to just access the circular buffer itself. That you can do by "unbundle".
  17. I did a Circular Buffer using VIMs, so I'm pretty sure one can get the same basic functionality, though i suspect there is advanced Xnode stuff that VIMs can't do.
  18. Terminology is an aid to communication among multiple people, so I'll stick with how I have seen "SEQ" generally used, unless I see multiple people use it differently. There are lots of terms that are not exactly literal; your "watchdogs" aren't actually canines, for example, but I understood the software concept you actually meant.
  19. Oh, sorry, I misread it. Your timing out on an Enqueue of a full Queue, while I have always built "watchdogs" using timeout on Dequeuing from an empty Queue.. In your case you do need to set a single element so as to define "full".
  20. I had a look at your watchdog example. I note that, in my mind, "SEQ" stands for a pattern of using of a one-element Queue like a DVR, rather than any use of a Queue with only one element. I changed your example to use a Queue of 10 elements, and it ran fine, so the single-element nature is not a meaningful characteristic. Even in cases where I use Queues that have to have one element, such as my "Future Tokens" in "Messenger Library", I don't think of them as "SEQs", even though they are literally single-element queues.
  21. Ah, you guys are talking about use of SEQs now, after DVRs were available. I'm thinking about before DVRs existed, where SEQs were often used to get DVR-like functionality. Most of that use of SEQs will have been replaced by DVRs now.
  22. It is my, perhaps mistaken, belief that SEQs were quite often used to fill the gap before DVRs were invented. I'm sure I saw several examples in other people's APIs, and I used them mostly that way. I've used the "back pressure" of a queue, too, but then it's an N-element queue, were N might be set at one, but doesn't have to be, unlike the DVR-like use case where it must be single-element.
  23. All the Tools Network libraries are supposed to have help documentation of some kind. At some point, they insisted I do it.
  24. I don't use DQMH myself, but some suggestions: Re #1 and using the timeout: you don't need to use a fixed timeout; you can write some small subVI that calculates the time remaining till the next scheduled read. For example, if teh last Read was at 98700 ms, the next read should happen at 98800 ms. If it is now 98712 ms, then the subVI can output a 88 ms timeout. If a message is handled, and the time is now 98798 ms, then the subVI will calculate a timeout of 2 ms. You would code in logic of what to do if it is after the scheduled time (either do anyway, or skip). Re #2: you could have the higher-level Module A send a message to C containing the User Event of B's Broadcast. Then C can listen to B, without directly referencing it. B and C would need to agree on the datatype of the User Event, but would not otherwise be coupled. A is doing the coupling, but without handling all the messages.
  25. I eventually "fixed" this by Find-Replacing all three VIMs used in the above large VI with themselves (thus starting the VIMs "from fresh"). There appears to be some kind of state that can be corrupted, that isn't fixed by clearing compiled code cache.
×
×
  • Create New...

Important Information

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