drjdpowell

Unfortunately, the SQLite DLL uses bare pointers, rather than safe refnum references, and is not protected against using a pointer after the thing pointed to has been released. If I were doing the library again, I would use a DVR to prevent calling functions on a dead pointer.

I am hoping that the need to branch the submodule repo will be a big improvement on the current situation. Needing to make an explicit commit/branch in the submodule will give the developer a point to think if they really meant to change something in the common component. If they do, they will be making a commit message describing that change. And I, if I'm the prime developer for that submodule) will notice this commit by another developer and can go and talk to them and deal with the issue (I will follow an aggressive merge-branch-quickly policy in common components).

In our case it's the opposite problem; shipping code for a test station that has not been tested for that station. We have multiple stations, that cannot all be tested at the same time, so changes to a shared component, made in developing one station type, should only be pulled into another type explicitly, not be a general "update all" thing. Admittedly, I would much rather update common components asap, and I'm hoping splitting the common components into submodules will allow most to be pulled often. Currently, the different stations get branched, with all shared components, which is a merging nightmare.

My problem with the "Attachment" feature is that is difficult to come up with an intuitive API. Just look quick example using a couple of Future Tokens to do one request-reply, with attached info. Way too complicated, with four bits of info in the reply message (envelope label, attachment, inner message label, and inner message data). This needs simplifying to be more than a niche feature.

Can you show me how you use "Add Attachment"? It's tricky to document its use, as I only use it as part of "Use Outer Envelope", and also because "Object Message" does double duty as "Outer Envelope" (as a Message is an object, then Object Message, when containing another Message, is acting like an outer envelope about that inner message).

It's badly documented, but it appears to be there for me, but in the "UseOuterEnvelopeLabel" vi (see below). This is because that is where I envision it being useful, with a requestor attaching something to the reply. But you may be using the "Add Attachment" vi, directly. This is still on disk, just not in the palettes. I will add it back into the palettes (issue 5).

That's what I mean. You'll fix that problem, but a junior programmer will not know what to do, and just carry on, possibly losing commits if the problem isn't seen in a month.

The problem I had is that submodules are connected to a specific commit, rather than branch, so when one checks them out originally one must remember to manually create a branch, else if you commit changes they are a "detached head", which is then fixable, but a pain. I find Git to be very much "'Oh, you should have used the "engage safety" and "don't_point_at_foot" options when you called the "git new_gun" command'.

Who uses Git Submodules? I know Greg Payne does and have watched his talk, but does anyone else have experience. I'm especially interested in experience with projects with multiple developers and multiple products (that might need to use different versions of the subprojects).

I've been experimenting with Git Submodules, as a way to deal with a large repo that supports multiple different Test Stations with lots of common code. It again demonstrates Git is powerful, but also how horrible the UX design is. It's like I want to do an obvious thing, so I do the obvious action, but because I missed the non-obvious step needed first, I am now in a state where I have to spend 10 minutes coming up with a series of multiple actions that will undo the damage.

You've reached the limit of my understanding of PPLs, other than they sound like a pain.

I've started a new NI User Group, to discuss the various tools I've published. This is because the current LAVA support threads on SQLite Library or Messenger Library, etc. have gotten far too long. An NI group allows individual conversations.

I've never used PPLs, but my understanding is that they can only externally call other PPLs, and will include copies of any source code they call, including the Action Engine VIs that the CVT is based on. To use the CVT for communication, one would need to make a PPL out of the CVT and call that from both your other PPL and the main program.

Latest version (minor differences): drjdpowell_messenger_ui_augments-1.1.2.10.vip

I guess the point is to have a list of packages third-party packages that your team uses, without cluttering up the public list of lists with one no one else cares about (or possibly without letting competitors know what you use).

The lists are just lists. VIP packages can't be private.

That should have produced an error. Did you solve your problem of not seeing errors?

This is basically this issue: https://bitbucket.org/drjdpowell/messenger-library/issues/32/clearer-way-to-pass-addresses-as-data-over Addresses are all based on communication methods, such as a Queue, that don't work across application boundaries. The TCP messengers get around this by replacing Reply addresses on messages with a special address that routes the reply back though the TCP connection. So all the local-only communication methods will work remotely, but only for addresses passed as Reply addresses. In your example, you are passing the address as data, not as the reply address. Rather than Query, use Send, with your Queue as Reply address. Use "read reply address" at the other end to get the address (actually now a "Route Back" address) and send your two messages to it.

Note: I am considering uping Messenger Library's base LabVIEW version from 2013 to 2017. This is to allow use adding actor templates that use JSONtext to do configuration, and to add VIMs to the palettes. None of my clients use LabVIEW earlier than 2017. Let me know if you use Messenger Library with LabVIEW earlier than 2017sp1 (sp1 fixed VIM bugs).

That's a standard technique I use all the time to prevent unwanted code coupling. In fact I almost always do it if I have reason to pass the address of an actor. I use either "Send" or "Actor" parent classes; there is no reason to use "Actor type 2". With the Send class (the grandparent of all address classes) one also has the option of passing a TCP Messenger, allowing you to run C or D on a different machine.

Thanks Oliver for pointing out this problem. I actually don't myself use a single Connection in parallel (if in parallel, I use multiple Connections), but the library should support this. The problem comes not from the single Connection, but from the preprepared SQL Statements for attribute access. They are preprepared for speed, but this means one needs to serialise use of the Statement. I've been burned by Semaphores in the past and won't use them, but I'll use some other method. Issue: https://bitbucket.org/drjdpowell/sqlite-labview/issues/10/attribute-parallel-access-bug

OP said they set a long busy timeout, so the write queries will just block and execute in serial order.

Try this: make a deliberate error in your SQL, such as spelling INSERT "INPERT", and see if the resulting error shows up in your web service error reporting thing. If it doesn't, then you are not seeing the errors produced by your "Exec SQL" call.

Your webservice could also respond with the result of the SQL execution, including any error that might happen. Your problem is either in your webservice or your SQL, not in SQLite losing writes.

What happened with those two tests I suggested? A non-Messenger-Library TCP listener, and a non-TCP actor?