Aristos Queue

8.5 and earlier: VI Property "Callees" 8.6: VI Properties "Callees' Names" and "Callees' Paths" [The previous "Callees" is equivalent to "Callees' Names"] Start at your top level VI and visit down the hierarchy.

I agree. It was the first feature request I made to LV years ago. No one ever sees it as a high enough priority.

QUOTE (Darren @ Mar 25 2009, 11:33 PM) Because not renaming them is intended behavior. :-) I can agree that it might be nice to have a tool to visit all of the overrides and rename them all in parallel, but not renaming them all is just as valid a use case, one that I've needed frequently.

Quick note: "library" is not the same as "llb". LLB officially is an acronym without meaning. Library refers to .lvlib files. NI made this change to the standard technical vocabulary in LabVIEW 8.0 in 2005. This detail is important because I was going to give you completely the wrong answer. LabVIEW does have built in ability, starting with LabVIEW 8.6, to do Merge of VIs both inside and outside of LLBs, and to merge new VIs from one LLB to another. That is built into LabVIEW.exe. There is a tool somewhere for teaching Perforce to call LabVIEW when there are LLBs or VIs that need comparison, and to automatically start LabVIEW in comparison mode, but I cannot tell you where that tool is... perhaps someone else on the forums knows.

If you have ever wanted to know the details behind how NI evaluates and fixes bug reports, this blog post from NI's John Pasquarette should answer your questions. What is our bug-fixing process If you have any feedback about this post, please respond on his blog instead of posting about it here on LAVA -- that will keep the comments centralized instead of spread across three different forum sites.<p>

QUOTE (Ton @ Mar 25 2009, 04:36 AM) Why? There are various uses of the project, most notably building an app, that does not involve opening a VI (note I distinguish loading a VI vs opening a VI, since AppBuilder obviously must load VIs). The project loads the pieces it needs as it needs them.

My bet: Source code control and/or installed LV modules. The first time you open a VI in a project, if you have SCC enabled, all the SCC VIs that manage that connection load into memory and then stay there. The various LV modules (real-time, FPGA, PDA, etc) can also add plug-ins to the project that respond to the loading of VIs.

QUOTE (gmart @ Mar 18 2009, 07:20 PM) XControls (.xctl) are another kind of library that load all their member VIs. I do not know the behavior of StateCharts (.lvsc).

QUOTE (Matthew Zaleski @ Mar 23 2009, 10:00 PM) No, it isn't. LabVIEW is a compiled assembly language. The engine simply exists to schedule blocks of code to run. There is not a JIT compiler or a script interpreter underlying LabVIEW. Some of the optimizations that C++ can do LV cannot because those optimizations would cross clump boundaries (clump == chunk of nodes that are scheduled to be run as a block before offering the thread a chance to go pick a different clump, possibly on a different VI running in parallel). But you'd be surprised I think just how many of C++ optimizations are possible within LV, and we have a few tricks of our own that C++ can only dream about. When the next version of LV comes out, we'll have some new surprises in that arena. Sometimes we can piggyback on C++. There are some nodes on a VI that are compiled into assembly that calls back into the LV engine -- essentially precompiled chunks that are written in C++ that the VI does a call and return to access. Those are exposed in the runtime engine lvrt.dll. The PDA and FPGA targets go even further, not relying upon the lvrt.dll at all and generating the entire code structure of the VI hierarchy in their code. We could do the same thing on the desktop, but it is more efficient for VIs to share those large blocks of common code than to have every VI generating the assembly necessary for every operation. But an Add node turns into an "add ax bx" assembly instruction.

QUOTE (Ton @ Mar 22 2009, 12:31 PM) You should be aware that the solution you have hit upon won't detect all types of libraries. There are (currently) five library types: .lvlib, .lvsc, .xctl, .lvclass and the mythical one that some LAVA users believe in. Of these, all but .lvclass can have libraries inside of it (a limitation that would be nice to remove but is not scheduled to be worked on any time soon). You probably want to make this work for all the types, not just .lvlib, which is what testing for "Library" as a type string does, including any future types that LV may introduce. Do I have any idea how to do that? No. For the record, I am not a fan of any of the ProjectItem API, but here's something that might help you in this particular quest: http://lavag.org/old_files/monthly_03_2009/post-5877-1237749800.png' target="_blank"> I have no idea why there is no "Open By Name" method.

QUOTE (Val Brown @ Mar 21 2009, 03:37 PM) Ah, the ancient hacker ethos question. I have to admit ... threads like this leave me torn between cheering on clever applications of software and admiration for those who can make the trick work concern for the ethical problems that such hacks raise and dread of the bug report when someone does figure these doors out that mean those of us in R&D have to be even more clever next release. Honestly, I think the best solution is to cleverly figure out the trick and tell no one *except* NI. Under those conditions, you can legitimately claim to be working to make LV better by exploring its weaknesses, and if you happen to learn how certain VIs work along the way -- such as picture to pixmap -- well, that's just a side-effect of your other efforts. Think of it as reward for research. Of course, under such a model, anyone who did figure a trick out wouldn't post it to the forums. ;-)

QUOTE (neBulus @ Mar 21 2009, 07:37 AM) I'd counter with the question: who is really the owner of those refs if they have to outlive the state machine? And, actually, it doesn't need to be the top-level that is responsible for those refs. We could have a wrapper around the state machine that is responsible for the refs used by the state machine, and the top-level calls to the wrapper. The encapsulation would then hold.

