Aristos Queue

If you've read the linked article, you know as much about it as I do. Post your question to forums.ni.com ... someone else at NI might be able to provide more details.

This seems like something that should be posted to the ni.com forums so that an AE can check into it for you.

NI SRManager is now in the iPhone App Store. You can download it here: http://itunes.apple.com/us/app/ni-srmanager/id432100096?mt=8&ls=1 View and bookmark your NI Service Requests. You can read the service requests offline including (requires a service contract) notes from our Engineers. Features: - View Open and Closed Service Requests - Bookmark Important Service Requests - Call Support Directly from the App - View Account Valid Service Contract Required: - View Notes from our Engineers

Information from the developer working on this: The token 'hierarchy.stateFlags' is used to enable/disable options in the VI Hierarchy toolbar. It becomes equal to '1' when Include vi.lib is on and Include Globals and Include Type def are off. I'm not sure, as of now, why it is affecting showing the class hierarchy. I'll debug it and update the CAR notes. I just checked and the problem is present since at least LV 2009. There is a better workaround to this problem which doesn't involve having to restart LabVIEW. Class hierarchy shows up fine when I right click on a lvclass in the Project Explorer and select 'Show Class Hierarchy'. I hope that helps. I don't think we can get this fixed in LV 2011 -- the report came in too late -- but at least you have a better workaround.

Ah, so we were both looking for better ways to stop bugs. What a coincidence! Deterministic puts requirements on the performance of the function, but not on its functionality. A function can be deterministic and hygienic, only hygienic, only deterministic or neither. For example, in LV Real-Time, I can write a function that reads from a FIFO. I can make that function deterministic, but it will give me back different values every time I call the function because of that FIFO.

I will file the bug report on Monday and see what comes of it. The problem with this theory is that his screenshot does not show the triangle that indicates "a subtree is folded up here". Ctrl+a (aka "show all") unfolds all such collapsed trees, but his picture is showing no such collapse. Have you also experienced that bit of incorrect visual feedback?

I just got home from Spain where I was attending an academic conference for researchers in functional programming languages. I put this question to some of the attendees and got a refreshingly straightforward answer. A VI should be considered clean if, when executed, for any set of input parameters, the output values are always the same. In other words, if you have a function that takes two integers and produces a string output, if those two integers are 3 and 5 and the output is "abc" the first time you call the function, it should ALWAYS be "abc" every time you call the function with 3 and 5. The term for such functions in other languages is "hygienic functions." It's a term I'd heard before but never thought to apply back to LabVIEW. This definition covers your queue example. Hygienic functions are not required to have the same performance characteristics whenever they are called, just the same output data values. There are variants on this theme. For example, the multi-enqueue queue example you posted is hygienic because the Obtain Queue is in the function body. If that were in a caller VI, you would have the situation where the caller VI would be hygienic but the subVI would not be (because given the same refnum [even during the same run of the application where that refnum refers to the same queue] the output might not always be the same because it might be called from places where others had mucked with the queue instead of being right after the Obtain Queue the way it is now). There is a concept called monads that I've been playing with for a number of years as a way of eliminating refnums from LabVIEW, and I hadn't had much luck with that approach, but this conversation highlighted specifically why monads exist in other functional programming languages and how they are used to make non-hygienic functions become safe for callers. I'm going to make another run at how monads could fit into LabVIEW. Yes. By the hygienic definition, a producer/consumer loop pair used to do some kind of divide and conquer algorithm or pipelining algorithm would be dataflow safe.

At a guess, this line looks the most relevant: Try removing only it and see what happens. I have no idea what that config token controls, but it's the only one I see that I'm not at least vaguely aware of its purpose, and its name is related to the problem described.

My opinion? Inherent. Whenever anyone in CS research says that "dataflow programming is (safer/more provable/easier to refactor) than procedural", they say these things because of the local effects rules.

The use of OO in this case is irrelevant -- you may decide to use it or not. What is key is the use of reentrant VIs. They are a much MUCH better solution than template VIs. Use "Open VI Reference" on a VI that has been marked as Reentrant to display multiple copies of the function.

