Aristos Queue

QUOTE (Jeff @ Dec 21 2008, 11:14 AM) The solution I would suggest (for minimum code changes AND minimum data copies) is as follows: create a protected-scope member VI named "Set Parent Values.vi" in the parent class that takes two Parent objects in and puts one Parent object out. Call them Source Object in, Destination Object in, and Destination Object out. Make the Destination Object in be a dynamic dispatch input and the Destination Object out be a dynamic dispatch output. On the block diagram of this VI, drop an Inplace Element Structure. Create two Bundle/Unbundle pairs on the border of this node and unbundle both the Source and Destination objects. Grow the terminals so that all the elements of the class are unbundled. Inside the structure, drop N "Swap Inputs" primitives. Wire one element of the unbundle to each of these nodes, and then wire the results to the other side of the structure node. What have you built? This is the single VI that you need to edit when you change the private data of the parent class. It provides a mechanism for child classes to override the standard behavior. There's a lot of other tidbits in here. Check out the attached files... unzip and open Demo.vi. http://lavag.org/old_files/post-5877-1229884239.zip'>Download File:post-5877-1229884239.zip

QUOTE (normandinf @ Oct 15 2008, 09:23 AM) And it will stay up-to-date conpane wise if you edit your VI or do "save as: rename" to change the VI file name, or if you move the nearest implementation from the immediate parent to some older ancestor or vice versa.

QUOTE (Eugen Graf @ Dec 8 2008, 07:11 PM) Dynamic dispatch VIs cannot be reentrant only in LV8.2. They can be reentrant, with shared clones, in LV8.5 and later. QUOTE Would anybody explain me why I should share clones? Why LV doesn't lock this setting in a VI even if this setting creates such errors? I've answered the first question elsewhere and perhaps someone can find a link to the explanation. But as to your second question --- why doesn't LV lock this setting? because when I implemented reentrancy for dynamic dispatch, I just didn't think about it. I'll go file a bug report to myself and perhaps someday that will get changed. Thanks for the suggestion.

QUOTE (Nate @ Dec 18 2008, 01:11 PM) Hello, Nate. As the lead architect for LabVOOP, I can give you some authoritative answers. With regards to accessing data in the private data control, Paul is correct. All the data members of a class are always private, so checking that a VI does not attempt to unbundle or bundle any class other than the one it is a member of is easily done at compile time and doesn't need to be done any time else. With regards to accessing member VIs in a class, scope checking is done in four places: At compile time When a VI loads into memory When a VI tries to open a strict VI reference to another VI in memory (does not apply to a non-strict VI reference) When a VI tries to call the Run method of a non-strict VI reference There is not any checking done at runtime for individual subVI calls -- we assume those are all checked when the VI came into memory or when it was edited after loading into memory. QUOTE I'm hoping the only thing that prevents it is the fact that the child class should be broken at design time by the LabVIEW compiler, LV classes are designed to be binary independent of their ancestors, so a built app can load a revised ancestor class without having to have re-compiled versions of the descendant classes [see note below]. As long as the public API is unchanged, the children should be unbroken. But, like VIs, we check for the interfaces matching when we load the class into memory. Again, there is no overhead once we get running, but we do take a few processor cycles to verify that the dynamically loaded class is everything its parent said it should be. [NOTE] When we were surveying folks years ago for what they would expect/need from LabVIEW classes, one of the significant items mentioned was this binary independence. "If my app dynamically loads a parent and its children into memory, I want the ability to ship to my users a new rev of the parent class without having to redistribute all the child classes, and it should work as long as the parent public and protected API is unchanged." To the best of my knowledge, with the exception of a single known issue (see below), this works. And yet thus far, 2.5 years after LabVIEW classes became available, I have yet to hear of any customer actually using this feature. If any of you are using it, I'd like to know how that's going. The lone exception mentioned above is if you add a new private VI to the parent class, if any descendant class already had a VI of that name, it will break. Private VIs in the parent class should not affect the child classes in any way, but the bug is that they steal the VI name for all their descendant namespaces. This bug has existed since the original introduction of classes in LV8.2 and my team has repeatedly prioritized other work ahead of fixing it since we have never heard of anyone being actually affected by it -- it was found by users doing exploration of class features in the early days after the release. The bug would possibly get a lot more attention if anyone were actually doing independent rev distribution of classes for built applications.

From a logical point of view, you are correct that no there's no reason that LabVIEW should disallow a notifier of a class being inside the class itself (or a queue or an array whose default value is an empty array, or a datalog or indeed any other refnum type with the class embedded inside it). After all, although the data *type* may be recursive, the data is not. From a language simplicity point of view, it's just a lot easier to explain "LV does not allow a class to be used as part of its own definition." than to go into the intricacies of why an array would have to have a default value of zero length, or try to puzzle out the error list window when such a circular class breaks. This is ESPECIALLY true when we start talking about circles of greater than one step (i.e., A includes B which includes A). From a language implementation point of view, there are plenty of performance shortcuts that can be made when loading a class into memory if we assume that all classes that are not broken are ones that do not include themselves in their definitions. Class unloading is complex enough without having to try to find "in any given circle of classes, identify which one is the reference one and allow it to unload first". Because the need for circular definitions is particularly rare compared to the total number of classes in the world, and because such need is typically encountered by advanced programmers, and because such programmers can and do stumble upon the idea of using the parent class in their child class definition to achieve much the same effect, points of view #2 and #3 trumped #1 during LV's design process.

