Aristos Queue

I've posted an example to NI.com that does this: http://community.ni.com/examples/scrolling-led-xcontrol

I'm pretty sure that OpenG has some better array sorting/searcing VIs that let you pass in a VI Server reference to do the comparison, so you just write a compare function that compares the desired element of the cluster and returns greater, equal or less. I saw something like that on Jim Kring's screen when he won the LV speed programming competition at NI Week a couple years ago.

QUOTE(zoogies @ Jun 25 2007, 01:11 PM) No. And you're not the only one who wishes for such a tool.

QUOTE(jzoller @ Jun 22 2007, 01:40 PM) The probe would have to be the VI that *opens* the refnum. A refnum goes invalid when the VI that opened the refnum goes idle even if you pass that refnum to some other VI by some means. The other VI can be using that refnum and the number will start returning errors for invalid refnum when the original VI goes idle. With something like the queue or notifier refnums, you might be able to look up the item's name and open a new reference to the same item. But for file refnums and similar, there's only one refnum and when it goes stale, there's no other way to get the reference.

QUOTE(Jim Kring @ Jun 14 2007, 08:59 PM) If we were protecting you from infinite recursion at runtime, you'd be correct that we were just protecting you from yourselves and being over-parental. No, the problem was infinite allocation at compile time. Just the act of dropping a node would create infinite allocations. The definition of reentrancy -- every node has its own instance to execute. If every node has one, then it's like staring into a mirror just to initialize the VIs.

QUOTE(crelf @ Jun 11 2007, 06:43 AM) I don't.

QUOTE(Tomi Maila @ Jun 11 2007, 06:18 AM) *grin* *rolling of eyes* Some users are never satisfied. In any case, good work, gentlemen.