Every wire of your class type is a separate object. Every object is an independent instance of a class.

I agree with this analysis generally. Now, having said that, there is a concept of asynchronous dataflow, where data flows from one part of a program to another, and a queue that has exactly one enqueue point and exactly one dequeue point can be as dataflow safe.Shared, local and global variables also violate dataflow for the same underlying reason as refnums. A variable "write" doesn't execute until its input value is available, but what it does under the hood is dependent upon non-local effects. So the best definition I can offer for "dataflow safe" is "all nodes execute when their inputs are available and, regardless of the behavior behind the scenes, no piece of data is simultaneously 'owned' by more than one node." I've been trying for some time to refine this definition. Actually, NI is trying to encourage the use of "G" as a way to differentiate the language from the IDE. This is contrary to our earlier position, because we were trying to avoid confusion among customers, but as we have gotten larger and our products have been more used in larger systems, the distinction has become more useful than harmful. That was something we started differentiating at the end of 2010, and it will take a while to permeate our communications/documentation/etc.

I might buy this argument for the CLD, but not for the CLA. You're not having to fill in all the detailed code in the CLA, which means its mostly "Create some basic classes and put empty VIs into those classes." Somewhere between 2 and 3 out of 10 of all CLA exams submitted do use LVOOP as their primary design orientation. I did both my CLD and CLA exams with "no VIs that weren't a member of some class" partially because I usually design that way and then prune back later if it seems prudent, so at the architecture stage it really is all classes, and partially to prove that it could be done within the time. The exam doesn't care so much about the terminology as long as you explain what you're doing. The value of the terminology is the shared vocabulary can save a lot of time. If you can just write down "put a standard producer/consumer loop pair here linked by a queue", that's faster than explaining all the bits and pieces. There is a common parlance that develops around any technical field. The CLA exam does not require that you speak it, but it does weight advantage to those who do. And, for the record, since you are reading LAVA, you've picked up that bit of terminology. Anyone who keeps reading like that will eventually pick up the terms. It would be worth asking whether the CLA graders would accept a VI that says, "Download standard toolkit XYZ from location MNO and instantiate the following template, then put that subVI here." ... and similar comments. Any of the tools like LapDog, or AMC, or ReX, or the Actor Framework, or the GOOP Toolkit might be usable then. After all, that's exactly the instructions I would give to a developer in some of these cases. I seriously doubt that it would get you off the hook for actually doing the module design and layout of pieces, but if you can broadly mimic the pieces that you want those tools to generate, that might pass examination. Worth asking, IMHO. My understanding of the intent of the CLA, and how it is used by managers who look for the certification when hiring, is that the CLA is a leader of CLDs, someone who works a bit faster than a CLD because of long practice, but more importantly, someone who can teach. Not every crackerjack developer can actually teach others how to develop. An architect has to have that skill. "This project is larger than what any single developer can build alone; I'm going to spec out the parts of that system and then farm them out to you guys. If you build them wrong, I'll show you why it doesn't fit with the rest of the system." Over time, a CLA should be able to create new CLDs from untrained new hires. That's my understanding, anyway, and I believe that's why documentation counts so much in the exam.

Or don't since the method reinitializes the value property to default and those things *are not* values. It would be really frustrating for apps that don't dynamically populate their tables etc if LV wiped out the content every time the value was reset. Rings shouldn't be wiped, neither should tables.

I wouldn't recommend the library refnums for anything other than editor support. They were never intended to be in the runtime engine -- they got added in LV 2009 to support TestStand talking to LabVIEW, and, honestly, I think including them is a bit misleading. The library refnums all go through the project interface. The functionality that they were designed to promote is not the runtime reflection that an OO programmer might be looking for, but instead for the editor capacities that a LV add-on author might be looking for. They require a swap to the UI thread, which is an obvious drawback. I haven't found any place where I actually get the qualified name from an object. The code that I thought I had done the "to variant" conversion trick apparently I found a different workaround and ended up not needing the qname at all. So the Flatten To String is still your best approach in all shipping versions of LV, as icky as that may be. There just hasn't been much request for the reflection API, and for most APIs, the path has been sufficient since any API designed to be used in a running VI (as opposed to a scripting editor tool) doesn't have to worry about classes that have never been saved to disk.

