topic Re: D'oh! in BreakPoint

D'oh!

JackDunaway — Wed, 09 Jan 2013 01:33:06 GMT

I just tracked down a subtle bug in my code -- this syntax was the culprit:

That's all!

Just sharing a silly bug that cost about a half-hour, intentionally starting a new thread to protest the megathreads that now dominate Breakpoint

Re: D'oh!

altenbach — Wed, 09 Jan 2013 01:55:34 GMT

I am sure I would have found it in 28 minutes. 😄

Re: D'oh!

PaulG. — Wed, 09 Jan 2013 13:23:03 GMT

As they say in Texas: "If it was a snake it would have bit ya'.".

Re: D'oh!

crossrulz — Wed, 09 Jan 2013 15:45:25 GMT

Been there, done that. 99% of the time, it is something really stupid like that.

Re: D'oh!

GregFreeman — Wed, 09 Jan 2013 17:57:12 GMT

@crossrulz wrote:

Been there, done that. 99% of the time, it is something really stupid like that.

And the other 1% it's something really, REALLY stupid.

Re: D'oh!

Alex.T — Thu, 10 Jan 2013 10:42:54 GMT

Do you think it'd be worth as posting as an idea?

Re: D'oh!

crossrulz — Thu, 10 Jan 2013 12:22:33 GMT

@Alex.T wrote:

Do you think it'd be worth as posting as an idea?

Go ahead and post it. It's an interesting idea. If it can be pulled off, I think it would help readability a lot.

Re: D'oh!

jcarmody — Thu, 10 Jan 2013 12:34:39 GMT

@Alex.T wrote:

Do you think it'd be worth as posting as an idea?

I'm sorry, but this is what I thought of when I saw your image:

Re: D'oh!

tst — Thu, 10 Jan 2013 12:38:05 GMT

@Alex.T wrote:

Do you think it'd be worth as posting as an idea?

It's a cool idea, but one problem with it is that it can only refer to the indices of the primitive itself (i.e. if someone wires a value into one of the inputs and that value is not a constant, then there's no way of knowing what the index in the array would be). I would suggest a modification - if a constant is wired into the primitive (or no value at all), then the primitive shows the indices until the next value wired into an input. Otherwise, it shows the same square which was there until now. I would show that as a demo image in the idea. I would also add an expection where if the index value is large and won't fit into the primitive, the output would show a square instead.

Re: D'oh!

elset191 — Thu, 10 Jan 2013 14:01:11 GMT

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Build-Index-array-element-index-tip/idi-p/987680

Re: D'oh!

Darin.K — Thu, 10 Jan 2013 14:08:56 GMT

Maybe there is some way for that to break your VI. 😉

Re: D'oh!

JackDunaway — Thu, 10 Jan 2013 14:47:35 GMT

@Darin.K wrote:

Maybe there is some way for that to break your VI. 😉

That's exactly my sentiment. A function with unwired inputs and outputs should break the VI. For this and for the static/dynamic configuration tst points out, I have removed the +1 from 2009 from the idea to which Tim links since it dilutes the array indexing syntax.

Each individual "Index Array" function in the node is overloaded to accept either 0 or 1 inputs. When it accepts 0, it implicitly accepts the ++ value of the index above. When a constant is wired into an index, it statically effects the configuration of the node. A *static* configuration syntactically should be representated and contained within the node, not without.

Rather than stepping even further syntactically in the wrong direction of the lexicon defition, we should push toward breaking this node into a few separate functions (one, statically configured; the other dynamically). This view is extreme, and I don't fully support it (I think the best path forward may be to do nothing with the node). Even though overloading is convenient, the tradeoff is safety. The compiler is your friend. Embrace the broken run arrow.

Re: D'oh!

Alex.T — Thu, 10 Jan 2013 19:11:51 GMT

Oh wow! I had no idea a configuration like that wouldn't result in a broken run arrow. I thought that if you left all of the terminals unwired, they'd default to incremental indexing, and if wired, all terminals would need some input... Seems a little crazy in terms of dataflow, but I suppose I see the advantages.

Now to lament over all of the time that could have saved me.

Re: D'oh!

JackDunaway — Fri, 11 Jan 2013 19:01:48 GMT

@Alex.T wrote:

Oh wow! I had no idea a configuration like that wouldn't result in a broken run arrow....

Now to lament over all of the time that could have saved me.

Yep! Very handy! Watch out though, since constructs like this (and my original example!) can sometimes be a code smell, better replaced by a typed/named data structure for code readability and type safety.

My original example has since been refactored for these reasons, and is more readable and scalable (static indexing of array elements is not readily scalable!)