Aristos Queue

I've never heard of this bug. I could not replicate it in 8.2 or 8.6. Is there something special about the particular class that you are updating?

QUOTE (Aristos Queue @ Jan 7 2009, 05:03 PM) This bug will be fixed in the upcoming bug-fix release of LabVIEW.

QUOTE (Aristos Queue @ Jan 7 2009, 05:03 PM) This bug will be fixed in the upcoming bug-fix release of LabVIEW.

This bug has been confirmed in LV 8.6. It has been filed as CAR 139602.

QUOTE (Tomi Maila @ Jan 7 2009, 01:45 PM) You can turn off autopopulating folders to resolve conflicts. That's possible today. What we're asking about is whether turning them off should be a side-effect of saying "use this VI" when the VI you choose is not in the autopopulating folder and conflicts with another VI that is in the autopopulating folder.

Have any of you filed a bug report? If not, please do so with VIs/lvproj files attached that reproduce the bug.

A logical impasse exists between two highly praised LV features: the autopopulating folders in the project and the cross-link detection/resolution tools. Both of these came into existence in LV8.5. (Author's Note: I should mention that both of these features are highly praised by people who only use VIs, not by people who use both VIs and libraries, but we're working on that...) Situation: Alpha.vi and Beta.vi both call Gamma.vi as a subVI. Alpha wants to load c:\Gamma.vi and Beta.vi wants to load d:\Gamma.vi. The conflict is between two VIs of exactly the same name but at different paths being listed as part of the project. The user needs to either pick which Gamma.vi to use in the project OR remove all references to all but one version of Gamma.vi, making that one the only version of Gamma.vi listed in the project. The trouble arises when the user tries to pick which Gamma.vi to use. Suppose that the project has an autopopulating folder for c:\, but the user says "Use d:\Gamma.vi for this project." (This reportedly happens somewhat commonly.) The project cannot get rid of c:\Gamma.vi because the file is in the autopopulating folder and the project has been told to keep everything in that folder up-to-date. And so, with this in mind... please answer the questions.

QUOTE (Jim Kring @ Jan 3 2009, 02:19 PM) Ah -- chained building is an entirely different beast. Chained building is a feature I'd support. But the base source files for any link in the chain should all be in the project or another project pointed at by this one. That way every link in the chain is managed by a project file that is very explicit about which source files should be pulled into the build.

QUOTE (Yair @ Jan 3 2009, 10:17 AM) That makes sense for the icon, but not for the VIs, in my opinion. The icon doesn't affect the runtime behavior of the VIs. My argument against the build spec accessing VIs not listed in the project is that it changes the behavior of the VIs from what you would have tested in the development environment.

QUOTE (Jim Kring @ Jan 2 2009, 06:34 PM) Why? Wouldn't that make the situation described here worse? You would conceivably have a project that works perfectly well in development, then you build an EXE and suddenly it doesn't work the same at all because a bunch of VIs over in a ".svn" directory are being picked up by wildcards. What can you pick up in a build spec that you cannot pick up in the project itself?

QUOTE (Daklu @ Jan 2 2009, 07:55 PM) yes.QUOTE How would the compiler treat the current code differently if we pull the x and y terminals out of the event structure? It's not the compiler. If we pull those out, we can get rid of the "DoNothing.lvclass" entirely. And the loop wouldn't wake up to try to do the "Enqueue Element" just because you typed in new numbers.

QUOTE (Michael_Aivaliotis @ Jan 2 2009, 05:00 PM) Darn it... I told them to take out the "if (user == Aivaliotis)" code before we shipped. Seriously though: The only bug like this that I've heard of for projects involves autopopulating folders. X.lvlib owns A.vi. A.vi is saved in a directory which is autopopulated in your project, but the library is not saved in that directory -- it's just a part of the project. So the project loads up, loads the library, then it starts populating the tree, and it includes the VI, and the library says, "Hey! That's mine, you can't have it!" and it tries to go with the VI, but the autopopulating folder says, "You can't come in here! You're not in my directory, Mr. Library!" They have a war which someone eventually wins but in the meantime the poor project gets hit with a docmod. Autopopulating folders: The only way to win is not to use them. Of course, this may not be applicable to your problem, Michael. It's the only case I can offer today, though.

