Aristos Queue

They are orthogonal insofar as the implementations of either do not require stepping on the domain of the other, though they certainly may. A lot of this is philosophy of categorization. There's no right or wrong answer, really. To me, it helps to see them separately because it emphasizes the domain that each has when designing software.

On the question of whether LV is object oriented or actor oriented: Neither, inherently. Both of those are design styles, and they are orthogonal to each other. One speaks to a way of data packaging (object) and the other speaks to a way of controlling execution flow (actor). It is possible to design a system that is pure procedural, purely object oriented, purely actor oriented, or both. Such systems can be built in just about any programming language. Having said that, various languages provide syntax support to make it easier to implement these designs. LabVIEW supports object-oriented programming through the .lvclass files and related features. LabVIEW supports actor-oriented programming through the queues and VI Server systems. The Actor Framework provides syntax to unify the two, though there are plenty of other ways to achieve that effect. As for the singleton pattern... I do wish that pattern would die. Yes, it is terribly useful and I use it all the time in C++. But I also get burned by having used it all the time. The single static instance of an actor/object (because you're treating it as the same thing in that case) makes it nearly impossible to fork two copies of your application or module within your application, and you'd be surprised just how often an app becomes successful and someone says, "Hey, let's run two of these side by side!" and suddenly that easy-to-implement global singleton that was so nice in the original version becomes a liability that is damned hard to refactor because you now have to rewrite your API to propagate a parameter to the far reaches of your program so it can know which of the two former-singleton objects to use.

This will give you the basic idea: https://decibel.ni.com/content/docs/DOC-1180 You have some independent VI that the XControl spins up that controlls the blink rate of each LED. In this case, it is blinking all the LEDs in a particular pattern, but you could easily have them blink independently.

CancellationTokenSource and CancellationToken provide the same signaling functionality. I don't know of anything that has the data transfer built in, but you might look around in the same assembly.

If you have any interest in language design, graphical or textual (because in this case they're hard to separate), you may enjoy reading this article. It contains some very inspirational concepts for any language designer, including computer languages. Ithkuil: A Philosophical Design for a Hypothetical Language http://www.ithkuil.net/00_intro.html

No. LabVIEW will have four viewing sizes and will automatically switch between them every quarter hour, which we feel should give you time to focus on the broad overview (on the hour), the major architecture components (15 minutes past), the individual functions (half past) and the algorithm details (15 minutes before) in good rotation in order to keep your overall application fresh in your mind. The front panel will scale inversely, so that both panel and diagram will be at the same scale at half past the hour. In all honesty... we are years away from even thinking about UI gestures for this. Keyboards may be obsolete by the time it is done. Years. No, I'm not joking, exaggerating, making stuff up or trying to set false expectations.

> What's inside, borscht, kimchi or Chicago hot dogs? Inside? LabVIEW, of course. This is the pot we boil it in so it fits on an RT target. The left over broth makes excellent documentation.

Shut down your computer and head home for the day because the world is ending... I agree with ShaunR on this one. Collect the data as you read, and when you have read all the pieces to know exactly your final type of object, then and only then instantiate your object. You'll probably end up with some sort of "variant with named attributes hanging off of it" to collect as you read and then you'll evaluate the collected attributes and make it into an object.

I recommend the tree data structure Damien implemented to underlie his priority queue: http://forums.ni.com/t5/LabVIEW/Dr-Damien-s-Development-Priority-Queue/td-p/837194

You, mi'lady, are asking for a feature we like to call "Zoom." And, no, there is no way to make LabVIEW itself bigger. Or smaller, for that matter. Your operating system might supply such features (use ctrl+scroll wheel on a Mac and you get the OS and all hosted apps zoomed in... quite nice). The feature to have LV able to zoom its diagrams/panels/etc is one that we are indeed working on, but when you have 20+ years of pixel manipulation code, it takes a monumental refactoring effort, and we are still a few years away from having that graphics layer reworked.

I had two sets at the BBQ for folks to play with, but I did not give them away. :-)

When LV builds just the string array, you get the copy of the array stored by the ring control itself -- no copy is made unless/until you modify the array downstream. Since you are only searching the array, no copy gets made, so it seems fast. When you ask for the array of strings and values, we have to build you a whole new data structure including copying each individual string so that the new data structure is independent of the one in the ring (that's how dataflow works; it is not a bug or something for LV to fix someday). So you see a massive penalty hit. You can maintain this data structure yourself, as various people have pointed out, in diagram local storage, like a shift register on your event loop (I wouldn't use an LV2-style global unless you really need this information elsewhere in your program and not just on the local diagram). Then, yes, when you make a change to one data structure, you make the same change to the other data structure.

This CAR is noted as already fixed in LV 2012.

Antoine: That JKI mass compile tool... I never saw it before. It is described as being for LV 8.0. There were a lot of issues in LV 8.0. Is that tool still relevant at LV 2012? Has the built-in mass compile come up to speed with the JKI tool? Or is there still a difference?

If we named it "index (last element)", that would be a lie. It is only by being unwired that you get the last element. There is no value you can pass in that will get you the last element. And it is named "index 0" in the context help because there are N indicies depending upon the dimensionality of the array, and the CH is trying to depict what happens for any dimensionality of array, but when you wire a 1D array, the terminal -- as it is on the diagram (see tip strip) -- is just "index" because there is no additional terminal that we need to differentiate.

This seems like a good CAR to file. Filed as CAR #377978.

Interesting conjecture. I'll keep it in mind if I ever have to dig into one of those systems.

Weird. The constant size thing can't be the issue... after all, the waveform itself contains a variable sized array for the numbers. The array of variants shouldn't have any impact. Can't explain it, but useful to know. The attributes are just another field of the cluster, it just gets exposed on the block diagram differently. Still just a cluster.

Citation needed. I'm not saying you're wrong, but there's nothing in the design of the RTFIFOs (they share a lot with the Queues) that would necessitate this, so I'd be surprised. It may be something in the transmission requirements that I'm not aware of. Please test and confirm this.

Nope. Those don't return errors. :-)

> What other conditions could cause a close function to fail > besides having an invalid or previously closed input reference? That's the only one.

Waveforms are clusters.

That's exactly the problem. I do not know of one and I have been trying to research it, but I am not a lawyer, so it is slow going. My original post was because I know of only one existing mechanism that works under US and international laws, for various reasons. Most long-term solutions seem to require the transfer of IP, the way the Creative Commons OReiley group does by buying it from you for a dollar and then licensing it back to you. It was not meant to rule out other possibilities, but upload to ni.com (or some variation that requires IP transfer) is the only solution I have thus far found.

Need a source of true random numbers? Here's an excellent source, assuming you have an Internet connection available to your application. What's the National Instruments connection? The system was developed with NI PXI systems and LabVIEW. https://decibel.ni.com/content/groups/sweet-apps/blog/2012/10/22/never-pick-your-own-lottery-numbers-again The online generator mentioned by the article is here: http://qrng.anu.edu.au/ This sort of begs to be packaged into a single "Get Real Random Number From Internet.vi". Very handy utility for lots of applications!

There's no VI that falls into that category. There's no DLL that isn't core to LV itself that falls into that category. In short, everything that currently ships with LV that falls in that category is installed by LV and thus requires no secondary notation from a user. A VI in vi.lib is not part of the runtime engine and so would require separate acknowledgement by any EXE that used that VI.