Cluster addition bug

[altenbach]

Don't get me wrong! I fully agree that whatever you discovered here is definitely a bug. 😉 (I wasn't trying to be unfair, the bundle example was to enforce the point that using multiple indentical unbundle or bundle terminals can lead to confusion. I still don't see a real valid reason to even allow multiple identical terminals.) 

Fortunately it got fixed in 8.0 (and hopefully the fix did not slow it down by an order of magitude :o).)

It just shows the difficulty of anticipating all possible usage patterns by the programmer, sometimes it takes years after a release to demonstrate a bug. Overall, it always strikes me how small the actual number of bugs is compared to the overall complexity of LabVIEW. 😄

[Ben]

tst wrote

"I see absolutely nothing wrong in unbundling the value multiple times for readability's sake, as long as the programmers make sure they selected the correct element."

I am with you 100% !

I actually prefer that style because it makes it crystal clear what the value be read is.

The alternative (unbundle once and run wires) would require a free label be used to ID the wire.

Ben

PS I do not have time to invesatigate but this sounds like the "data flowing backwards" bug.

PPs Christian: the answer BETTEr be "5".

Message Edited by Ben on 05-30-2006 02:03 PM

[tst]

---

@altenbach wrote:

Don't get me wrong! I fully agree that whatever you discovered here is definitely a bug.

---

I never thought you didn't.

---

the bundle example was to enforce the point that using multiple indentical unbundle or bundle terminals can lead to confusion. I still don't see a real valid reason to even allow multiple identical terminals.

---

In that case, I guess it's a matter of personal perspective - I don't find unbundling the same element twice confusing (if it's properly named) and I prefer the way the diagram looks. Since it's a matter of taste, we might as well leave it at that.

---

Overall, it always strikes me how small the actual number of bugs is compared to the overall complexity of LabVIEW. :D

---

Amen to that (not including the PDA module  ).

P.S. I believe the answer for your question about the bundle node (at least for as long as LV keeps its current paradigm and style) should be that the bottommost element gets written regardless of execution time, and I wouldn't find that confusing. What would be confusing is if you fail to notice that the last element is there. Also, since the last element will always be the deciding one, the other connections would be unnecessary and therefore can be considered bad style.

P.P.S. Speaking of bugs, you can tell your son that the file named Steps of Bonfim in the Dukes' site is actually Wildfire, which appears again 2 songs later. You can also tell him that I liked most of what I heard so far (particularly So Many Before).

[jasonhill]

---

@tst wrote:

I don't find unbundling the same element twice confusing (if it's properly named)

---

I just want to add a little emphasis to what you said, tst.  This thread is giving me all kinds of interesting ideas for the next obfuscated G contest.

[tst]

OK, I decided to do one version of Jason's idea and see if I could use this bug to build an obfuscated Hello World program (ignore the fact that the numbers are wrong, I was going to change them using trial and error). Unfortunately, this time it seems that the data in the wires is so messed up that all the elements in the array are 146 even though only the last element wired into the Build Array primitive is 146 (it looks like LV agrees with my method ). Can anyone please confirm that this is not happening in 8.

[johnsold]

32, 100, 106, 105, 107, 28, 81, 104, 106, 99, 90.

LV8.0.1 Mac OS X, 10.4.6.

Lynn

[jasonhill]

Now that we are completely off topic, I will throw up my little proof of concept.  It does not rely on tst's bug.  But rather exploits the confusion that can arise with mulitple reads and poorly chosen variable names.

Relying on bugs for obfuscation is a poor choice, because it may break (and be discovered / get firxed)  during patching.

Message Edited by jasonhill on 05-30-2006 03:13 PM

[tst]

OK, thanks.

This bug really seems to drive LV crazy.

[tst]

---

@jasonhill wrote:
It does not rely on tst's bug.  But rather exploits the confusion that can arise with mulitple reads and poorly chosen variable names.

---

That's what I thought you meant, which is why I said that mine is a version of your idea. I like mine better, because unlike yours, it would be much harder to figure out, similar to JPD's trick with typecasting from a boolean. On the other hand, mine would not have been fair, since it relies on a bug.

[altenbach]

---

@Ben wrote:

PS I do not have time to invesatigate but this sounds like the "data flowing backwards" bug.

---

I think it is more complex than just "flowing backwards". It is really strange, e.g. if you do execution highlighting, all unbundle outputs show as zero and the wrong values only appear after the increments. Even a probe placed right before the increment still shows zero. ...

---

@tst wrote:

P.P.S. Speaking of bugs, you can tell your son that the file named Steps of Bonfim in the Dukes' site is actually Wildfire, which appears again 2 songs later. You can also tell him that I liked most of what I heard so far (particularly So Many Before).

---

Thanks! I sent him a note, but they are probably traveling somewhere in no-mans-land between Utah and Colorado without any internet access. I'm sure you noticed that you can get the real "bonfim" track from their myspace page, though. 🙂