QUOTE (sachsm @ Dec 19 2008, 07:50 AM) The canonical solution is the static VI reference, introduced in the same version that the case structure optimizations went in. And, for the record, if you change the constant to a control then LV won't optimize it out -- at least, not in any version of LV that has shipped yet. It is entirely possible that LV could decide in a built application, where the Front Panel has been stripped out, if the bool is not on the conpane, then the case structure could be optimized. Not that I'm saying that change is coming... I'm just saying that you probably want to use a static VI reference.

What you want is a new object based on an existing object. You happen to be asking about the special case of having a parent object and wanting to create a child object. You think, "Well, gee, I already have the parent fields, surely the programming language will just let me fill in the values, and then I can set the child values. Why do I have to create some function that copies all the parent values into my new object?!" But that special case of parent-to-child has all the same problems of arbitrary object-to-object. Let's examine... Suppose you have class Thing and class Stuff. Both of them have exactly the same fields for private data --- an integer, a string and a path. Now, because they have the same private data, LabVIEW could, in theory, allow you to cast a Thing into a Stuff or vice versa. But that isn't allowed. Why? There are two reasons: Those fields have meaning for their objects. In the Thing class, perhaps that integer is always an odd number and in the Stuff class the integer is always an even number. Perhaps Thing enforces a rule that either the String or the Path are always empty, but never both, where as the Stuff class never allows either one to be empty. The APIs of each class control the data values that can be set in objects of that class type. The data is private. Assigning from one object to another directly because the fields happen to be the same would mean that we were taking public advantage of private knowledge, and that if at some point the private details of either class were changed then public functionality would break. That's exactly the sort of thing that is not supposed to happen. So, obviously, simply changing one to another cannot be a built-in part of the language. Any time you want to be able to create a new object from an existing object of another type, you, the LV user, have to write the transformation function and assign the fields as desired. Now, you're interested in the more specific case of parent-to-child. In this case, we can rule out reason #2 because any time the parent class changes, the child class will change in the same way, so the cast would always be possible from a pure "can this data be copied here" standpoint. But reason #1 still applies: Suppose Parent defines an integer and a dynamic dispatch method "Set Integer.vi". The Parent implementation takes an integer as input, multiplies it times 2 and bundles it into the cluster. Child has its own override of "Set Integer.vi" which takes the input, multiplies it times two, and then does Call Parent to the parent verson. In this case, the Parent API has enforced a rule to make sure that the integer is always an even number. The Child class has gone further and made sure that this integer is divisible by four. The fields that a child class inherits from its parent are settable only through the parent's API and thus must conform to the parent's rules. But the child class can put more restrictive rules onto the fields. So even though the data types are the same, and even though the parent API is used to set those fields, those fields still might not be acceptable as values of the child. If LabVIEW allowed any VI to simply cast from parent to child, there would be no way for you, the programmer, to enforce rules about the consistency of data that are specific to a child class. You may read this and think, "Fine, don't let *any* VI do this cast. Just give the ability to the child VIs to take a parent object and downcast it." But the parent class may have some weird rules. One of its fields might be a refnum, and when ever you try to set it in a new object, a new refnum is allocated, or something like that. And so, no, LabVIEW cannot provide this arbitrary construction under any circumstances.

QUOTE (neB @ Dec 19 2008, 08:57 AM) Nor have most people succeeded in that domain. Could it be that some crucial connection between the two is missing? Does it feel, perhaps, unfinished...? If it feels that way, yet again, you are not way off...

QUOTE (shoneill @ Dec 17 2008, 10:35 AM) You're not way off. QUOTE (jdunham @ Dec 17 2008, 12:22 PM) Bringing this back to the original question, I would focus on OOP first, since it can change the way you think about programming, usually for the better. I agree. The XControls are useful only for UI heavy projects. Classes start becoming useful about the same time "Create SubVI from Selection" is useful, and for many of the same reasons.

QUOTE (Milchbilch @ Dec 16 2008, 03:25 AM) The "Open class reference" is a reference to your class. What you are looking for is a reference to your object that is an instance of your class. These are two very different things. No, there is no object reference built into LabVIEW. You have to do something that dynamically creates a data storage location. Your options include opening a new VI [either by duplicating a template or cloning a reentrant VI] which you could then use to store data either in controls [through the Value property] or in uninitialized shift registers [as per functional global] creating a queue or notifier of the desired type using some sort of global VI with an array of objects and adding a new position in the array etc... I'm sure there are more if you get creative The class reference is a reference to the .lvclass file itself. You can use it to query the class definition (who is my parent class, how many methods do I have, etc) and to do editing to the class (change wire appearance, etc). It does not give you a reference to an actual object.