*head smack* I forgot about that. It's the type descriptor included in the variant, which is the wire... it doesn't delve into the object. Somehow I did get the right type descriptor into the variant. Now, if only I could remember how I did that...

Ask and ye shall receive... vi.lib\Utility\VariantDataType\GetLVClassInfo.vi Just wire the class wire directly to the Variant input. Shipped with LV 2010 at least, but I'm *mostly* sure it was in LV 2009. *May* have been earlier, but I *think* it was 2009. LabVIEW version of any library (including .lvclass) can be gotten with an App method "Application:Library:Get LabVIEW File Version" without having to load the library into memory. Class version is the same as library version... if you have a reference to the class itself, you can use the "Library:Version" method.

This bug will be fixed in LV 2011. If you are part of the LV beta program, you should be able to confirm this fix in the second beta.

Incorrect.

I forgot to check LV 2010 before the SP1 patch. Well, I'm sorry it broke, but I'm glad we fixed it.

No one has ever mentioned this behavior before. I've certainly never seen it. I'll keep my eyes open. Obviously if you figure out what triggers it, please let us know.

I'm not going to comment on any design aspects. I assume you're design is good and this is what it takes. So let's focus on load time. 1) Put all your VIs and classes into a .llb file. The .llb optimizes the contents of the file and significantly improves load speed when a block of VIs must load as one. 2) Try loading in a runtime engine and compare to the load time in a development environment. Are they significantly different (there will be some difference, but it should be a second or two, at most) If so, you're probably doing something in the dev environment that is causing the block diagrams and panels of all those VIs to load needlessly. There are various things that can cause this -- scripting tools running in the background, VIs that are saved broken and become good after they load because something else loaded their missing subVIs, etc. 3) If you have LV 2010, you can build packed libraries. DO NOT UNDERTAKE THIS WITHOUT READING DOCUMENTATION. The packed libraries can give you BLAZING FAST LOAD SPEEDS. But they are a power that comes with consequences. Notably, the classes in the packed library have a different qualified name than classes not in the packed library, so any caller VIs need to be written in terms of one or the other. The packed libraries are designed to be "I build this separate component, and then I go develop something that uses that built component", not "I build this monolith of source code and then I turn it into two different components." There are tools to make the latter approach work, but the former approach is what I'd recommend.

Hey! There's already a better error message there! Closing CAR...

I cannot reproduce the good wire on the Equals prim in LV 2010. Here's what I get: Do you see anything that I have different from what you were doing? I tried adding the other nodes on the wires (such as the Send Event node) and that didn't make a difference. And in the VI you just sent, can you just use parent events and send the appropriate data later?

The wire that is now broken is correctly broken. The wire that is now fixed should still be broken, but at least that one won't crash LV, whereas the other one will. You should never be allowed to cast an event of child as an event of parent. Consider a hierarchy of Parent, which has two children named Son and Daughter. I create an event of Daughter. I register it with an Event Structure, which now has a Daughter type output. Then I cast the event refnum as an event of Parent. Then I use Send Event to fire the event, but the data I give it is of type Son. The son data is transmitted and comes out of a Daughter terminal in the Event structure. This is a problem because the private data of Son will be incorrectly interpreted, and you may crash. Yes, this metaphor leads to some terrible jokes. But the crash that occurs is no joking mater. I do not know why the Equals prim is allowing the comparison, but at least that comparison isn't actually trying to interpret the data, and it will always return False, since we've blocked the casting. Now, having said all that, there's a back door to casting that I cannot ever close. Use the following at your own risk: If you have an event of Daughter, you can use the Type Cast node to cast it as an Int32. Then you can use a second Type Cast node to cast that Int32 as an event of Parent. You now face the same danger of crash that was there before. Your framework had better guarantee that the event of Parent is buried so that no one can transmit arbitrary data to that event. I'll file a CAR about the Equals operation. Don't write code that relies on that comparison being legal -- it's going to close again now that I know about it. [LATER] CAR 294872 filed.