drjdpowell

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.  

Quote

Abstract of  "Purposes, Concepts, Misfits, and a Redesign of Git"

Git is a widely used version control system that is powerful but complicated. Its complexity may not be an inevitable consequence of its power but rather evidence of flaws in its design. To explore this hypothesis, we analyzed the design of Git using a theory that identifies concepts, purposes, and misfits. Some well-known difficulties with Git are described, and explained as misfits in which underlying concepts fail to meet their intended purpose. Based on this analysis, we designed a reworking of Git (called Gitless) that attempts to remedy these flaws. To correlate misfits with issues reported by users, we conducted a study of Stack Overflow questions. And to determine whether users experienced fewer complications using Gitless in place of Git, we conducted a small user study. Results suggest our approach can be profitable in identifying, analyzing, and fixing design problems.

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)

1. Create a temporary branch on the detached head commit (I prefer to name it "GitIsStupid")
2. "Checkout" the real branch it should be on (usually)
3. "Merge" the temporary branch into the current branch (no actual code merge occurs, so this is non-intuitive to me)
4. 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.

On 8/28/2020 at 3:40 PM, LogMAN said:

Branching submodules while branching the main repository, or as I call it: "when you spread the love".

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

On 8/28/2020 at 3:40 PM, LogMAN said:

Everyone on the team needs to remember to occasionally do git submodule update to pull the correct commit for all submodules. Just imagine shipping an application with outdated code because you forgot to run this command...

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.

On 8/26/2020 at 3:54 PM, Maksim Kuznetsov said:

Are you planning to return the "attachment" feature for the outer-envelope?

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

23 hours ago, Maksim Kuznetsov said:

Are you planning to return the "attachment" feature for the outer-envelope?
I remember using it for some time, but after installing the latest messenger library it seems to be gone.

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

2 hours ago, Neil Pate said:

I did get the detatched head a few times though.

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.

3 hours ago, Austin said:

 Any idea how to deal with this?

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.