Aristos Queue

QUOTE (Darren @ Feb 12 2009, 05:54 PM)

I believe this statement will be my motivation to actually write the blog article on LabVIEW Object-Oriented Programming that has been brewing in the back of my brain for months now. You have been warned...

Good! These users can finally get some practical advice... I've been feeding them theory for two years, and I think some of them were starting to believe in it.

QUOTE (Darren @ Feb 12 2009, 11:24 AM)

I did not use LV Classes in my code for the CLA (and I passed).

Passed? You're lucky I wasn't your grader!!! Congratulations, Mr. CLNCA (Certified LabVIEW No Class Architect).

(In full disclosure, I can't razz Darren too much since I am not sure I could pass the CLA, LV classes or not. Remember that G programming is only a hobby for me; I spend most of my time architecting C++. Or, to put it another way, I write in text so you don't have to.)

QUOTE

Ah. We need more users like this. :-)

QUOTE (shoneill @ Feb 11 2009, 05:03 PM)

I can also see need for something like this. The ability to create extensible frameworks with Objects (Loadable at run-time) which may have its origins well beyond our control means we cannot be sure that name collisions don't take place. I don't know the internals to LabVIEW but surely there must be a way to do this. But as I tell my customers quite often, everything's possible, it's just a question of manpower.....

Actually, no. Some things are logically impossible: A general hash function that never produces collisions. Sorting data faster than O(n*log n). Preventing name collisions among a system where anyone can contribute a name without a central database of names.

There are ways to mitigate name collisions, but not prevent them. Hearing the use cases is important because they affect which mitigation schemes might work best. So keep talking... I'm listening.

QUOTE (mic_k86 @ Feb 11 2009, 09:20 PM)

hi all, i have some concept from visual basic but i not sure can applied it to labview or not.

let say i have a numeric control to set the delay time. if the user selected 00:00:00 and click run, message box "wrong time selected" pop out and return the user to the labview control panel to selected the time interval again. how to do that in labview?

*i am using labview 8.5

In the Dialog palette, you'll find One Button Dialog, Two Button Dialog and Three Button Dialog.

QUOTE (Mark Yedinak @ Feb 11 2009, 06:34 PM)

What type if var Comport? I suspect that this is not simply an integer. This may be part of your problem.

"var" means variable. The way to read this is "declaration of three variables, named ComPort, TC and Mode, all of type Integer".

QUOTE (Daklu @ Feb 11 2009, 12:27 PM)

The namespace itself doesn't have to be used anywhere except when loading identically named libraries.

If the namespace is not used anywhere other than load, how do you invoke subVI calls? Suppose you have two copies of X.lvlib, each of which contain Y.vi. When you load the second X.lvlib, according to your scenario, we would put that library in a new namespace Temp:X.lvlib. Now you load Alpha.vi, which calls X.lvlib:Y.vi. It is going to call the original X.lvlib:Y.vi, regardless of which one it was expecting to invoke because that's the one that got the name.

The goal of namespaces is *not* merely so that you can have two things of the same name in memory simultaneously. It is actualy so that you can *use* those two items simultaneously, and meaningfully keep straight which one is being used by any given caller. Being able to load a VI isn't much good if you can never invoke it.

QUOTE (menghuihantang @ Feb 11 2009, 04:02 PM)

Thanks much. I changed to 8-bit unsigned, but labview still crashed every time.

QUOTE

Comparing the picture you included against the function prototype, I'm pretty sure that you've got it configured exactly right. I would guess that the problem is more likely with the value of the parameters that you are passing in than with a problem with the types. It's pretty hard to mess up integers.

QUOTE (Daklu @ Feb 11 2009, 02:04 AM)

(There were a few more comments I wanted to make, but I'm literally falling asleep at the keyboard. I hope this is reasonably coherent.)

It is coherent. :-)

And I think it will provide fodder for contemplation for the next few years. I say that because I don't want you to think the feedback is lost even though nothing may come of it for many years. This would not be the sort of feature that would be rushed into a release.

QUOTE (Daklu @ Feb 10 2009, 06:46 PM)

One word: "Incorrectly."

Not necessarily. I replied in more detail in the other thread you spawned.

QUOTE (Daklu @ Feb 10 2009, 06:46 PM)

