Label arrow bugs with In Place Element Structure and more...

[X.]

Since I have no intention to sign up for beta testing, I submit the following bug report here for the record.

Take an In Place Element Structure:

Drop a label and connect it to the structure via a magic arrow. Move the structure around, everything works as expected (and intended, I suppose):

Now create a primitive within the structure, and drag the arrow on top of it in order to connect it to that specific primitive:

Drag the primitive (or the structure) and observe how the arrow points to its original location:

     or           

Now, what is VERY interesting is that if you move the primitive (or the structure) around a couple of times (with no effect on the arrow obviously) and then CTRL-Z (undo) each step, you will see that the arrow snaps back to the primitive!

I will be hard pressed to accept that this is the intended behavior, hence this is a bug.

[JÞB]

Well,  at least they fixed the phantom terminals on structures inside IPE

But X,  Why are you still using the IPE structure?  Almost allways the optomizer lets inplaceable operations operate inplace without the extra synchronization boundry (since 2011 at least!)

[X.]

Didn't know that. Is that a fact? It's not mentioned in the Help, AFAIK. Besides, I just created this report because of this comment I made here.

Edit: more arrow "features" reported there in this post where I show that arrows can't be attached to the dynamic event terminal of an Event Structure, or the input/output terminals of a Formula/Mathscript node.

As a matter of fact, the Timed Loop and Timed Sequence's Input and Output Nodes behave rather similarly to the IPE nodes discussed above in the sense that you can target an arrow onto them, but the arrow will (occasionally) not follow them of you move them around. However, it will snap back to the node if you double-click it (which will unfortunately also open a dialog window).

[JÞB]

Yes,  the IPE is less advantageous with newer compilers.  I did a Benchmark with 2011 that may be searchable. try the (uNuggets thread)  I believe Darren or Norbert may have mentioned the fact in passing in a nugget.  The compiler really is getting that smart (they got some bright minds at R&D)  in 2009 when the IPE came out the optomizer wasn't there-  Backward compatability may be affected if you avoid the IPE.

I appreciate your diligence reporting the bugs-  As a developer I really don't like those glitches but, they don't affect the user so I normally ignore them.  Of course you can always review my thread on new style numerics-  It may be the only CAR I've seen with a 1. ranking  (It could never affect the code and you need to be fixing a boneheaded design descision problem to trigger it.)

BD Comments aren't for the developer anyway-  The maintainer should be happy they exist at all and more so that they stick to objects.  If they miss-behave a bit the code still does not break.

[crossrulz]

---

@JÞB wrote:

in 2009 when the IPE came out the optomizer wasn't there

---

It actually came out with 8.6.  But who's keeping track!

I too remember comments from guys inside of R&D saying how the IPE Structure is becomming obsolete.  For instance, unbundling values from a cluster to change them and rebundle.  The compiler will do that in place, even when not inside of the IPE Structure (assuming you used the same cluster wire for the Bundle and Unbundle).  Not entirely sure how far they have gotten with arrays.

[X.]

New bug: if you attach a label to an object and replace this object by another, the arrow disappears.

For instance:

Replace the Compound Arithmetic primitive by a perfectly legitimate "Subtraction" and you get this:

Welll, I wished the label would actually update its content! At least that would be entertaining.

[JÞB]

---

@X. wrote:

New bug: if you attach a label to an object and replace this object by another, the arrow disappears.

For instance:

Replace the Compound Arithmetic primitive by a perfectly legitimate "Subtraction" and you get this:

Welll, I wished the label would actually update its content! At least that would be entertaining.

---

X- I would expect this behavior.  Same as if I would expect the ISLs content to go away if I replaced as Case Structure with a Stacked Sequence (It would seem like heresy for me to do that so, I have not tried it) But, replacing the object that a comment was linked to with something else SHOULD invalidate the comment link.  In Fact, that is no longer a compound arithmetic primitave in your example.....  It would be really easy to generate some VERY confussing code with missleading documentation if the comment link remained.

Better behavior- if a object with a linked comment is replaced - REMOVE the linked comment durring the replacement to prevent bad documentation!  As long as the comment removal is well documented its pretty easy to unlink-replace-link to preserve a comment AND the developer is THINKING about the documentation as well as the code.

[X.]

You're being funny...

Try this:

Replace the Sequence by a flat sequence. Guess what? The arrow is gone. Totally expected, obviously.

[JÞB]

---

@X. wrote:

You're being funny...

---

Not by intent.  Your own example showed the better practice of "Change the code- Change the comment"  Had you not done so the comment would be erroneous.  Unlink-replace-relink involves consious thought to preserve the comment linkage to the new code.  Replace-Relink makes you think about the comments relation to the new code as well and is acceptable to me.

So repeat:

"Replace-Relink Makes you Think!"

until you believe

Spoiler

Now THAT's funny!

[X.]

I am of the "if the user ask for it, don't do it for him" school of thought.

Now, all I am saying is that the NI programmers who implemented the label arrows did not bother to deal with the effect of target replacement. Good for them, bad for the user.