QUOTE (flarn2006 @ Mar 21 2009, 11:00 AM) Not in the way you used to be able to do... If you hunt around on LAVA and elsewhere, I'm sure you'll find the latest workarounds.

QUOTE (flarn2006 @ Mar 21 2009, 02:29 PM) Ah, but we can, and have, randomly changed things between versions, just on the off chance that something is working that shouldn't be. :-)

QUOTE (bsvingen @ Mar 21 2009, 01:25 AM) We call that an array.QUOTE (Aristos Queue @ Mar 20 2009, 04:15 PM) Grrr... A bug report against the documentation will be filed shortly. That should read: It appears this documentation was already changed in LV8.6. You must've been quoting an earlier version of the Obtain Queue documentation. In any case, it was wrong no matter which version of LV you were using Obtain Queue.

QUOTE (Michael Aivaliotis @ Mar 20 2009, 10:56 AM) It's that last bit that I'm contemplating -- designing for abort. If you design the state machine to be aborted. Yedinak mentioned a bunch of stuff besides references that may need to be cleaned up. All of that could be back in the main VI, sitting right after the call to the Run VI method. Your biggest danger is still with the hardware interactions -- don't let anything I post here dissuade you from that. But I am suggesting that "Never use the abort button" is very different from "never use the Abort method", maybe. The Abort button you might use on just any VI, with no clue as to what you're aborting or how safe it is. The Abort method you'd be laying in as a deliberate stop mechanism. Anyway... idle musings from a C++ programmer. One of you G programmers should explore this idea and let me know how it turns out.

QUOTE (flarn2006 @ Mar 20 2009, 06:32 PM) Nope. When VIs are run, the assembly code that the compiler produced is executed. The block diagram never even gets loaded into memory. Heck, it isn't even saved as part of the VI when you build for the Run Time Engine.

The token no longer works after LV 7.1.

QUOTE (Gary Rubin @ Mar 20 2009, 12:19 PM) Grrr... A bug report against the documentation will be filed shortly. That should read: QUOTE max queue size only limits the number of elements in the queue. It does not preallocate that many elements in the queue. If you want to preallocate your queue, enqueue that many elements and then flush the queue. The space, once allocated, will remain allocated for further use of the queue. Enqueueing and dequeueing resizable data types, such as paths, strings and arrays, do not affect the memory of queues. The queues are used to move data around, but they do not generate copies of the data.

QUOTE (Neville D @ Mar 18 2009, 04:45 PM) Ok, but those references could be open and closed by the still-running, not-aborted UI VIs. The state machine that's doing work that needs to be stopped doesn't have to do the cleanup. If you can't open all the needed references before the state machine starts running, you could have the state machine call back to the original VI hierarchy (though posting a message and waiting for response using two queues or user events) so that the orig hierarchy can open references on the state machine's behalf. That way those references survive the abort. Then when it does abort, the original VIs take care of closing any references that weren't closed explicitly by the state machine. I'm still not saying this method is good or bad; I'm just walking through arguments to see if this path works. It seems like a more effective way to stop a process than having to code boolean checks all over your code, especially when LV has such nice hooks right in the assembly code at the end of each clump of nodes to detect abort.

QUOTE (shoneill @ Mar 20 2009, 02:25 AM) Naturally. :-)

QUOTE (shoneill @ Mar 19 2009, 04:59 PM) Yes.The child class does not record whether the VI is an override of the parent or not. It doesn't care. So if the parent adds or removes an implementation, callers of the child class don't care.

Another solution would be having the UI be VI A and the state machine be VI B and instead of calling VI B as a subVI, call it using a VI Reference and the Run method, then when user hits the STOP button, you call the Abort method of the VI reference. Your app as a whole keeps running, but that state machine stops. Is that more or less dirty? Can it be made acceptable somehow?

QUOTE (jdunham @ Mar 17 2009, 03:20 PM) No. The way to safely use the binary data file functions is to write down information as a header that you can recognize the correctness of the file as one of your own files. What behavior would you want from LabVIEW? Should we secretly record some random bits that LV checks that says, "Yep, we wrote this file." That would make it mighty hard to output some specific file format -- for example, a .png file. If LV output those secret bytes in the heading of every file, you'd never be able to write a .png. Or any other format. QUOTE There's no reason except for bad file format design that a proprietary format can't have a header that identifies the file type and some kind of data validation scheme. Except the LV binary prims are NOT designed to output a proprietary file format. They output the binary strings as requested by you, the user. QUOTE Both my local graphics editors put up an error: "This is not a valid PNG file." (more or less). And I guarantee that I can put together a file that wouldn't. As I said, it matters how close to being a valid file it was. PNG is probably not the best example. But there are plenty of graphics formats that are packed up, that assume they need to be unpacked, and you can put data in that will make the system think it needs to unzip as a gigantic system.

QUOTE (Ton @ Mar 17 2009, 04:42 PM) I forgive you. But I can't really explain it. I don't remember why it was done.QUOTE How does this go for LabVIEW 64 bit? is the padding than 8 bytes? No change. It would be a real problem if it was changed. The format for flat information has to be the same no matter where it was flattened so anyone can unflatten it.