What happens when you load a library outside a project context, such as by opening a .lvlib file from the OS file system? Is there a default application instance that is used?

Yes, there is a default app instance. An app instance is simply a LV sandbox for VIs. All VIs always load into a given app instance.

QUOTE

No. There is only one non-project app instance.

QUOTE

Nope. You would simply get the Honda.lvclass that was already in memory in that app instance.

Your questions strongly hint that R&D has been significantly off track in our work on this problem, at least as far as your situtation is concerned -- it may apply to other users as well. Let me see if I can explain why your questions disturb me...

We [R&D] have been almost entirely concerned about *development* time collision of VIs/Libraries. The single biggest challenge that we have focused on "I have a bunch of VIs in my project. I create a source distribution of my VIs. Then I open my source distribution to make sure it was created correctly, and then my source distribution and my original source ends up cross-linked." This seemed to be the primary reason for all the prefixing/renaming that was taking place. Thus in that environment the project is aware of the links of everything that tries to join the project and it throws up a protective dialog if stuff that would create cross-linking tries to join the project. That dialog offers you the chance to open the new items in a separate project, where you could rename the items, put them in a library, or just realize that you didn't want that in the first project in the first place.

When you are done developing VIs, we expect you're going to go deploy them somewhere. This may be by building an EXE. This may be downloading them to a target. This may be by building a source distribution and running them in the development environment. But at that point, you are no longer editing the VIs. The presumption has been that when you are now running your VIs that you don't have these concerns about collision because your application is something that has been created. Even if you have a bunch of dynamically loaded VIs/classes, those dynamically loaded components are things that were designed in the context of the application; they know the framework that they are loading into, so there should be zero concerns about collision with the elements of the framework itself. When the components are independently developed by unrelated groups of developers, the dynamically loaded components should be placed in a library to namespace the elements... your Austin development team would have their pieces in a library named "Austin.lvlib", and your Shanghai team would have their pieces in "Shanghai.lvlib", so even if they both wrote a "DAQStuff.lvclass", those are two different qualified names when loaded into the framework.

Now, your questions seem to imply that you could have multiple unrelated applications -- the test lab microwave, the cafeteria microwave, etc -- all loading into the same run time environment. Under what conditions does that occur? Why does that even arise as a concern? When is there ever a single labview.exe that is running both of those applications?

The presumption is that all those different Microwave classes would never come together for the first time in the run time environment. Long before you ever got to that point, all these classes would have been loaded together in a project in development, and the project would have forced you to sort things out at that point, if the classes were not already in uniquely named libraries.

If you really are bringing these classes together for the first time in a run time scenario, it means that your use cases are far away from the common scenario envisioned by R&D.

QUOTE

Given that the library is the container for the member VIs/sublibraries, and given that the VIs/sublibraries know they are members of the owning library, choosing the library as the namespace seems very natural to me.

QUOTE

What was their failure here? I'm going to guess that it was something like this:

You had two development teams, Alpha and Beta. And since the development efforts of these two teams might sometimes get used together, it was decided that Alpha should use "Alpha.lvlib" namespace and Beta should use "Beta.lvlib" namespace. So Alpha created two different toolkits, Ping and Pong. And when they went to namespace these toolkits, they were frustrated because they realized, darn it, we don't want to have to distribute Ping and Pong both together. But if both Ping.lvclass and Pong.lvclass are in the same owning library, then that implies that they want to distribute together -- libraries, by design, package stuff together.

Am I right?

National Instruments does not have a single "NI.lvlib" that namespaces everything that NI produces to keep it separate from user developed VIs/libraries. If you look around, you'll notice that a lot of NI libraries have "NI_" as a prefix, and within that library is all the stuff for a particular toolkit. The prefix is not something that we apply during the production of the source distribution... it is the name the library is initially created with.

Your suggestion of a "meta" namespace -- one where a library says, "I'm part of the NI namespace", and multiple libraries might claim that, is interesting. It severs the concept of the namespace from the concept of access scope. Currently, if something is inside the namespace then it has the right to access private VIs in that scope. But such a meta scope, which any library might join arbitrarily, obviously couldn't extend the right to access private functions to just any library that said, "Oh me too!" But as a way of providing a common namespace that everything produced by a given set of developers into a unique namespace, it might be useful. It doesn't invalidate the library as namespace -- as I said above, that is a very natural container, and the namespacing there is valuable. But a second form of namespacing -- one that is divorced from reciprocated ownership -- might be worth contemplating.