The latest revision of my LabVOOP Design Patterns document -- with some revisions and with all the implementations filled in finally -- is now available. Unlike previous versions that you downloaded from somewhere, this version is in a WIKI so that the community can help maintain, extend and comment about the document. http://decibel.ni.com/content/docs/DOC-2875 This document takes several of the design patterns from the Gang Of Four book, originally written for C++ and similar languages, and explores how to implement those patterns in LabVIEW.

Open the Context Help window and then hover over the wire and you'll see exactly what type of wire it is. On one side of the wire's red X the CH will say one type. On the other side of the red X, the CH will say the other type.

QUOTE (jzoller @ Dec 14 2008, 03:48 AM) More specifically, it specifies as N gets larger, how does the time needed to complete the algorithm grow. So if I have N items in my array, saying an algorithm takes O(N) means that the function grows linearly -- double the number of items, double the amount of time. If it grows O(N * N), aka N squared, then if I double the number of items in my array, I expect the time to increase as N squared. In general: Any polynomial, even large ones like N to the 10th, is considered a good "solvable" algorithm. Any exponential (2 to the Nth, or N to the Nth, or worse) is considered a bad "unsolvable" algorithm since those would generally take longer to compute than we have time to wait for any non-trivial value of N.

Post your best attempt so far and we may be able to help you from there, but an open request like this is hard to answer without just giving you the answer. You probably want to read the online help for the "Scan String for Tokens" function. At the bottom of the help is links to shipping example programs that should help you.

Here: Download File:post-5877-1229132728.vi Very fast and saved in LV8.6.

QUOTE (Jim Kring @ Dec 12 2008, 01:23 PM) The poly VI brings all of its subVIs into memory with it, so if you drop a single VI, all the member VIs load. A couple of us in R&D have worked for years to remove this limitation, but no success yet -- too many aspects of polyVIs break when you don't load all the instances (how do you make sure all the conpanes match, for example).

QUOTE (P. Rosegger @ Dec 12 2008, 07:27 AM) To the best of my knowledge, there is nothing in LV that will let you do what you're looking for. If you don't want to drop the case structure, etc, yourself, the only solution that I see is to pay someone else to laboriously write the VI and then use theirs. And pay them to maintain those VIs for every new version of LV, of course.

If you are a LabVIEW user who writes or maintains large applications (which I'll define as "large enough that off the top of your head you can't name all the VIs in your project"), there are two new resources on NI's website that you may be very interested in reading. The first is http://ni.com/labview/power This static page of information is a collection of all the white papers, recomendations, design ideas, etc, that NI has ever published for large-scale development. It has been compiled with contributions from every segment of National Instruments and will be updated over time to provide you the best practices for LabVIEW app development. The second is http://decibel.ni.com/content/groups/large...ion-development This is a collaborative space where both NI folks and LV users can contribute documents dedicated to Large App Development. We're hoping that those of you who maintain blogs on the topic will post links to your blogs here. We hope that you'll share your horror stories and success stories alike, so that other users may learn from those experiences, and so NI can get a sense for the areas most needing improvement.

Naresh: If no one is able to give you a detailed answer here, try posting on http://forums.ni.com/ni/ as more DAQmx insiders are likely to be monitoring those forums.

QUOTE (orko @ Dec 10 2008, 02:26 PM) No such thing as "too much" if you're serious about building large scale software. Keep drinking... there's more coming...

QUOTE (shoneill @ Dec 9 2008, 01:21 PM) That's everything I know on the topic, and I don't even guarantee that it is fully correct among the various versions of LabVIEW. I know I've seen a version of that VI that had to worry about that case. Whether that was for a LV way in the past or far in the future or currently shipping, I do not know.

QUOTE (crelf @ Dec 8 2008, 10:24 PM) *He* was a bot, actually. Sorry, crelf...

QUOTE (Michael_Aivaliotis @ Dec 8 2008, 04:29 PM) Really? It should be fixed? Because I still get the ads and have for many months.QUOTE (normandinf @ Dec 8 2008, 06:21 PM) I can see you're a Star Wars fan... Um... Darth Vader's line was "It is useless to resist." "Resistance is futile" is Star Trek, not Star Wars. Man, what kind of geeks are we allowing on these forums these days?!

QUOTE (vugie @ Dec 9 2008, 05:38 AM) System colors aren't handled by just splitting the number. The 32 bit number uses 24 bits to encode colors. The other 8 bits can encode system colors -- colors that resolve to whatever your operating system settings say they should be.

QUOTE (BrokenArrow @ Dec 8 2008, 04:38 PM) There is no cluster view of LabVIEW classes -- the data is private and there is no way to get access to it (including FP access) other than through interfaces the programmer exposes (FP access can be exposed through an XControl if the programmer chooses). You may have inherited code written with one of the GOOP toolkits, perhaps?