Aristos Queue

This one seemed pretty specific and looking for a CAR number.

I'm hoping that we get an analysis of which questions are being missed so we can analyze them to see if they're bad questions and, if so, fix them. Unfortunately, it takes multiple people actually taking the exam to generate that data pool. Curiously, the annecdotes I'm hearing seem to indicate that our beta test group of CLAs was abnormally skilled at passing the CLA-R compared to the general body of CLAs. Perhaps CLAs become smarter when in physical proximity to each other? :-)

CAR 328228 filed. For future reference, posting something like this at http://forums.ni.com/ is more effective than posting it on LAVA -- the NI application engineers monitor those forums continuously and can directly file CARs and they know the known issues and workarounds better than anyone. Yes, sometimes posting here works, but no one from NI (myself included) assiduously reads every LAVA post, so bug reports like this can get easily missed.

> Also I wouldn't put too much untested faith in the idea that each time a sub-vi runs w/an event reg node in it, that the executions of that node will be wholly unrelated. Though I agree with Norm's admonitions on this topic generally, if you make the subVI that generates the event refnum be inlined (LV 2011 feature on the VI Properties dialog >> Execution page), I'd be very confident that it is just like having the event registration node on the caller diagram.

WHOA. You can bundle event registrations?!!?!?!? WHY HAS NO ONE EVER SHOWN ME THAT TRICK BEFORE?!?!

If Shaun is talking run time performance, this claim is extraordinarily unlikely given that 2009 includes none of the modern compiler optimizations. If Shaun is talking edit time performance, the claim is generally unlikely but there may be some particular edit operation that he does frequently that may be slower, but mostly 2011 fixes the commonly sighted editor slow spots.

Hierarchy which *uses* the reference doesn't matter at all. Only the hierarchy that *creates* the reference matters. If the hierarchy that creates the reference goes idle, the reference will be invalidated, even if it is in use in another hierarchy. This is the defined behavior for all refnums in LabVIEW. The LV2G will still have the same actual number stored in it, but that number won't be a valid object any longer.

To the best of my knowledge, no, no one has made efforts in that direction.

The problem is that in this case, there are no events that directly represent the action for which the programmer wants to register. Registering for the mouse and keyboard events is a hack that has to be done very precisely, and it gets really tricky when there are multiple controls/labels/etc that need to be monitored. The polling loop addresses these concerns.

Another variation that works for almost all similar situations is to have a separate loop that just polls every 100ms or so, comparing the last known value (in shift register) to the current value. If it detects a change in the value, then it fires a User Event. This allows your main event loop to not have to have the shift register logic inside of it, making it easier to add/remove the handling for additional scales or other run-time-changeable properties. Yes, it is a polling loop that is continuously running, but in the vast majority of VIs intended for the user to actually see, it has no human-noticeable impact on the responsiveness of the UI.

I looked at the linked file... there's no mechanism that I see in that demo to change the type of the event. What header do you edit to change the data type?

You say "a dynamically called VI". If you called it by using the "Run VI" method, that's a separate VI Hierarchy. If you called it using the Call By Reference node, that's the same VI Hierarchy. (Note for LV 2011 users: If you use "fire and forget" mode with the Asynch Call By Ref, that's the same as Run VI method and so is a separate VI Hierarchy. If you use "fire and collect" mode, that's the same VI Hierarchy.)

To me, this sounds like a problem for User Events and User Events only. All other refnums can be wrapped in classes. Why would I oppose building something more common for references generally? First of all, you only put a single checkbox in the Library Properties, but just because I have one reference that I want to restrict does not imply I want to restrict all references. Second, you're asking for restricting destroying the reference, but with queues, it is not uncommon to want to restrict either enqueue or dequeue -- any given subset of functionality might be the subset you wish to restrict (I even imagine one case where the *only* thing the outside can do is destroy the queue, which stops the internal producer/consumer loop). Third, you might want to share functionality to some people but not to others. For all these reasons, I think building a class that exposes the functionality that you want is the more desirable route. Asking for some scripting tools to create those wrappers faster would be reasonable. The restrictions for DVRs of class types do not fall in the above categories because those are restrictions that apply to the *entire type* of refnum. A type-wide restriction is different than a per-instance restriciton. If you wanted to prevent anyone from ever destroying a "User Event of Subtype X", that would be more viable as a request than the per instance restriction. As for the User Event, asking for a new node that, given a User Event, outputs a "Registration-Only User Event" gives you something that could still be connected to a Register Event node. With that small adjustment, you could build a refnum class that can register, send, etc. The *top-level* VI is tracked, but not the specific subVI, and this would need to be on the specific subVI. It would require a new tracking system. It is the language's job when the restriction is applied to the whole type (like having a private destructor in C++). It's not the language's job when we're talking specific instances of a type.

This will be fixed in LV 2012. It wasn't deemed high severity enough for LV 2011 SP1.

Just FYI, the old "array of int16" type descriptors are all pretty much deprecated as far as LV R&D are concerned. There are many types that those arrays cannot accurately reflect, which is why we use the Variant library that "TheJ" mentioned.

Flatten to String can return Out Of Memory.

Yes, it would. Insert standard arguments here regarding priorities, resources...

