Aristos Queue

QUOTE (ned @ Aug 6 2008, 05:44 PM) Doh. That was dumb on my part. Here it is in LV8.2...http://lavag.org/old_files/post-5877-1218065546.zip'>Download File:post-5877-1218065546.zip

Here at NI Week, I've had a couple different customers ask questions about control refnums as they relate to LabVIEW classes. So I've put together a VI that has comments explaining these control references. As part of that, I had to explain Numeric control references, since the design decisions for classes mimic those of Numerics. That's another area that has been a source of misunderstanding in the past. Unzip the attached VIs then open the VI named OPEN ME_CtrlRefsInfo.vi VI Server is one of my weaker points in LV code, but I've tried to be clear to the best of my ability. I hope this helps. NOTE: This is saved in version LV8.6. I have attached LV8.2 version in a reply to this post below... Download File:post-5877-1218053451.zip

QUOTE (Norm Kirchner @ Aug 1 2008, 11:21 PM) How about this: Give Parent.lvclass a member of type "SpecificDetails.lvclass". When the XControl selects the type, you set the appropriate child of SpecificDetails.lvclass into the Parent object. Assigning whole objects always works better than assigning parts of them. PS: Is not that you're doing something "wrong" in the "this is bad programming and if the LAVA Code Repository had standards for LVclasses you'd be rejected". This is "wrong" in the sense of "it works but 9 out of 10 applications will expand to the point that they wish they'd picked an alternate architecture." But you might be that 10th architecture, so if it works, keep going. :-)

QUOTE (Norm Kirchner @ Aug 1 2008, 03:46 PM) Nope, that's the way to do it. You create a method on the parent class that takes two parents as inputs and unbundles one and bundles the results into the other.QUOTE I must be missing something....I would have imagined this would be easier. Why would you imagine this would be easier? What you've just asked for is something I've never seen anyone have to do in any OO program I've seen in any language. I strongly suspect that a change to your class architecture would negate the need for this. Generally, if you find yourself needing to do this, ask yourself whether instead of inheritance you should be using containment instead.