QUOTE (Jim Kring @ Jan 2 2009, 02:31 PM) Ideally you what?! Weren't folks just complaining about cross-linking? Yes. And yet now you want to add it as a feature for build specs. *sigh*

QUOTE (Yair @ Jan 2 2009, 03:07 AM) I've argued it elsewhere in these forums, but the short story is that the feature contradicts the basic principles that we designed into the project and it causes logical contradictions to arise when using libraries (all types of libraries: .lvlib, .lvclass, .xctl and .lvsc). The project was designed to help you separate the physical layout on disk from the virtual layout in your project. That was a feature, and it is a good feature. The autopopulating folders unifies those two again, which once again means there is a lot of churn among caller VIs when a subVI moves to a different folder, and it means that source code control revision history is harder to track whenever VIs go through moves on disk. It moves us in the wrong direction: toward more disk integration instead of less. Libraries in the project show ownership tree -- but if the library is inside an autopopulating folder, you get all sorts of stupid situations when trying to use libraries, and we in LV had to invent all sorts of arbitrary rules for handling cases... for example, a library is in an autopopulate folder, but one of the members of that library is not in the same directory (this is common for sublibraries). The library is listed under the autopopulate folder; and under that library, the owned item is also listed, even though it isn't in that directory. I know why a lot of folks like the autopopulate folders. I get the "ease of use" arguments. But in my opinion they're just like global VIs: easy to learn, quick to implement and a complete disaster for long term code maintenance.

You missed a key trick -- that enum is a maintenance hazard, and there's an easy way to avoid changing the mechanical action of "Plus 2". Oh, and I renamed your "Data.lvclass" as "DoNothing.lvclass" since its job really wasn't to load the data but just to give the queue something to do on those events. See attached file. You can actually get rid of the Value Changed event case and the shift registers entirely by just moving those FPTerms outside the event structure -- I didn't make that change in this revision. I could've gone a lot further in the refactoring, but I figured this revision highlighted the enum improvement the best. Download File:post-5877-1230873647.zip

QUOTE (Ton @ Dec 31 2008, 03:40 PM) There are reasons why I opposed its introduction into current LV versions and would have no qualms if it went away in future versions. Unfortunately, I am in the minority, both among developers and users. I loathe that "feature."

QUOTE (Ton @ Dec 31 2008, 11:21 AM) What causes LabVIEW to ignore _svn directories? Is that something built into LabVIEW?

QUOTE (sam @ Dec 31 2008, 09:43 AM) I use Perforce which keeps the repository on a separate machine, so there's no chance of local VIs crosslinking to the repository files. Having said that...QUOTE What do you do to avoid false linking? Yes, I have encountered this problem, but more rarely in recent versions of LabVIEW. I'm surprised to hear you blame the project explorer -- that has gone a long long way toward preventing these problems, particularly LV version 8.5. That version added cross-link detection before the VIs load into memory (if a caller VI in your project links to a subVI not in your project, the project checks to see if another subVI of the same name is already in the project, which indicates that the caller VI has linked to the wrong item). the File view of the project (shortcut key ctrl+E when on the Project Window) that lets you quickly see if any VIs are linked that are from unexpected directories. protection for VI renaming... when you rename a VI, LV updates all the caller VIs in the project, even those you haven't loaded into memory, so you have fewer cases of loading a caller VI and its subVI being gone, triggering a search for the subVI. and some rather powerful untangling tools. There are several problems with the untangling tools when libraries (.lvlib, .lvclass, .xctl and .lvsc) are involved, but if you're working purely with VIs, these tools are a major aid. Cross links of the type you describe almost always come from a caller VI missing a subVI and then LV searching for the missing subVI and finding it. Do you frequently rename VIs on disk instead of renaming them inside LabVIEW? Are you using libraries, moving a VI inside a library (which changes its fully qualified name) and then not saving the caller VIs? Can you move the svn directory to a location where LV won't automatically search it when looking for missing VIs?

QUOTE (Yair @ Dec 30 2008, 01:18 PM) Write up the exact documentation change you'd like to see. I'll ask the tech writers to review it and see if we agree.

I commonly program at 1440x900.