QUOTE (bsvingen @ Feb 10 2009, 06:37 PM)

One drawback with OOP i the loss of execution speed. In C++ templates can often be used instead of inheretence, offering the same/similar functionality in most cases, and with no loss of speed. Could this be something for LVOOP? Or will this simply be the same as a polymorphic vi? Can this be done with LVOOP classes?

I've never heard of such a situation in C++, but templates is an area where my knowledge is admittedly weak. So let me ask a couple questions... it might help me say whether the same problem even exists in LV and whether the same (or similar) solution might help.

A) What is the performance problem that you are attempting to ameliorate? Is it the overhead of dynamic dispatching?

B) What is an example from C++ where you would use templates instead of inheritance to improve performance?

QUOTE (Ton @ Feb 10 2009, 05:02 AM)

The options in OpenG builder are a little bit more advanced:

Oh, I know that the OpenG distribution has a lot of useful features. I'm only addressing the one feature of renaming all your VIs/libraries when publishing. The goal was to make such hoop jumping unnecessary.

But your list does raise a related question: Why the heck would you want a random namespace??? I can understand a GUID or a version or somesuch, but random?

QUOTE (Daklu @ Feb 9 2009, 10:59 PM)

In any event, the class I was referring to in the orig post is a distributed reuse class, meaning it is (IMUO) essentially required to namespace the .lvclass by changing the filename. Why? Different class names for source and distributed code allows me to have both loaded in memory at the same time, which makes developing, debugging, and fixing my reuse code much easier. Even if I removed the namespacing from member vis I'm still facing the original issue.

With exactly identical file names, you can have both your source and distribution in memory at the same time. You load your source in one project and your distrib in another project. They are thus in isolated application instances. LV 8.5 and later will even detect if you try to load your distrib into the same project as your source and will say "this could potentially create cross linking, would you rather open this in a separate project?"

Every LV 8.x release has included features designed to eliminate the need for prefixing. If you're still needing it, then clearly there is something that the R&D team does not understand about LabVIEW and how our users are using it, because there's general agreement on the team that the tools exist now (8.6) such that you shouldn't have any reason to keep using prefixes. This should probably move to a new thread, rather than hijack Daklu's original question about how to deal with this, but a detailed list of why, between the project application instance isolation and the library namespacing, prefixing for distribution is still necessary.

Another option: Stop using OpenG namespaces and instead put the whole kit and kaboodle into a LV Library to provide namespacing. If you do that, your paths aren't changed at all. You can still use OpenG to namespace that top level library if you so desire, but all the stuff inside that library retains its original path and filename.

QUOTE (neBulus @ Feb 4 2009, 10:49 AM)

What is the number of queue create/destroys that are required to hit this bug?

The minimum is slightly above 4000 queues, although you probably won't see anything that soon because the refnum is made up of three components, one that is a cycling number and one that is based on something like the tick count and one that is random. Probability is in your favor until you get up around 10000 refnums of the same kind (meaning that if you create 5000 queues and 5000 notifiers, you're probably still safe on both).

This has been confirmed as CAR 136680.

Summary: "Queue/Notifier references can become unexpectedly invalid when using "Force Destroy" option for long-running VIs"

Details: A bug has been discovered with the queue and notifier refnums that affects all versions of LabVIEW from 6.1.0 through 8.6.1. It can only occur when you have multiple top-level VIs that are all using queues or notifiers AND you occasionally use the "force destroy?" option when releasing refnums AND your VIs run for an extremely long time without stopping. If you are seeing queue or notifier refnums becoming invalid unexpectedly, this bug may apply to you.

When you use Obtain Queue or Obtain Notifier, LabVIEW records that refnum so that if the VI that allocated it goes idle (stops running), the refnum will be automatically released. If you call Release Queue or Release Notifier explicitly, then the refnum is released and is removed from the list of refnums that need to be automatically cleaned up.