The LabVOOP team has a few goodies in the box for LabVIEW 8.6. Nothing major... you can safely assume some yet-unreleased project must've had my team and I distracted. *grin* But let's not talk about vaporware. You want to know the goodies that are ready now... The LV8.6 upgrade notes may be read in their entirety here. For your convenience, I have extracted out from this document all the features particular to LV Classes. The stuff in [ ] is commentary from me. In LabVIEW 8.6, all comparison functions (<, >, !=, ==, Sort 1D Array, etc) work with LabVIEW classes. [Details in online help files, but basically, they compare just like clusters do, with some rules for comparing classes of different types. But before anyone asks, no, you can't supply your own comparison routine.] LabVIEW 8.6 includes enhancements to LabVIEW class error reporting that might result in fewer unbroken class items listed in the Error List window. [Translation: Breaking one VI in a class now only breaks the callers, not the entire hierarchy and its siblings, and God-only-knows what else. You can all stop sending the protest e-mails now... :worship: ] The VI Hierarchy window displays LabVIEW classes and dynamic member VIs, XControls, shared libraries, .m files you reference from MathScript Nodes, Express VIs, and static VI references. ["displays LabVIEW classes" means we now show when a VI's only use of a class is using the class as a control/indicator/constant. Showing dynamic member VIs means a caller VI is now shown as a caller of all the override VIs, not just the ancestor implementation. ] The LabVIEW Schema palette includes the following changed functions:Flatten To XML—Supports LabVIEW classes and the fixed-point data type. Unflatten From XML—Supports LabVIEW classes and the fixed-point data type. [ :ninja: <<< All the other items had smilies when I finished typing this. I thought this should have a smilie too.] [*]Report Generation VIs: The Report Generation VIs were rewritten using LabVIEW classes. The report in control and report out indicator changed from reference number data types to LabVIEW class data types. [And, as a result of this, a lot of small issues that result from deploying a class in a toolkit -- such as the wire appearance drawing right in Context Help when hovering over the palettes without loading the entire class into memory -- have been worked out. :thumbup: You may all go forth and develop lots of LabVIEW class toolkits that other developers can inherit from to their heart's content.] Enjoy!

All these bugs were fixed in LV8.5.

Wish granted in LV8.6: new notifier primitives. Search in this document for Advanced Notifier Waiting VIs and Functions

QUOTE (Norm Kirchner @ Aug 1 2008, 02:56 PM) You already can. Pop up on the XControl in the project tree and unlock it. When done editing, pop up and apply changes.This was possible since at least 8.2 and I think it was in 8.0 when XControls originally released. (I wouldn't know... I really didn't use 8.0... 8.2 was a bit more important to me... you can guess why...).QUOTE (Phillip Brooks @ Aug 1 2008, 01:16 PM) Thank you, Aristos! You're welcome. Oh... and check out the Notifier functionality at the same time... another wish granted.

QUOTE (Omar Mussa @ Jul 31 2008, 11:05 AM) Well, you can load your top-level VI without loading a project. Then the child classes would not be loaded into memory. If you wanted to edit a child class while the framework was running, you could load the child in its own project (which is a separate application instance). To open a class' tree without loading a project, just pop up on any FP control of the class or BD constant of the class and select "Show Class Library". But other than that, yes, you're stuck. LabVIEW cannot predict when data of your child class will be unflattened from a string, loaded as part of a VI coming into memory, instantiated through the latest hack you've invented, etc. Once there's data, there can be function calls, and the dynamic dispatch node has to be ready to go. We can't delay the reservation because reservation must occur in the UI thread for safety, and that would force all LV class operations to be capable of swapping to the UI thread, which would eliminate a lot of our optimizations, even if it was a feature that was never used in your particular app. I wish that the project only listed the classes instead of loading them. But the architecture decision for that goes way beyond the needs of LV classes, affecting all library types (.lvlib, .xctl, .lvsc, .lvclass, etc). Not something I can get changed easily, though it has been discussed. QUOTE (Tomi Maila @ Jul 31 2008, 03:50 AM) Thanks for catching this major bug AQ! Do you already know if you manage to fix it for the maintenance release of winter 2009? I guarantee it will be fixed in a future version of LabVIEW. Beyond that, I cannot guess myself, and even if I could, I wouldn't be allowed to post the answer here. Sorry.

University of Oklahoma, Norman, Ok, USA

QUOTE (xtaldaz @ Jul 29 2008, 03:21 PM) Don't buy one. I have a spare you can try when you get here.

"When you have eliminated the impossible, whatever is left, however improbable, must be the truth." -- Sherlock Holmes Or, in my case, whatever is left must be the bug. I've been digging for the source of the performance problem with Map.lvclass (posted here). Various LAVA users posted performance graphs that showed significantly unexpected results: the class implementation of a map came in behind the array implementation. That flies in the face of every bit of computer science theory that I know. So there had to be something strange going on. I now have the answer. The problem is the To More Specific node. Now, if you're like me, you're probably asking, "How the heck could such a simple node be the source of performance problems? It barely does any work!" And that's the problem -- that node is doing way too much work. This node has a bug in LV8.2 and 8.5 that forces a full copy of the object to be made whenever the data successfully downcasts. A correct implementation of the node would not make any data copy -- the class data that was traveling on one type of wire should be the same data now traveling on a new type of wire. As a result of this bug, the Map was making hundreds of copies of itself needlessly. With the refnum data types, this really isn't a big deal -- they're just 32-bit numbers and duplicating one is pretty low overhead. But with a class, with all of its private data, it's a huge deal. What are the ramifications of this bug? First of all, whenever possible, LV class developers should avoid using the To More Specific node to do type testing -- use dynamic dispatch subVIs instead. That's just good programming practice anyway*, but this bug makes it even more important. Second, any LV class developer who is writing a nested data type -- one where the child class includes an instance of the parent class -- needs to be aware of potential performance problems if your data structure gets large. These problems will persist until this bug is fixed in a future version of LabVIEW. Some data types, such as a simple linked list, may be implementable without using To More Specific. But I have not yet managed to do this with the Map class -- at some point in every test implementation, I had to use a To More Specific node. There's just no way to get a parent wire changed into a child wire without using the To More Specific node, and those extra copies slow stuff down considerably. This was reported to R&D (#121514) for further investigation. * Why is type testing bad? If you use multiple To More Specific nodes to figure out which class an object is and then use a case structure to execute specific code, you'll create code that requires maintenance every time a new child class is created. And the type testing is done multiple times: "Is it this one? No. Is it this one? No. ...". Dynamic dispatching tests the class once and calls the right function directly, and if you have a new child class, there's no code to update.

Be aware when ordering the women's T-shirts for LAVA: they are extrordinarily small. We ordered a number of T-shirts as a group (to save on shipping). The two women's XL shirts *might* fit the average eighth grader. We sent back to the company to get the next size up in the hopes that it might fit better.

QUOTE (MikaelH @ Jul 28 2008, 04:29 AM) Norm: I take it back. I saw the full cirruiculum for the first time today. While I do think it will start off slow for you, I think there may be useful stuff in there come day 2.

QUOTE (Jeffrey Habets @ Jul 26 2008, 12:43 PM) Not quite. I can instantiate only one instance of the class *with that VI*. I could easily write another VI with its own uninitialized shift register that gives me a second instance of the class. Or I could have the class out on a wire and fork it off to many locations. A singleton guarantees that there is one and only one in memory *ever*. There's a shipping example that shows how to enforce that -- see examples\lvoop\singleton. The closest approximation of this to C++ code is function static data -- a variable declared inside a function using keyword "static". I think that the best name for these remains "functional globals". They are global variables implemented using a function.

It is not a control. It is a picture, drawn in some paint package. There's a picture ring control of the three images that LV uses for the splash screen (depending upon which modules you have installed). If you only have a static image, then just paste the .jpg onto the front panel.

QUOTE (Ton @ Jul 27 2008, 12:24 AM) It can. You may notice that the first time you save a VI that is a member of a library, you're directed to the same directory as the library itself. That little tweak appeared courtesy of the LVClass team, which got really tired of dynamic dispatch VIs getting saved over each other. When Yair says this is done by the OS, he's kind of right --- in the absence of other directives, the OS tracks the last used directory. In the past, this was less of an issue, but as LV has become more of a "large app" tool, I can understand the pervading frustrations.

QUOTE (Norm Kirchner @ Jul 25 2008, 11:19 AM) Probably this course is below your threshold of interest. It's for people who know LV but not LabVOOP. You already know the how and the why of LabVIEW classes. Send a flunky of yours and tell them to report back to you any interesting tidbits. :-)On the other hand, block off Thursday afternoon... I'm presenting a session then that should be more your speed.

QUOTE (JiMM @ Jul 17 2008, 10:05 AM) I'm accounting for the US Patent Office's occasional willingness to allow a patent on mind-boggling grounds.

QUOTE (Dirk J. @ Jul 17 2008, 10:25 AM) You know, a reference class is a perfectly valid form of class. I think the control references or any reference classes built with GOOP Toolkit would pass the test for being part of the conpane.

QUOTE (sukhiray @ Jul 17 2008, 08:15 AM) You find a patent lawyer to walk you through the patent application process. Patent applications typically cost quite a bit to research and file (you have to provide reasonable search of all the existing patents to assert that your idea really is new and unique). You should research copyright, trade secret, and trademark to decide if one of those is a better way to protect your software. Copyright and trade secret are both free to implement (although you can pay a nominal fee to formally register a copyright if you want that extra bit of protection). Trademark requires registration but is much cheaper than patent. 90% of software cannot be patented because it is simply an implementation of algorithms that already exist -- even if it is a new way of combining those algorithms, most of the combinations are "obvious derivations". That's why copyright is the tool of choice among most software developers for defending software.

QUOTE (Dirk J. @ Jul 17 2008, 07:51 AM) I kicked this around last night. I don't have any examples to post, but I think the answer might lie in focusing on this phrase: QUOTE adherence to the maxim "tell, don't ask." Suppose the answer is this: You shouldn't ever need to index the array from outside the array class. Why are you indexing the array? In order to do something to an element of that array. Shouldn't the index that we need to operate on be something that the array class itself calculated? If so, its own private data might contain an element for "active element", similar to how the multi-column listbox property nodes work. Search around on Google for commentary about this challenge... you'll find some interesting tidbits. Those tidbits make me think we're trying to solve the wrong problem. (PS: This actually is turning into a useful challenge, but you may not hear much from me on it for a while; I'll be traveling next week.)

QUOTE (Daklu @ Jul 15 2008, 07:49 PM) An excellent point. Let's use this... This text block represents the initial array. It is a 2D array of uInt16 which I ran through "Flatten To String" and then displayed in hex mode. Paste this text into a string control that is set to hex mode, then use Unflatten From String to recover the 2D array. 0000 000F 0000 000F 0001 0001 0001 0001 0001 0002 0001 0002 0001 0002 0001 0001 0002 0001 0001 0002 0001 0002 0002 0001 0001 0001 0001 0001 0002 0001 0002 0001 0001 0002 0001 0001 0001 0002 0002 0002 0002 0001 0002 0002 0001 0001 0002 0001 0001 0001 0002 0001 0001 0001 0001 0002 0001 0001 0001 0002 0001 0002 0002 0001 0001 0002 0002 0002 0002 0001 0001 0002 0002 0001 0001 0001 0001 0001 0001 0001 0001 0001 0001 0001 0002 0001 0001 0001 0002 0001 0002 0002 0001 0002 0002 0002 0001 0002 0001 0001 0002 0001 0002 0001 0002 0001 0001 0002 0001 0001 0001 0001 0002 0002 0001 0002 0001 0002 0001 0001 0001 0002 0002 0001 0001 0002 0001 0002 0001 0001 0001 0001 0001 0001 0002 0002 0001 0001 0001 0001 0001 0002 0001 0001 0002 0002 0001 0002 0001 0001 0001 0001 0002 0001 0001 0002 0001 0002 0002 0001 0001 0001 0002 0002 0002 0002 0002 0001 0001 0001 0001 0001 0001 0002 0001 0002 0002 0002 0001 0001 0001 0001 0001 0001 0002 0001 0002 0002 0002 0001 0001 0001 0001 0002 0002 0002 0002 0001 0002 0001 0002 0001 0001 0001 0001 0002 0001 0002 0001 0001 0001 0002 0001 0001 0001 0001 0001 0002 0002 0001 0002 0001 0001 0001 0002 0001 0001 0002 0005 The front panel itself you should be able to use directly. [by the way, the reason for not looking at the block diagram is that it is completely not an OO solution and for this exercise you don't want to taint your thinking.] QUOTE (Dirk J. @ Jul 16 2008, 04:33 PM) Edit 2: It seems that the collection problem is also raised in the origional post quoted by AristosQueue. Hmmmmm.... Yes, this sounds like a classic "How do you write Matrix times Vector if neither Vector nor Matrix can touch the private data of the other one?" For the index problem, I suppose you could write a function Get Value At Index.vi which does the following: I mentioned earlier that you should try to work within the rules and not try to hack around the rules. Honestly, I am not sure if this solution is hacking around the rules or working within the spirit of the rules. And then, after writing this, I realized that I still have a boolean output from one of my member VIs. This would be solved in C++/Java/C# by having this be a class output that had been taught how to behave as a boolean. We don't have that capacity with LabVIEW classes today*. I think that some more contemplation of the rules of this challenge may be required before we can really attempt it. * LV R&D does not make promises regarding future functionality.