QUOTE(Jeff Plotzke @ Jun 10 2007, 05:24 PM) No. I'm not sure why Rolf thinks the assembly code isn't in there somewhere. The assembly code for all the VIs is definitely in the EXE. The initial code is going to start the EXE, and then start executing "clumps" of assembly as they become available to the thread scheduler (the top-level VI schedules its initial clumps to run... as each clump's inputs become available, they join the list of clumps that can get executed). LV doesn't have a call stack for subroutines -- just the scheduler picking up a clump, executing it, then scheduling the next batch of clumps. Anyway, the long and short of it, there is assembly code in there for the VIs. I don't know why you're not seeing it. This is probably the sort of information that you're not supposed to know -- because you're not supposed to be reverse engineering the assembly according to the license agreement -- but I figured I'd tell you because I don't want some rumor to start up that LV is somehow an intermediate interpreted language like JAVA. That sort of nonsense would just contribute to perceptions -- right or wrong -- of LV as not a real language and too slow for real work. LabVIEW is a compiled language.

QUOTE(Michael_Aivaliotis @ Jun 9 2007, 08:17 PM) Yes.

LabVIEW classes know how to translate old versions of themselves into the current data format. Typedefs do not have this expertise. So if you flatten an instance of a LV class, then edit the class (add a field, reorder the fields, delete a field), and then read the old version, the same changes that you made to the class (add a field, reorder fields, delete a field) will be applied to the read data in order to make it match the new version (any added field is added with the default value). QUOTE(tcplomp @ Jun 9 2007, 12:41 PM) A bit over 4 hours...

QUOTE(torekp @ Jun 6 2007, 06:50 AM) That would be the version of the class file itself, not the version of LabVIEW. Be careful not to confuse these two version numbers. LV8.2 has annoying behavior that frequently (but not always, which while still wrong would at least be less annoying) when you build a class into a built app, the version of the class in the built app has its version bumped and is no longer the same as the version used in the dev system. So one place that you might encounter the error you posted is when trying to use a built DLL in the development system. Your dev system has class version 1.0.0.0, and the class in the built DLL is version 1.0.0.1. When data tries to pass from the DLL to the dev system, the dev system doesn't know how to handle the data -- the data is from a version of the class that the dev system doesn't know about. (Data can pass from the dev system to the DLL because the 1.0.0.1 version has instructions for how to load and mutate old version of the data -- in this case, no mutation is necessary because the data types are actually identical, but the dev system has no way of knowing that fact when it tries to unflatten 1.0.0.1 data). The use of classes in built apps has been hammered inside NI over the last couple months and there'll be significant improvements in the next full version of LV released. For now, there are a number of posts on DevZone and here that may help you figure out a workaround now. You should probably move this post over to the GOOP forum and have a separate thread. Various folks on that forum may be able to suggest a workaround for you. It's a definite tangent from this thread on 8.2 vs 8.2.1.

QUOTE(Gavin Burnell @ Jun 5 2007, 07:06 AM) Amortized growing vs allocating on every iteration... I don't actually know which one the while loop does... I'd assume its the smarter of the two. But the details weren't really relevant to my point -- it doesn't have oracular abilities, so there's reallocation at some point regularly during the execution of a while loop. Even the smarter of the two algorithms is still less efficient than the For Loop and would account for the recollection of user eaolson. QUOTE Is the compiler intelligent enough when looking at a loop to work out if the iterator terminal is unwired to not bother generating code to produce the iterator output, or would that explain why the array operation is faster ? Yes. QUOTE On the original topic, what would be very handy would be if index array and friends took in a cluster of n-numerics to index a n-dimension array. Particularly handy for working with 2D arrays of images if one could wire in 'points' and 'bounds' type clusters to pull out points and subsets. At first I thought you just wanted the functionality of the "Cluster to Array" primitive. But you're actually talking about being able to index the cluster, not necessarily convert it to an array. An interesting idea.

QUOTE(eaolson @ Jun 4 2007, 01:42 PM) I think you're thinking of a *while* loop. In a For Loop, since we know at the start how many elements will be needed, the output array can be allocated right away. With a while loop, it gets reallocated on each iteration to grow as needed.

QUOTE(Gary Rubin @ Jun 4 2007, 09:44 AM) Try putting the random number generation node *outside* the loop and then wire it through the loop tunnel. That should give comperable results to wiring the array directly.

QUOTE(Tomi Maila @ Jun 1 2007, 01:27 AM) We are not using any intermediate language.

QUOTE(eaolson @ May 31 2007, 09:53 AM) Just like any compiler for any computer language, the source code of LabVIEW (the block diagram) is translated to assembly instructions that the computer can actually execute. The Add primitive generates machine code instructions to load values into registers, add them and store the result back to memory. The Queue prims generate considerably more complex assembly code. Ultimately, machine code is the only language the computer understands. Some routines in LV are prewritten. An example would be the Scan From String primitive, which generates assembly code needed to call an already written section of machine code stored in either labview.exe or lvrt.dll. But if all we did was string together prewritten functions, the code would be pretty slow to execute. The compiler translates the nodes/wires on the block diagram into code that is as optimal as the compiler can figure out to make it. Of course, when we compile a VI for a target like PDA or FPGA all of the code has to be generated. There are no prewritten routines on those platforms.

QUOTE(eaolson @ May 31 2007, 10:01 AM) One of our intern T-shirts says this... There's also another intern T-shirt that says "The End of the World is NI". ;-)

QUOTE(Ben @ May 31 2007, 10:13 AM) *grin* The algorithm has many specifications for what it has to do. But how it does them... well... if you come to NI HQ on Samhain/All Souls Night, when the barriers to the spirit world are thinnest, you can hear the whispers in the wind that tell us lines of code to change. Some developers hear better than others, and they enter a sort of trance that allows them to change obscure lines of code. At any other time of the year, staring at those lines of code is much like staring at a Rorshach ink blot.

QUOTE(Mike Ashe @ May 31 2007, 09:37 AM) I don't. Maybe NI does somewhere.

Zen Koans teach that certain yes/no questions can only be answered with "mu". The classic example: Question: "Have you stopped beating your wife yet?" Answer: "Mu." "Mu" unasks a question that is based on false assumptions. The above question not only presumes that you have a wife, but also that at some point you started beating her. If you don't have a wife or never started beating her, then both yes and no would both be misleading answers. QUOTE(Ben @ May 30 2007, 02:43 PM) The answer to your question is "mu." Can you puzzle out the incorrect assumptions built into the question?

QUOTE(Gary Rubin @ May 31 2007, 07:45 AM) What would make it slower than a native capability? Let's say we did make the Index Array have the behavior you request. The code under the hood would be something similar to the G code. For example, your array of int32s as indicies would be something like: outputArray.capacity(indexArray.size()); for (i = 0; i < indexArray.size(); ++i) { outputArray.push_back(inputArray[indexArray[i]]); } All the same stuff you'd do in G. There may be other reasons to add this functionality to the Index Array primitive, but speed/performance isn't a valid reason (IMHO).

QUOTE(JanJorgensen @ May 24 2007, 02:56 PM) Man, LVClasses have only been available since August! We'll have a "best design" for a lot of things ... in about three years. At the moment there's a scattershot of "things that R&D put together that seem to work well" and "things the early adopters (such as Tomi) have attempted when the R&D stuff failed to meet their needs". What you see in the shipping examples and postings to LAVA is pretty much the extent of things at this point. If you do hit on a really clean implementation, post it --- and in a couple years we may be pointing to your design as the "best" recommedation.

QUOTE(Michael_Aivaliotis @ May 23 2007, 04:59 PM) Brainstorming ideas: 1) Did you change .ini files such that "load palettes in background" was changed to "load all palettes at launch"? That's an option in Tools>>Options>>Palettes. 2) Have you got a bunch of toolkits installed that aren't mass compiled? (Not that I can explain why those would be loading as part of launch.) 3) Is it at all possible that you installed 8.2.1 and then used an 8.2 on another computer to mass compile your 8.2.1 install? Or something bizzare like that? I'm really at a loss to explain such a slowdown. Those are the only ideas that I can come up with.

This was reported to R&D (# 49MCUJJ1) for further investigation.

QUOTE(crelf @ May 23 2007, 10:20 AM) What about dinner afterward at 8pm? Salt Lick is open late. (Yeah, I know, there's an 8am keynote, but that's 12 hours away...)