However, when calling Release Queue or Release Notifier with the "force destroy?" option set to TRUE, all refnums that refer to that same named queue are invalidated, but only the refnum that is explicitly passed to the Release function is removed from the automatic clean up list. The result of this is that all the refnums are now available for LabVIEW to reuse for future calls to Obtain and Release Queue that are used by other VIs. The result is that a first top-level VI can obtain multiple references to the same named item, then "force destroy?" those references. A second top-level VI could now obtain a refnum to a different item. When the first top-level VI goes idle, it will automatically destroy the refnums that were incorrectly left on its list. This results in the refnums, which are still in use by the other top-level VI, returning errors when they are used for operations.

Because released refnums are reused only when LV wraps around on the refnum count, the first top-level VI must be running for a significant amount of time before this bug can occur. It has taken as long as three days to manifest in some of the applications that were experiencing problems with this bug.

Workaround: Avoid using "force destroy" to destroy all the refnums for a given item (queue or notifier). One solution to this is to use the NamedRefnumManager.vi in the attached VI file. Unzip the attachment and take a look at "DemoWorkaround.vi" for more information. Download File:post-5877-1233763916.zip

Status: This bug was not isolated in time to be included in the 8.6.1 bug fix release. It will be fixed in the next release of LabVIEW.

QUOTE (Omar Mussa @ Feb 2 2009, 08:33 PM)

I can imagine all kinds of s*!@ hitting the fan when doing that in LabVIEW since any class methods that happened to have the same name as the method you changed to public would be broken (due to not having dynamic dispatching enabled but being a part of the same class hierarchy).

Well, actually, you don't have to worry about that because of the known issue in LVClasses that my team still hasn't been able to fix that even when a VI is private in the parent the child class is broken if it has a VI of the same name. It was going to be fixed in LV 8.6, but in LV8.5 someone (not on the LVClass feature team) wrote some new features for another part of LV that depend upon that uniqueness of name and enshrined it. Darn software -- it grows when you're not looking.

QUOTE (Daklu @ Feb 2 2009, 06:16 PM)

