drjdpowell

Did you wrap your INSERTs in a transaction?

There are (not free) extensions of Sqlite that add encryption, but I have not tried them:

Note: The NI Labs version is now available without password protection.

Yes, that's the basic JSONtext use case: working with JSON: Working to/from LabVIEW data types is also a use case, and there is the (more complicated) ability to intermix JSON and LabVIEW Types in clusters using the <JSON>-tag method smithd describes, but a basic motivation of JSONtext is to be able to work simply with JSON-formatted strings directly.

At some point, but it joins a long list of other things it would be nice to have. I'd like JSONpath filtering, like $.MyArray[?(@.type="MyType")]

We'd have to deal somehow with projects that are in the CR and on the Tools Network. Personally, I sometimes have a newer version in the CR (and update the Tools Network less often when the changes have been more real-word tested).

I now use JSON for tree-like program settings, and things like test results and test scripts. I left objects and variant attributes behind and just handle text directly (JSONtext). Like others, your "time series" examples don't seem very tree-like to me (although my JSON test-result files do contain several serieses).

I'm afraid those functions have not been implemented yet.

That extension to JSON is part of the LabVIEW JSON primitives, and JSONtext supports that.

I few other methods for you to consider: 1) a separate "helper loop": in this, the main loop of the template is a "manager", with a separate loop inside the actor doing the work. The "worker" can be controlled by non-actorish ways (such as an Abort Notifier) by the Manager, which is always capable of handling new messages coming in. This encapsulates the non-actor communication, keeping it local (and understandable). I likely addition to this is a "job queue", to hold the list of actions that the manager queues up for the worker. Here is where one can have job priority, or cancelable jobs. Note that this is different from the "action stack" (what you called a "state machine"). These are different things that are too often combined. 2) Have a "Sequence actor" that does the long actions, which can't itself be aborted, but which acts on hardware via short-to-execute synchronous Request-Reply messages to separate hardware actors. Send the "abort" messages to the hardware actors, putting them into a safe-mode state where they reply to action requests with errors. The first such error message causes the "Sequence actor" to end it's sequence (using standard error-chaining logic). Note that if your stop really is an emergency then this bypassing of your complex higher-level logic to talk directly to low-level hardware actors is actually a lot safer and more easily testable. 3) An asynchronous version of (2), where the "Sequence actor" uses Async Request-Reply for interaction with the Hardware actors. Less flexible than (2), but more properly actorish, in that the Sequence actor is always able to handle messages. I actually don't mind your abort notifier triggered from outside the actor. This is, as you say, bending the rules for a limited and clear purpose, and for the special case of aborting. Unfortunately, though, you're dealing with the problem of "state" (true "state", not the actions of a so-called "QSM") and that isn't ever easy.

I use an object only when I'm doing a lot more than just passing data in a single message. So a "job" object might be sent to the "Worker" actor, who calls "do job", but then the completed "job" is passed on to another actor who calls methods to reads the results. Or a "data" object might pass through several actors for processing and display. If I just want to pass a loose collection of data from one actor to another then I just use a cluster. But I find it rare to do this, and my messages tend to either be a single piece of data (or array) or a tight collection of data that makes sense to be an object.

I, personally, rare!y make custom message subclasses, though it is my intention that one can use Messenger Library that way. Somewhere on LAVA is an example I made of doing AF-style Command-Pattern messages. But I generally either use variants or I create non-message object classes that I pass in messages (example: a dataset object, or job object, or fast-growing object). The later have useful lifetimes longer than one message pass. I'm not sure variants are that slow, btw, so I would benchmark before avoiding them. Edit> "fast-growing object" is some strange auto-spell correction, but I can't for the life of me tell what I was meaning to write!

I needed a reference I can wait on, and I do not know of a lower-overhead option than a queue.

I suspect one of your actors, or something it calls, is broken in the build. "Async Launch Shell" is what calls all the actors, and any one being broken will throw an error like this. What I would do to debug is build all my actors as separate EXEs. Even if they don't do anything when run by themselves they should at least run. See if you get an error in building one of them. Unfortunately, debugging EXE problems is very painful and time-consuming. You could try re-asking your question on the main "Messenger Library" thread, as other developers who use it on RT have posted there and may have advice.

It's an asynchronous action called "Reference Monitor", a variant of the "Address Watchdog" available on the library pallets. It's started inside "Startup type 2.vi". That VI exchanges messages with "Startup Handshaking.vi" (inside "Launch Actor") in order to get a Queue created in the Caller for the Reference Monitor to monitor. The Monitor is configured to send a shutdown message if the Queue dies. BTW, this is one of the best examples of "internal complexity to support external simplicity" in Messenger Library. Having things created by a Caller automatically clean themselves up is a major simplification, but to get this requires sophisticated internal plumbing.

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

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.

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

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.

You seem to be sending CAPTURE... but your receiver is expecting only CAPT...

I'm trying it out on my own projects at the moment, but I intend to release it. I could post a copy here if you want to try it.

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)?

I've used public inlined methods (non-VIM), so that can't be the issue.

I use the ctrl-L shortcut key to bring up the Error List Window. Broken actor will have a red X.

My first suspicion would be you forgot to wire the newly-launched actor to your cluster (ie. you "dropped" or "lost" the address). The problem is almost certainly in your Top-Level actor. Use Probes to debug your actor's address wire backwards. Using the standard probe, an unlaunched actor address look like this (note the Messenger.lvclass): While a launched actor looks like this (note the EventMessenger substituted for Messenger.lvclass): You can also use the custom "Address Probe", which looks like this: The "X" indicates an invalid address, though note that this could be a launched-then-shutdown actor address, rather than an unlaunched one.