No offense taken, Daklu. The technical feedback is generally valuable. In this case, I suggest your statement is sometimes true, but not always, and I'm not sure whether it is true in this case, so I'm going to walk through my thought process publicly. Let's start with this example. The code on either side of the black bar does the same functionality: Suppose many users are writing the code on the left, which is less efficient than the code on the right. Is that a deficiency of the language? No. Is it a deficiency of our documentation? I'm not sure... it certainly doesn't seem like it is LabVIEW's job to be documenting all the possible trig identities. Maybe VI Analyzer could detect simple trig substitutions like this one, but it would be hard to teach it all the known interesting identities. So if I saw many customers writing the code on the left and posted "hey, you should use the code on the right", that wouldn't reflect a deficiency in the language. I believe that the above demonstrates that that the assertion of "efficiency advisory implies language deficiency" is not universally true. Next thought experiment: Advising users to use the Inplace Element Structure instead of Index Array and Replace Array Subset. The structure node gives LabVIEW information about your intentions that is hard or impossible (depending upon the exact code you write) to derive otherwise, and the compiler can use that information to make more efficient code. This is an example of, essentially, using exactly the same two nodes, but using them in a specific way. Is the language deficient? No, it provides a way to make your intentions clear to the compiler. Is the compiler deficient? Yes. In much the same way as the trig identity substitution, the compiler is not smart enough to recognize what you're doing. So it is a lack of artificial intelligence. But it does demonstrate that an efficiency advisory to use a node (or pair of nodes) in a particular way is not necessarily a language deficiency. That brings us to the current case of the To More Specific node. Does it add anything to the language to have a different node that does the type testing? Functionally it would be absolutely the same as the existing To More Specific node, but missing the "object out" terminal. Let's call it the "Is More Specific" node... and I'll refer to them as "Is" and "To" for short. If we have "To", there's no need, functionally, for "Is", as long as people know how to use it. In other words, adding the "Is" node would still leave us with the same problem of teaching people when to use "Is" vs. when to use "To". On the flip side, if we had "Is" in the palettes, it might make people ask the question, "Why do I need this other node when I already have this first node?" That's the effect today with the Inplace Element Structure -- just have the IPE struct makes people question, "When would I ever use this if I have the direct nodes?" So although the "Is" would be noise from a "does it do anything new" perspective, that extra static might make people question, thus aiding with the education problem. On the other hand, if people could always use the IPE, I suspect we would remove the individual nodes from the palettes and send everyone to the IPE always. But there are times when you only want one half of the pair, so the individual nodes stay. In this case, we have a situation where the "To" node would *always* suffice for the "Is" node. Overall, we are talking about avoiding one object copy. Yes, that might be critical in some domains, I grant, but this is hardly the most exotic tool in the "hide the dots" toolbox. Is it really worth the extra node? I don't know. I'm inclined to say "no", but I suspect some part of me is saying that just because I'd have to take on the work of actually creating that node, which would be a relatively boring task to undertake compared to other things I could be working on, so in this instance, my objectivity is compromised (providing new functionality is almost always more interesting than rehashing existing functionality... I'm sure most of you, as programmers, have experienced that... unless it is someone else's code originally that totally sucks and you get to have great fun ripping out the ugliness). So, that's my arguments for/against the "Is" node.

Read all the documentation about "inplaceness" My mistake. I thought they were both that way. Thanks, Greg.

Option 1, the sentinel value, is having an input that is a uInt32, where 0 means "never set" and all positive numbers are valid input. There are variations on this theme, like using -1 to mean "infinite timeout" on various primitives in LabVIEW. Option 2, clustering the data with a boolean, can be done just as well with a LabVIEW class and provides a better enforcement mechanism: Suppose you create a private data cluster of an integer and a boolean where the boolean means "Initialized", which defaults to False. The "Write Numeric.vi" could assign the integer and turn on the boolean. The "Read Numeric.vi" could return an error if the boolean was never set. With a plain cluster, you have the possibility of someone not checking the boolean and going straight to unbundling the integer. For those of you who believe in the Tooth Fairy and other mythical creatures, an Option 4 would be to write an XNode, which can script different behavior if a terminal is unwired. But like all unreleased features, a certain amount of faith is needed to believe in that solution.

Yes, and this feature was discussed... and rejected since inlining doesn't prevent a VI from being used with the Call By Reference node. Also, very large VIs should not be inlined, and there's a real probability of people turning on inlining on something big just to get a feature like this that could still be better achieved by making it part of the function's signature or making a new type that has sentinel capacity (i.e., a class that has a boolean for "is initialized" and then the rest of the data).

LabVIEW strings are not immutable. The compiler does consolidate and modify. What have I repeatedly said? "Buffer allocation dot is not the same as a copy". A buffer allocation is a place where we can *hold onto* a string. Two string buffer allocations would mean that there are two strings, but we can modify one of them and just swap it into the next position, without making a copy. All LV data types are mutable and subject to this inplaceness analysis. For the special case of "reverse a string", we just set a flag on the string that says "this string should be traversed in reverse", so it is a constant time operation.

I found some commentary online, unrelated to LabVIEW, suggesting that Symantec doesn't like being locked out -- it might be a program trying to avoid detection. I wonder if the Timed Loop could be causing Symantec to think it is being locked out.

Write your own compiler.

*laugh* Can I add that to the list of advantages from large icons for new users? :-)