The short answer is sometimes I make changes to private vis that inadvertently 'breaks' (as in it still executes but doesn't operate correctly) my application and it's easy to run a test case on a private vi to make sure it's behaving the way I expect it to.

You can always hit the run button on any VI for short, quick checks of functionality. And if you just want to run a quick test, it should be just as easy to run the public VI that calls your private VI as it would be to run the private VI directly. When we start talking "test suites", I'm thinking nightly builds and automated testing on a regular basis. Those auto tests have no business, IMHO, running the private VIs because, as I said, a parameter sweep across them may result in false error reports or may put your object into an unexpected bad state that can never actually occur in real uses -- and I do mean *can* never occur not *should* never occur. That's the thing about privacy enforced by the compiler -- outsiders *cannot* call that VI with arbitrary values. Since this *cannot* happen, we don't have to worry about testing for it.

Up until recently, NI employees couldn't take the various LV certification exams because there just weren't enough graders and priority was given to customers. That's changed this year, and today I took the CLAD, along with a large faction of NI, including many of the LV R&D team. Yes, I did pass. I thought it was an ok exam, with a few wording problems I hope we can get cleared up for future test takers. I only had a serious problem on two of the questions, one of which was wording and the other was a case of me knowing too much about how LV works behind the scenes.

CLD? Maybe. But a part of me wants to hold out for a CLD exam that includes LV classes. I mean, I'd kind of be undermining the prostelytyzing I've been doing the last few years if I actually admitted that someone could be a true LabVIEW developer without classes!

On a tangent note:

Q: What are you if you are naked while answering a 40-question multiple choice exam about LabVIEW?

A: SkyCLAD!

Q: What are you if you swim 1 mile, bike 20 miles, run 2 miles and then take a a 40-question multiple choice exam about LabVIEW?

A: IronCLAD!

Others are welcome to try their own puns, but I should warn you... the only other word in English that uses the letters "clad" together is "clade" and making jokes off of it won't be easy. You may have more success in other languages.

QUOTE (shoneill @ Feb 2 2009, 10:36 AM)

For 1 million DBL values, the NI Median implementation is 4 times faster than an array sort (According to my quick test).

True, but the NI Median implementation is not returning the data we are looking for -- namely the index of that median. If we put a new requirement on the NI implementation, I'm sure they'd have to change their calculations to find that value somehow. I was just commenting on benchmarking the "sort then search" method vs the "cluster then sort" method.

QUOTE

Mathematics would be in a sorry state today if people gave up searching just because the entity was non-existent. Are you familiar with Stanislaw Lev's Cyberiad? One of my all-time favorite quotes, posted on my desk at work...

Everyone knows that dragons don't exist. But while this simplistic formulation may satisfy the layman, it does not suffice for the scientific mind. The School of Higher Neantical Nillity is in fact wholly unconcerned with what does exist. Indeed, the banality of existence has been so amply demonstrated, there is no need for us to discuss it any further here. The brilliant Cerebron, attacking the problem analytically, discovered three distinct kinds of dragon: the mythical, the chimerical, and the purely hypothetical. They were all, one might say, nonexistent, but each nonexisted in an entirely different way...

Hmm... Jim... I think theory and practice are closer in this case. Try this on:

You *shouldn't* test your private VIs. You should only test your public VIs. Why? Your private VIs are written to assume they are being called from within the class. Your private VIs may not be able to handle boundary conditions because the public API prevents those boundaries from ever being tested. Your private VIs may not have any error handling because their inputs are always sanitized by the public API. There may actually be logical errors in many many parts of your private VIs, but that's ok because there is absolutely no way for those ever to be invoked from the public API. Given all this, if you test your private VIs, you're going to become aware of defects that don't matter, and you'll waste development time fixing them. You may even cause slowdowns for your class by adding error checking and bounds checking code to the private parts of your class, replicating the work done by the public VIs. Or, to put it another way... Surgeon General's Warning: Testing your private parts directly may result in decreased performance, wasted development, and redundant material. Avoid testing your private parts in favor of having someone else test you through your public API.

Now, this is *theory* only. What are the thoughts from the practical experimentalists?

PS: Friend classes, should they ever come into being, won't do what you just said you expect them to do, ie, give free, uncontrolled access to the private parts of the class. An object doesn't mind if friends come inside the house, but following the object into the bathroom is going too far. That's one feature that I think is poorly implemented in C++ and JAVA, and if LV ever gets it on my watch, we're going to do something just a bit different...

QUOTE (jdunham @ Feb 1 2009, 10:54 PM)

... if the array is sorted!

Bah. "Median" is the middle number of the set... and an array is an ordered set. So I'll contend that for an array, giving the middle value is technically valid. But I will concede that the subVI in question gives -- what I would call -- the median of the sorted permutation of the array, which does make the finding of the median more difficult.

Having said that ... you recommended clustering the value with the index and then sorting... I wonder if that would really benchmark well compared with just calling Sort 1D Array, calculating the middle and then using Search 1D Array on the original array. Sorting an array can be done without any new array allocations, and the data movement is significantly less that moving around the value plus an additional 4 bytes of index. The Search 1D Array is linear, but a multi-core CPU might break that down pretty quick compared to the actual data movement incurred in the larger sort -- after all, if your data is type double then the double+int is larger than a single assembly "move" instruction.

[Note that for any array less than a few milion elements this sort of performance discussion is probably pointless on a modern CPU, but I find the thought experiment interesting nonetheless.]

The median is just the middle number of the array. In the case where the array has an even number of elements, the median is the average of the two elements at the middle. But the *index* of the median is always (size of array / 2) rounded up. So all you need are the Array Size function, the Quotient&Remainder function and the Add -- all of which can be found by searching the palettes. Just get the size of the array, use quotient and remainder to divide by two and then add the resulting remainder to the quotient. (If the remainder was zero, then you had an even array and you have the lower index; if the remainder was 1 then you have the index of the middle element of the array).

QUOTE (syah85 @ Jan 31 2009, 08:06 PM)

sorry, i do not know about "blob". can u explain me.

Most databases have types for the entries in their tables -- integer, string, key, char, etc. Generally there is one called "blob" which is used for storing binary data. Use google.com and enter "database blob" and you'll find a good chunk of info.

Post your best attempt so far and people are more likely to try to help you, but no one can help you from such a vague description. Upload your VIs. The community is far better able to answer specific questions than general ones.