QUOTE (rolfk @ Dec 29 2008, 08:00 AM) Actually, believe it or not, Malani's suspicion is correct Rolf... it is inefficient. It also is not the same functionality.Let's handle the difference in functionality first: Save As: Substitute Copy For Original will cause any VI currently in memory that calls the renamed VI to be updated to point at the new name. Save As: Create Unopened Disk Copy will NOT redirect the caller VIs. I assume that in Malani's case there are no callers for the VI he is renaming, thus the functionality appears to be the same. But I want to make sure he/she is aware of the functionality difference just in case it matters in some future application. As for the efficiency: Save As is accomplished by renaming the VI in memory and then saving the resulting VI. When we do Save As: Create Unopened Disk Copy, we rename the VI in memory to the new name/path, save it, and then rename it back to the original name. That's the inefficiency -- if you're just going to take this VI out of memory, then it is better to leave it as the new name, which is what happens when we do Save As: Substitute Copy For Original. The reason we do the rename is to make sure any circular references correctly update and/or break. Milani: You should be able to get the functionality you want like this: http://lavag.org/old_files/monthly_12_2008/post-5877-1230591271.png' target="_blank">

QUOTE (Jeff @ Dec 22 2008, 10:33 AM) Yes, it is, and thus, in this case, references seem like an acceptable choice.

QUOTE (Jeff @ Dec 22 2008, 09:57 AM) The easiest thing to do in this case is ask yourself, "If my data was an integer, just an integer, how would I structure this?" If the answer is still, "I would create a reference to it" then a reference is the right thing to do for the class. But the answer may very well be "I would add parameters to my subVIs and pass the integer to them" or "I would create a functional global that manages that integer" or "I would use a global VI to store that integer". But, again, the decision applies to that one class only, and you would then make the same evaluation for the next class in line.

QUOTE (Jeff @ Dec 22 2008, 08:00 AM) Why are you having to choose between by value and by reference? Say it with me: By ref and by value models are NOT MUTUALLY EXCLUSIVE. By ref and by value models are NOT MUTUALLY EXCLUSIVE. By ref and by value models are NOT MUTUALLY EXCLUSIVE. You should be using references for classes that represent hardware and system resources and, sometimes, for extremely large data structures if you're not confident of your ability to avoid forking wires to modifier functions and thus creating data copies. You should be using data for classes that represent data, including very large data structures where you are confident of your ability to write LV code that avoids data copies. My personal estimate -- based on two years of observing programs from LV developers, both inside NI and not -- is that The vast majority of programs have no use for references whatsoever The total number of classes that should be by reference in the world is roughly 5% of the total of classes written. The GOOP Toolkit refnums are -- get this -- written as by-value classes. They are by-value classes that implement reference functionality. Using one domain does not exclude using the other. To put it another way for C++ programmers: Using a class pointer in one part of your code does not prevent you from declaring local variables of the class in another part of your code.

QUOTE (Nate @ Dec 21 2008, 03:00 PM) I'm only going to contest a single word of that sentence. Change "extend" into "hack", and I agree with you. Essentially, if access to the data is limited to the API, then, yes, you are limited to only the things that the author of the original class foresaw you needing to be able to do. But that could be stated another, more positive way: you are limited only to those things that the author actually planned for and (hopefully) tested. Setting the internal values of the parent class to arbitrary values in the child class may move your class in directions that may destabilize the object or give rise to unintended behavior -- even crashes, perhaps (not in LV [if we in R&D have done our jobs correctly], but perhaps in a DLL that you call out to]).I realize that all of this argument is fairly philosophical, and yet I think the philosophy is a strong one for a language in LabVIEW's design space. LV classes really tried to balance the ideal against the practical, to weigh guiding users into good designs against forcing them into ridiculous academic constructs. The privacy of data was a major step in simplifying dialogs, simplifying design options, and supporting various other features through subVI connections only instead of having to constantly check for data connections too. We are not a hacker's language. We are a design, test and control language that seeks to be used to communicate directly with hardware, to maintain "always on" systems, and to provide all of this to folks who are not trained as computer scientists but are scientists and engineers in their own domains who need the computer to serve them instead of the other way around. Being a bit more "ideal" seems like a good thing in such situations, as long as we don't go overboard with it. For the moment, I think the balance is preserved, but I keep listening to feedback from users to make sure we keep it balanced as we go forward.