Aristos Queue

There's an idea I'd really like to see implemented in LV but I haven't got traction for it, so I need kudos from the community if it is ever going to happen. I posted it to the LV Idea Exchange here. Please review the idea and kudos it if you think its worth implementing!

I like to believe that NI was prescient enough 25 years ago to know that classes would be so fundamental to the language that they would put classes on the logo in expectation of their arrival. On the other hand, the logo includes the sequence structure, which casts doubt on the prescience idea. :-) Clearly the blue wire is also an object, and the add primitive supports automatic downcasting.

The standard producer/consumer pattern does this. The producer loop has an Enqueue prim somewhere inside it. The consumer loop starts with a Dequeue prim. Until the producer hits that first Enqueue prim, the consumer loop sits waiting. To see this, go to "File >> New ..." and in the dialog that appears, go to Patterns (or Frameworks in some versions of LabVIEW) and open the Producer/Consumer template.

The last version of LabVIEW released for Solaris was LV 6.0 *I think*. Contact your local NI sales rep and he/she can probably (with a bit of searching) find an installer disk. I don't know cost for older versions -- that's something to ask your sales rep.

NI would prefer if you password protect those diagrams. The mystic ini token may not be the most secure gate latch ever, but it does generally keep the kids out of the briar patch. Scripting is being cleaned up for the next release, and at that point most of the operations that the token hides will be exposed but in ways that are closer to safe. Until then, please latch the gate behind you.

This is NOT true on desktop platforms (Windows, Mac, Linux). Only real-time operating systems maintain the synchronicity of timed loops. On the other platforms, LV will try, but inevitably there will be slippage since there's no real-time guarantees from the OS. True concurrency can be achieved with the Synchronization primitives -- queues, notifiers, rendezvous and semaphores. Sequence structures are to LabVIEW what sentence fragments are to English. Both are so problematic that we have to teach newbies "never use these" and then later we can say, "ok, now you can use them because you now understand how they work with relation to the rest of the grammer." Sequence structures have value, but new users to LV tend to over use them gratuitously and thus end up killing the performance of their code. Similar with sentence fragments. ;-)

As multiple folks have said, in the absence of any data dependency between the loops, the loops will run in parallel as threads become available. One thread may race ahead of the other, one may even complete before the other gets started, and it will be different every time you run the VI. In general, this is highly desirable as it maximizes the use of your available CPUs, thus the answer to your "How can I control this order?" question should be, "Are you sure you want to?" If and only if the answer is "yes" should you try to enforce a particular ordering. Adding a dependency order just to do so only reduces the efficiency of your program and looses one of the biggest advantages of dataflow programming.

