Micro-Nuggets !!! ~~~~ Post 'em if you got 'em

[Darin.K]

Of course in a precisely targeted attack, NI decided to put a subtle bug in the combination of two of my favorite objects, variants (for their attributes) and the Feedback Node.  In building the attribute table I liked to use a FN in a loop to add attributes.  Turns out this is MUCH, MUCH slower than the corresponding SR code.    I believe this was fixed in LV10 SP1, so someday I'll have a version that works.

Be that as it may, I use fewer and fewer and fewer SR as time goes by, and find it completely silly that a single iteration loop is used simply as a container for a shift register, and that a First Call? primitive is necessary.

The benchmarking is tricky, the results depend on data type, size, relative frequency of read and write, phase of the moon, and execution priority of the FG.  I also believe that there is some very specific optimizations for the LV2 global construct in the compiler, maybe the FN can get the same boost if it does not already.

This idea must get more Kudos (or implemented at any rate)!:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/An-output-terminal-for-feedback-nodes-that-mirrors-the...

This idea (and its demon spawn) must be stopped at all costs!:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Auto-insert-Feedback-Nodes-in-cycles-quot-Option-...

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/quot-Auto-insert-Feedback-Node-in-cycles-quot-should-b...

(I like the comments in the duplicate)

Looking at the Kudos, what's wrong with you people?

[Bob_Schor]

A few years ago, I suggested adding a "Do Once" structure, something like a While loop with an automatic Stop, but different enough that it would be easily recognized by novices.  You would use this "special" structure for FGV, Action Engines, and similar things.  [Most of my students, when they first see a "Do Once" structure, are puzzled by it as they don't see why you'd decide ahead of time to stop an "iterative" loop].

The idea was shot down, with the suggestion that I use Feedback loops instead.  In my not-so-humble opinion (and my experience trying to teach LabVIEW), using Feedback loops in this way is not nearly as mnemonic as the "Do Once" explicit loop construct.

Given that one of the goals of a good programming language and a good program is its intuitiveness, might a Do Once structure be an idea to be revived?

[Darin.K]

I would see a "Do Once" structure as a special form of a "Do N times" structure, where N is specified at compile time.  It is very easy to implement, add shift registers to the Stacked Sequence structure.  As an added bonus you could manually "unwind" loops if you were so inclined.

[Bob_Schor]

How do you add shift registers to a Stacked Sequence?  [Quite frankly, I try really hard not to use Sequence structures, especially Stacked Sequences -- I prefer using Error Lines and connecting wires, and sub-VIs instead of Stacked Sequences, mainly because I found it very difficult to follow the tortuous path of the tunnels in and out.  I've even gone so far as to convert some Stacked Sequences into a Case Statement surrounded by a For Loop, which does allow you to use Shift Registers and really neatens (is that a word) up some messy code I inherited.]

If you are proposing adding Shift Registers to Stacked Sequences, I say "Hurray", particularly if it works with a single sequence.  I think I could explain that OK to my students ...  [the BS test of a Good Idea]

[Darin.K]

It would have to be added by NI to the FSS, but making that structure useful conflicts with their plan to let it wither away.

[tst]

---

@Steve Chandler wrote:

If you are not familiar with a functional global then read Ben's community nugget on Action Engines. A functional global is very similar to an action engine but it only has a set and get. It only stores data. If the VI operates on the data it is an action engine.

---

Let's just be very clear on one thing - the get/set VIs are exposed to the same race conditions that global variables are exposed to. There are very few reasons to use them over globals (for instance, you could add logging or breakpoints more easily), but if I trust that I won't have a problem with race conditions, I would generally prefer globals for something like this, as they're easier to use. For most things, though, I would go with other constructs.

Also, it's important to understand that people use the same terms to mean different things, so what you call FGV might not mean that in someone else's language.

I suggest you also look at this - http://labviewjournal.com/2011/08/race-conditions-and-functional-global-variables-in-labview/

[tst]

---

@Darin.K wrote:

Of course in a precisely targeted attack, NI decided to put a subtle bug in the combination of two of my favorite objects, variants (for their attributes) and the Feedback Node.  In building the attribute table I liked to use a FN in a loop to add attributes.  Turns out this is MUCH, MUCH slower than the corresponding SR code.

---

I believe that this bug only occured in specific conditions. I remember it killing my performance after I built a whole program based on it, which annoyed me, because I did test before I started to see that the performance was OK, and I couldn't figure out why it wasn't OK anymore. It took some very specific timing tests to find that the problem was with specific conditions (I think it was if you use a select node to pass the variant which you keep in an SR. Like you said, this was fixed in a later version.

As for the idea - when you see an annoying feature, you want it off. I don't think most people (including me) move past the loathing stage of your spectrum.

[tst]

---

@BOB Schor wrote:

If you are proposing adding Shift Registers to Stacked Sequences, I say "Hurray", particularly if it works with a single sequence. 

---

You would have some vocal opposition:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Stacked-Sequence/idi-p/918243

[SteveChandler]

Indeed! I have linked to the LabVIEW Journal article several times.

My only intent here was show that there is another way of creating a LV2 style global. It should be identical in functionality and drawbacks to the shift register version.

But it is good you point this out. Race conditions are simply an architectural issue. Local and global variables are a scapegoat. It's true that if those or even FGVs are used incorrectly your application can end up having race conditions. But it is the application that has the race condition and not the thing you are storing data in. Eliminating race conditions is about synchronization and controlled access to a shared resource.

But as for the micro-nugget. If it has no other benefit maybe it will help people understand this mysterious creature that, depending on your settings, just pops up out of nowhere when you inadvertantly create a cycle. Hopefully people who are freaked out by these things will come to realize they are just little shift registers that are not attached to a loop. How cool is that?

Spoiler

LOL Good thing I previewed. I had a typo which read "little *bleep* registers" instead of "little shift registers"

[Darin.K]

---

@tst wrote:

---

As for the idea - when you see an annoying feature, you want it off. I don't think most people (including me) move past the loathing stage of your spectrum.

---

I offer only my footprints along the path of enlightenment, no time to back up and push others.