Make FlatSequence part of MultiFrameStructure class

[jacemdom]

The FlatSequence structure was not classified as a MultiFrameStructure but was put in a class of its own. This causes the creation of "exception code" that would not be necessary if the FlatSequence was a MultiFrameStructure and could be processed with generic code. Issue was discussed here, it was decided that the investment to fix this was to high. I believe that the longer NI waits to fix it the higher the cost will be and the higher the cost associated with treating the exceptions cases will have become. I also believe that someday this will actually prevent NI to create more efficient code, i know it has prevented me to do so.

[Darren]

I've never used that property before. And yes, it behaves strangely. I can take the 'Node' reference that comes back from that property and cast it to FlatSequenceFrame, but if I then try to cast it back to Node, I get an error.

There are other little wierdsies in scripting too, like how you can use Type Cast to convert an ArrayConstant to an Array and use Array properties on the constant that otherwise aren't in the ArrayConstant property list. 😕

[AristosQueue (NI)]

A node, by definition, waits for all of its inputs to be available before executing, then produces all of its outputs.

Flat sequence is not a node. It cannot be a node because its syntax doesn't match that of a node. Consider this diagram:

If flat sequence was a node, this would be a broken diagram. Maybe it should be a broken diagram, but that isn't how it was defined. Each individual frame is an independent node, which means you can run code in parallel to the sequence. That "5" will definitely be after the "1" and before "4", but you can't say where else it'll be in the final array from just looking at the diagram.

[AristosQueue (NI)]

> It's the Diagram FiringOrder property that returns [nodes], including FSFs.

That's a bug. We should fix that. I'll file it.

(Bug 978482 to deprecate the property and introduce a new property whose return type is GObject.)

[wiebe@CARYA]

>A node, by definition, waits for all of its inputs to be available before executing, then produces all of its outputs.

A Flat Sequence Structure Frame does fit that description 😁.

I have code that uses the FiringOrder. It's just a pet project\thought experiment that converts G to C++. Way to much for me to finish. Gained lots of appreciation for LabVIEW in the process. Especially the polymorphism, nD arrays, memory management and LV-like threading isn't easy in c++. Had lots of fun with shift registers and feedback nodes as well.

FiringOrder is quite convenient for code like that. I'm not sure what the fix would be. If FiringOrder would return GObjects, that would fix it, without loosing it's functionality.

[Intaris]

For what it's worth, I find the behaviour of the sequence structure counter-intuitive.

It looks like a single structure but is actually a series of structures whose execution order is serialised.

This has caused me some head-scratching over the years as I generally make the same error every now and again. For me, the problem is the top and bottom frame suggesting a single behavioural entity whereas each frame upper and lower border is actually independent.

Maybe some better visualisation that the frames are essentially independent would help understand that?

Split frame

[wiebe@CARYA]

It's a weird structure. But a wealth of trivia and CLAD questions. Like "how long does this take?".

It also prevents generalization of statements, like "all structures stall execution until all connected input wires are 'fired'". (Most nodes do too, but not all.)

I'd say your (Intaris) suggestion is an improvement, but wouldn't mind if he structure was removed altogether. I'm not sure if it will be back in NXG. IIRC, it's just hidden even better.

[AristosQueue (NI)]

> I'm not sure if it will be back in NXG. IIRC, it's just hidden even better.

It is in with all the structures in NXG. Not hidden.

[wiebe@CARYA]

>It is in with all the structures in NXG. Not hidden.

Ah, it's the stacked sequence structure that's hidden in CG.