Initially we did it because we followed the same rules as VI Server, which does show coercion dots for the hierarchy of control refnums (wire a Knob refnum wire to a Control Refnum terminal and you'll get a coercion dot). Later we figured out that it helped you recognize whether or not automatic downcasting was operating or not. But I'm still in the camp that wishes we had different colors of coercion dots for different cases.

Ok. I really want to know: Why do you need Singleton? What are you using it for? I implemented the example that ships with LabVIEW because lots of people wanted to see some implementation for it. But I honestly am not sure why you want it in LabVIEW. In C++ it makes perfect sense, but not so much in LabVIEW. At least, that's my opinion. Now, you can ask why I would think a construct would be useful in one language and useless in another... I have an answer, but I'd rather not share it at the moment. First I'd like to know what you're doing with these Singleton classes. I have yet to be convinced that it is a useful pattern in LabVIEW.

LVOOP FAQ (includes links to other resources at the end): http://zone.ni.com/devzone/cda/tut/p/id/3573 Excellent 1 hour video presentation on getting started with LVOOP:

If you're facing this situation, I think the correct answer is to eliminate the inheritance relationship in favor of a container class that contains both "parent" and "child" as separate internal objects. Then you are back to only having mutex locking on an entire object.

jgcode: Does your customized version handle the new options in LV 2009 to not include the error terminals and case structure?

Storing this information is what the ContainerState is for. You should put all that info in the ContainerState and then it should just be there without having to muck about with tags.

Yes, it is possible. I did something similar in this XControl. It should serve as an example for you: http://decibel.ni.com/content/docs/DOC-1180

Post a block diagram, please. There has to be a simpler way to do this.

Curiously enough, there was a debate just last week within R&D about whether this was a bug or not. There was no agreement, and those responsible for the differences are no longer around. You should be aware of the following arrow key behavior: It increments whichever digit the cursor is next to. So if your cursor is next to the tens digit, you'll increment by 10. Next to the hundreds digit, you'll increment by 100. In that respect, it is more flexible than the increment arrows. Desired behavior? I don't know. I found it because I changed the increment setting of the numeric to increment by 2, and yet the up arrow still incremented by one. The arrow keys are unaffected by the increment defined for the numeric. The behavior is what it is, and I doubt it will change because someone might want it. But I think (hope) you can build an XControl that intercepts the up and down arrow keys and applies different behavior.

All of the info in the variant's type should be accessible through the VIs in the same folder as GetTypeInfo. In fact, GetTypeInfo should have returned "int32" to you. Isn't that the info you wanted? If there's some aspect of the variant that you can't get from the VIs in that directory, I'd be surprised, since those are the type handling VIs that we in R&D created to manipulate all the types from G. They should be as rich as anything I can get access to in the C++ code.

There's only one case I know of... there's a set of VIs... all of them work on the desktop but only a subset of them work in real-time environment. So there are two different poly VIs, one in the desktop palettes, one in the RT palettes.

A VI has no idea that it is a member of a poly VI (indeed, the same VI can be a member of many polyVIs). The only time you'll see poly VI help is when you're over the poly VI itself.

We're already heavily involved in politics keeping our projects funded. No time for other issues.

Quoting from the Eyes On VIs blog: http://www.eyesonvis.com/blog/2009/10/r-in-r.html Please do not post comments here if you expect the developers to see them. Please post to the blog or to the pioneer website (details below). Note: This isn't my project. I'm just sharing the excitement and helping to broadcast the announcement to users. == AQ ============The LabVIEW Notebook Pioneer================== I'm so excited to be able to share with you the project that I've been working on recently! As far as I know, this is the first time LabVIEW R&D has been able to run a Pioneer program to get customer feedback on a research project. I'd like to emphasize that this is Research. This version of LabVIEW is a Pioneer. That could mean many things, but in this case it means that this version is not approved for production work and the features in it are not guaranteed to be in any future version of LabVIEW. If you see something you like or dislike in this Pioneer, please let us know! This is an opportunity for you to directly affect the future design of LabVIEW. I encourage you to watch these two short videos on the LabVIEW Notebook: (on YouTube) (on YouTube) If you have time to "get behind the wheel," please join the LabVIEW Notebook Pioneer program and try it out. Although it's not actually a Beta, we're running the Pioneer through the Beta Program Resource Center, so to sign up go to ni.com/beta and select the product LabVIEW Notebook. Once approved to the program, you'll receive an e-mail invitation to join a private group on ni.com/Community. That's where you can download the Pioneer and discuss it on our private forum. Note that the LabVIEW Notebook is intended to complement the LabVIEW Project, not replace it. However, if you have ideas for how concepts in the Notebook could be applied to Projects as well, we'd love to discuss them with you!

Well, I have a term for this that I use in the code. I've never had a need to expose users to that term. In general, as in the Error List Window, we talk about run-time type propagation, as in, "The run-time type must be propagated from dyn input to dyn output." We also use "run-time type preservation," which is how the new LV 2009 primitive "Preserve Run-Time Class" got its name. In the code, I call these two terminals "thralled", since the result of the successful propagation is that the output terminal's type is now thralled to the input terminal's type. I picked this somewhat arcane term because it was unique in the LV vernacular, whereas "linked" or "chained" or "bound" had other uses. If you'd like to use that term, I can guarantee that nothing else in LV uses that term, either in the code or in public. To restate this using my terminology... "If the input terminal is successfully propagated to the output terminal then the output terminal is thralled to the input terminal. Given this guarantee, when a subVI is written to take a parent class but the subVI node's input terminal is wired with a child class, automatic downcasting can convert the output terminal to match the input terminal."

The project window should have a bright yellow triangle next to the missing file name. Sorry about that. If you can reproduce it, please CAR it.

Ben: Regarding your original post... you should search the Web for documentation about Genetic Programming. It's a very hot research field at the moment, and breeding algorithms has turned out to be a highly successful way to solve several problems.

Older bugs than that are still unresolved. The priority of fixing any given bug varies. Severe bugs are addressed quickly. Lesser bugs may be pushed off until enough of them are found in a feature to warrant a developer revisiting the code. Some bugs are simply declared "that's the way it works" and left as known issues because fixing them would create other issues. And others we just haven't had time/resources to get to yet.