drjdpowell

Have you used this? Any fixes needed?

I suffer from the handicap of being located in UTC+00:00, which makes it difficult for me to spot bugs in local to UTC conversion. I have to remember to switch my computer to the wrong timezone to test things, and I obviously didn't do that here. Thanks for spotting this. The format specifier should indeed have a ^ in it.

I believe those dlls came from a standard postgreSQL: https://www.postgresql.org/download/windows/ You could try installing postgreSQL from there and finding the latest-compiled versions of those dlls.

That doesn't make much sense. Those DLLs aren't created by me; they are the standard PostgreSQL DLLs that I downloaded. They can't have any dependencies on any LabVIEW stuff.

Only suggestions I have are: Is the exe in that "builds" folder. The EXE xpects teh dll at "<EXE's folder>/data". Your screenshot shows the dll at "builds/data". Could be a missing dll that libpq.dll calls. Try downloading a full set of Postgres dlls and place them in the data folder.

I've never used Test Stand, but if I did, my first thought is to have a main LabVIEW App that controls all hardware, with Test Stand connecting (using the Messenger-Library TCP functions) and interacting via messages. Just as Shaun is describing.

All my applications are developed with a package I wrote several years ago called "Messenger Library": https://labviewwiki.org/wiki/Messenger_Library There are a few YouTube videos linked from that wiki that go through an actual example application. It's motivated by the Actor Model, and so I take inspiration from frameworks like Erlang, Akka or the C++ Actor Framework. The core concept is "messaging" to gain the benefits you list.

Remember that you are a User, and you only look at User Interface. When you "open a class" a cluster UI widget is loaded to represent the class data. But that widget is not the actual cluster. When you "open a subVI", the corresponding front panel is loaded with UI widgets to correspond to the block diagram terminals. But for most subVIs, that front panel is never loaded if it is not opened. This is unfortunately counter intuitive, as every subVI has a User Interface (Front Panel) a new programmer will think that is significant, while an experienced LabVIEW programmer will intuitively understand that the front panel of most subVIs doesn't really exist at runtime.

Didn't not read the full conversation, but thought I'd point out to the OP that it is a common mistake for programmers coming into LabVIEW to mistakenly identify LabVIEW's UI Widgets (Controls/Indicators) as being "variables", and Control References (actually references to the UI widgets) as being "data references". They also confuse the UI Widgets with the data that the Widget is acting as a UI for (which I suspect the OP has done when they talked about having many data copies in using "Arrays" and "Clusters"). Performant data-handling code will not utilize the User Interface at all, and if a "reference" were to be needed, it would probably be a DVR.

No, unfortunately, as it is written in LabVIEW 2017, which does not have that type.

Note: you can also do this (using the JSONpath for all array elements) because here one is specifying the element of the array (with default) rather that an empty array:

TortoiseGit is an interesting middle way between command line and a "full-featured" UI tool, as it mostly just replaces text commands with menu selections, and it can be configured to show the basic few commands (with a submenu for less-used commands): Then on top of commands is the "log", which is a visual representation of the repo.

Tried GitKraken a bit. Couldn't see enough improvement over SourceTree to consider a paid product (but I may be missing something). If I were going command line, I would first look into Gitless, and attempt by Computer Scientists to fix the flaws of Git. There is a paper on it here: Purposes, Concepts, Misfits, and a Redesign of Git.

The task manager should work, though like Neil I also find it displays too much, and have a more specialised tool built into my "Messenger Library" framework:

If only there was a > git fast-forward <new branch> One step, and no scary "-force" or "delete" involved.

Just for info: my recipe to fix a "detached head" is (using SourceTree) Create a temporary branch on the detached head commit (I prefer to name it "GitIsStupid") "Checkout" the real branch it should be on (usually) "Merge" the temporary branch into the current branch (no actual code merge occurs, so this is non-intuitive to me) Delete the now-unneeded temporary branch Git: making the easy things hard, and the hard things possible.

You are trying to create your ini file adjacent to your vi; in your exe that path is inside your exe, which cannot have files created in it. You need to have your ini file in a different place.

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