QUOTE (Justin Goeres @ Jul 15 2008, 04:06 PM) Objection not accepted on the grounds that two VIs with the same name should be performing the same operation. If the parent class has a method called "Dot Product.vi" and the children also need a method named "Dot Product.vi", then the children are presumably overriding their parent's behavior -- thus the method should be dynamic dispatch, not static dispatch, and there's no problem. If the children are not overriding -- and thus the desire is for static dispatch -- then the VIs have no business being named the same thing. The reason for the "can't have same name as static in parent" rule is that the functionality "Dot Product" has been defined by the parent and the child must accept that or it isn't really a proper child. Let's take the very common case of "Init.vi". If the parent class needs an Init -- which does not have a class in but does produce a class out -- then you inherit from it, you may very well want an Init.vi on the child class. But this is a case of a concrete class inheriting from another concrete class, and the solution is to add an abstract parent class from which both of the concrete classes inherit.

A smart-alec co-worker pointed out that the rule about "only classes can be on the conpane" can be easily handled by passing everything to subVIs using global variables/queues/etc. This suggests that an additional restriction should be added for the hackers among us. However, since it is the nature of us programmers to see how far we can get within a set of constraints, adding that restriction would only lead to a long list of hack-prevention measures. So, let me say that the challenge can only have positive benefits if you willingly accept the restrictions. If you see evading the challenges as the goal, you will develop yourself as a hacker, but not as a software engineer.