Aristos Queue

Ok... I'm about to do something very out of character. I'm going to give some advice about the unreleased features of LV. For the love of all things holy, do not use external nodes. Use XNodes.* Build on XNodes. Write poetry to your XNode. But do not attempt to propagate the entity known as the external node. Shun the ;D prefix. It was a useful research project in "what not to do." We learned much from that research. And, having learned, we now abandon. National Instruments is re-writing every single toolkit that uses external nodes to use XNodes. We are switching off that technology as quickly as we can find staff to do the rewrite. And that means at some point we really will switch off that technology -- some future version of LV will ship from NI stripped of the code that supports that tech support nightmare (internal tech support of course... external tech support doesn't support unreleased features, X or external). And now this LV developer will return to his usual principle of denial: "What XNodes? I see no XNodes in the feature list..." * Yes, I would turn on "blinking" for this bit of feedback if LAVA had such a font setting. I mean it. Do not use external nodes. Bad juju. Bad.

Your suggestion about the Automobile example is an excellent one worth implementing. I take it then that the Board Testing example that ships with LV wasn't helpful. I know it has flaws, but it's the best anyone has been able to do to highlight the changes that OO brings to code. Any ideas for improving it? *ahem* May I direct you to the opening paragraph of this ...

A cluster or enum should be a typedef. A typedef should be a LV class. LV classes should be improved so that the previous is practical. Event structures are better than polling loops. LV makes UI easier, but even so, good programmers are not necessarily good UI designers. Figure out which you are and ask for help if necessary.

Link seems to work for me and others now... perhpas server had a hiccup. Yes, the link is to the ni.com LVOOP FAQ. (and thanks, crelf, for adding it to the LAVA FAQ). LabVIEW classes are not, in LV8.2, available for download to the real-time targets (embedded, FPGA, Pharlap). They are fully supported on Mac, Windows and Linux platforms, in ALL the development envrionments (base/full/pro) and in the run-time (built app) environment.

I can't believe I haven't posted this link to LAVA before: http://zone.ni.com/devzone/cda/tut/p/id/3573 This is the LVOOP FAQ. It answers a bunch of questions and, at the end, includes links to tutorials, examples, Powerpoint slides, etc.

Addressing Rolf's concerns... It would need to be a setting on a per VI basis, since you'd want the setting saved with the VI so that if it was distributed to another machine that other machine wouldn't turn the optimization back on and break the VI. We could handle it a lot like the alignment grid settings -- the Tools>>Options setting applies to new VIs and then each individual VI records the grid size that it was constructed with so that on different machines the VI keeps its grid. It's not a bad suggestion. I'll pass it through.

If you're doing anything with RT/targets, you *have* to distribute the project. It contains all the deployment information. I don't really use RT, so I'm not sure how people share systems like those (after development they have to be duplicated to many systems, right?), but I can tell you that there are definitely cases where the VIs would execute differently in the absence of a project than in the presence of one.

FYI, ater having been in the public domain for 2 releases, we've collected enough feedback that the project should be getting a nice polish in one of the next releases. Not sure which one, but there's work actively going on there. On your comment that we're forcing you into the project: It is certainly true the that the project is now *the* place for configuration of LabVIEW deloyments -- whether that be deploying to an RT target, building an EXE, or configuring a remote machine. That was a deliberate decision because the complexity of many tasks was too much for simpler command structures. We had bug reports and feature requests galore, and LV needed a richer environment to respond to those reports/requests. Everyone has complained for years about every VI being its own window and there not being a central place to look at to see your application as a whole (the VI Hierarchy window doesn't count for most people). The project provides that (and will provide that better as time goes by). Reentrancy raises another issue. The demand for debuggable reentrant VIs was huge. That requires that each clone have its own front panel and block diagram, so they can be individually inspected/probed/stepped/etc. So now you have a window management issue worse than before. We did provide ways of working out side of the project -- there's a major faction of LV developers dedicated to making sure that LV stays usable without the project window, at least for general editing of VIs. But the project does a nice way to guarantee that you got the original VI. That's not NI forcing the use of the project. That's the project being as useful as it can possibly be.

This is both true and untrue. Let's look at inplaceness. If we didn't optimize memory usage, LV becomes unusable. Quite literally -- the "ideal" form of a data flow language is that every wire is its own independent allocation. By analyzing the flow, we can identify when memory can be reused. LV 6.0.1. was released. LV 6.0.2 was released about two weeks later because we had a bug in inplaceness for bundle/unbundle nodes. But even if the bugs were dire, we wouldn't turn off inplaceness. We'd fix the bugs. That's the part I don't understand about this thread. LabVIEW is a compiler. Every node you drop generates some amount of assembly code, just like every line of C code generates assembly code. An optimization bug is no different from a functionality bug. We redid the queues/notifiers in LV6.1 to be language prims instead of CIN nodes. There were a couple of deadlocks in the queues/notifiers in that first revision (fixed in LV7.0). But finding such a bug doesn't make everyone question the functionality of LabVIEW, just the intelligence of the fool who wrote the queue/notifier code. Finding the constant folding bug makes everyone panic. I find that odd. I guess my point is that any bug in LV is a functionality failure, and I'm not quite sure why the constant folding bug raises more concerns than any other bug. It needs to be fixed, sure, but obviously a whole lot of VIs work just fine in LV8.2, despite this bug, even VIs that have constants on their diagrams. LV8.2 would've been hard pressed to ship out the door otherwise. Optimization of code is becoming a major issue for LV. We've coasted for a long time by being a highly parallel language and thereby staying ahead of C in performance in a lot of routines. But parallelism is less of an advantage as the processors become more parallel themselves and other compilers optimize out entire chuncks of code. There's many multiple of optimization features behind the scenes in the last couple releases of LV. For example, everyone praises the 50x speed improvement in the LVVariants. Would you rather we didn't attempt that? It was entirely possible that we would get it wrong and variants wouldn't work correctly. It seems we got it right. But the push against constant folding smacks of "this is something that LV has done that was so risky I can't believe you exposed users to this!" That's overreacting, to me.

Ctrl+m opens the original. If you then start editing, the clone goes away on its own. No slight of hand needed.

Can't find that CAR number... but I did find one with a very similar CAR number that includes a link to this post. That CAR is 45E85U1Y. I think we've got enough to identify what's up, so no need to post any further code.

See here.

See here.

See here.

Kring has posted a tidal wave of bugs against this VI. http://forums.lavag.org/index.php?showtopic=5780 http://forums.lavag.org/index.php?showtopic=5807 http://forums.lavag.org/index.php?showtopic=5804 http://forums.lavag.org/index.php?showtopic=5802 I'll ask the original author of the VI to take a long hard look at it and see if the example can be improved. I do own the Notifier primitives, but this particular example was written by someone else -- I asked that it be included in the shipping LV because the functionality gets asked for from time to time.

This was reported to R&D (#45BGR0J1) for further investigation. It will be fixed in the next full release of LV.

No, but it seemed like an interesting question to ask. I'm not sure why... call it "basic research" -- something that seems useful to know even if you can't say why at the time the question is asked.

A) Have you posted this to DevZone? You're a lot more likely to get an NI AE to help there than here. B) What version of LV are you using?

Are you being obnoxious on purpose or by accident? Your statement seems like a deliberate flamebait. [LATER EDIT] Sorry, Joris. My original reply was uncalled-for and has now been edited. But your comment really doesn't make sense. What's the difference between constant folding and any other compiler optimization?

How about LVXXX for "LabVIEW XObject-XOriented XProgramming"? (this is pronounced L'vexsssssss, by the way)

I forgot to mention an idea I had and today's post to this thread reminded me... Everyone talks about keeping the project small. Suppose the challenge was this: Some LAVA zealot creates a simple app that does XYZ. The challenge is simply to add a feature to the app. Any feature. This way a person can bite off as much or as little as they choose. Competition is judged on best feature added. The general framework already exists, so there's less of the "blank diagram syndrome". Maybe there's a cool bit of UI that another programmer could convert to an XControl. Maybe the program needs a faster core algorithm. The options are wider for what could be worked on and there's less of a "this is the right answer and if you haven't gotten to this point then you aren't done" which tends to make for long hours of programming to hit a specified target. We could start with any of several items in the Code Repositiory. This would take us away from algorithmic challenges -- which depend heavily on programming experience and moments of eureka to solve -- and moves us towards expansion of LabVIEW -- which anyone might be able to contribute to from the parts of LV that they happen to know.

When you get the bug report number (ask the AE you talk to for the CAR number), please post it here.

Ben: please repost your question as a new discussion topic. I think it is worthy of being a top-level post, and it is certainly off topic for this thread. But it's a good question.

The VI also works correctly if you popup on the 2 that is wired to the Index Array and select "Change to Control". The bug seems to be something in the constant folding. I'll let JeffK know... did you already file the bug with NI?

When I think "X" anything, I think "Marketing."