Aristos Queue

Ok... this is just weird. Up front: I have not tried this exercise. I have heard positive things about it from other programmers. The link below is to an article that recommends writing 1000 line C++/Java/C# program with 9 insane restrictions on the code you write. These are restrictions that would probably be harmful if rigorously enforced in production code -- performance hits, slow development time, etc. However, as a learning exercise, they are intended to get you to think about your program in a more object-oriented manner. They force you to break certain habits you may have developed when programming procedurally. http://binstock.blogspot.com/2008/04/perfe...-and-short.html REMEMBER: These are not intended to be rules for actual production code. They are restrictions during practice. If we translate this exercise into LabVIEW, the challenge would be as follows: ================================================================ Your challenge is to write a LV application with the following restrictions RIGOROUSLY enforced. Consider writing a VI Analyzer test to make sure they're enforced. I'll offer this as your challenge application: <labview>\examples\general\queue.llb\Queue Stack - Solve Maze.vi Don't look at the block diagram before attempting this exercise. This example has shipped with LV since LV6.1, so everyone should be able to find a copy. No nested structure nodes. If you want to put a structure inside another structure, you need to create a subVI for the inner structure. The challenge is to meaningfully name that subVI. An exception can be made for the Event Structure, the Inplace Element Structure, and the two code disable structures. You can also have an exception for the Case structure that tests "error in" to skip a subVIs execution. Any Case structure must have a boolean input or an error input. In the "true" or "no error" case, you may write code. In the "false" or "error" cases, you may only pass inputs through to outputs. This prevents if-else chaining; and every routine does just one thing. No controls or indicators on any front panel may be connected to the VI's connector pane except LV class controls/indicators and error code clusters. This directly addresses "primitive obsession." If you want a function to take an integer as an input, you first have to create a class that wraps that integer to identify it's true role. This means that zip codes are an object not an integer, for example. This makes for far clearer and more testable code. And it prevents operations (such as Add) from being performed on zip codes. This restriction is already enforced by the LV language normally. Use only one dot per line. This step prevents you from reaching deeply into other objects to get at fields or methods, and thereby conceptually breaking encapsulation. This restriction is really not applicable to LabVIEW, since we don't type the text names of VIs. But the sentiment about naming your VIs well is still relevant. Don't abbreviate names. This constraint avoids the procedural verbosity that is created by certain forms of redundancy—if you have to type the full name of a method or variable, you're likely to spend more time thinking about its name. And you'll avoid having objects called Order with methods entitled shipOrder(). Instead, your code will have more calls such as Order.ship(). In LabVIEW, if you have a class named Matrix, you might have a member VI named DotProduct.vi. You should not name it MatrixDotProduct.vi Keep entities small. For any class, the private data control's front panel AND the block diagrams of ALL member VIs must be able to fit side by side, without overlapping, on a 1024x768 screen. This restriction forces concision and keep classes focused. It means that developers can take in the whole class in a glance. Don't use any classes with more than two elements in the private data control. So if you think you need 4 elements in the private data control, consider how you could create a class to wrap three of them and then include that other class as the second element. This is perhaps the hardest constraint. Bay's point is that with more than two instance variables, there is almost certainly a reason to subgroup some variables into a separate class. Commentators noted classes such as 3DPoint -- which needs 3 elements for x, y and z axis. This was answered that you could as easily have a three-element array as the member. The similarity of the three elements means we can group them; if they were sufficiently dissimilar that such grouping was not possible, then we would probably be able to create another meaningfully named class. Use first-class collections. In other words, any class that contains an array in its private data control should contain no other elements in the private data control. The idea is an extension of stopping primitive obsession. If you need a class that subsumes the collection, then write it that way. A good example is that 3DPoint mentioned earlier -- the array needs to be checked at the API boundaries to make sure it never has more than three elements in it. Don't use accessor VIs. Any member VI that unbundles or bundles data from the class should do something with that data, not just set or get the value. This is a radical approach to enforcing encapsulation. It also requires implementation of dependency injection approaches and adherence to the maxim "tell, don't ask." This restriction is one I'm adding for LabVIEW -- ALL VIs in the application must be members of some LabVIEW class. The author of this challenge has this as an unspoken assumption, but I figured it should be explicit for LabVIEW programmers. ================================================================ As I said before, I have not tried this exercise myself, so I cannot testify to its effectiveness. If anyone tries this, please post about your experience.

QUOTE (jzoller @ Jul 14 2008, 09:58 AM) True. But several of the style tests have the effect of improving performance. Here are some VI Analyzer tests that can find performance issues: Arrays and Strings in Loops—Checks loops to see if they contain Build Array or Concatenate Strings functions. Avoid using these functions in loops because each call to them requires a dynamic resizing of the array or string, which can affect memory and processor time. This test does not check timed loops. Coercion Dots—Checks the total number of coercion dots on the block diagram and the number of coercion dots on individual wires and compares them to user-specified limits. Enabled Debugging—Checks whether debugging is enabled or disabled. Disabling debugging improves VI performance. Wait in While Loop—Checks While Loops with front panel control terminals for structures or functions other than I/O functions that regulate the speed of the While Loop. Wired Terminals in Subdiagrams—Checks to see if any control or indicator that is wired on the connector pane does not reside within the top-level diagram. In order to avoid unnecessary memory copies, place control and indicator terminals that are wired on the connector pane should be placed on the top-level diagram. Unused Code—Checks for unnecessary code on the block diagram. Globals and Locals—Checks whether a block diagram contains global and local variables. Reentrant VI Issues—Checks for uninitialized shift registers and non-reentrant subVIs in a reentrant VI. Because reentrant VIs maintain multiple data spaces, unexpected results can occur when using uninitialized shift registers. Additionally, parallelism could be inhibited if the reentrant VI calls non-reentrant subVIs. Array Default Values—Checks charts, graphs, and arrays on a front panel for empty default values. Saving non-empty default values inside charts, graphs, or arrays uses memory unnecessarily. When the VI runs, it overwrites values wired to indicators on the block diagram. If a subVI is using the VI, the VI overwrites values wired to controls connected to the connector pane. Empty List Items—Checks listbox, multicolumn listbox, table, and tree controls to ensure that they are empty. The VI populates the contents of these controls when it runs, so saving a VI with contents in these controls uses memory unnecessarily. Overlapping Controls—Checks that front panel controls do not overlap. The test does not analyze front panel decorations. VI Saved Version—Checks that the VI is saved in the most current version of LabVIEW.

A comment about design patterns drawn from other OO languages in general: The "behavioral" patterns -- the ones that talk about having one object do an action while another object does an action, or about sending a message from one object to another -- are almost always realized in LabVIEW by substituting the word "object" with the word "VI". The data and interface patterns are fulfilled using LabVIEW classes. But the flow-of-control behaviors of LabVIEW are already encapsulated in an object: the virtual instrument.

In the VI's menus, choose Tools >> Profile >> Performance and Memory...

QUOTE (JDave @ May 15 2008, 11:50 AM) 1. I have read a definition of atheism and find it plausible. 2. I have met atheists. For these reasons, I believe atheism exists. :-) QUOTE (Justin Goeres @ Jul 11 2008, 05:13 PM) My wife made two loaves of bread last night with chocolate chips in them. But despite thorough mixing, approximately 80% of the chips ended up in one loaf. I am concerned that this means the entropy of the universe may be decreasing and THE SECOND LAW OF THERMODYNAMICS HAS BEEN REPEALED. Occam's razor suggests a simpler explanation: you have highly magnetic chips in the bread. Be careful biting into those loaves.

QUOTE (Yair @ Jul 11 2008, 04:52 AM) Nope. In this case, inside or outside the loop would be the same. I was just posting the diagram where I had generated both to prove to myself that they really did output the same thing.

Here's another way you could do it that would be more efficient.

SOLUTION!!! If you set the Window Run-time Position in the VI Properties dialog, the clones will all follow suit and appear in the set location. Unfortunately, my really cool idea for using a stack of semi-transparent VIs won't work... I can't make the panel color itself transparent, so the stacked effect of the panel gray is enough to completely hide the furthest back window, even with the palest of transparency settings. A bit of research found that this is a limitation of the operating system until very recently (in Windows at least) and nothing in LV will let me set the panel to transparent. *sigh*

QUOTE (Jim Kring @ Jul 9 2008, 10:57 AM) The irony here is that in this case, I'm wishing my clone was exactly like my original. I'm not looking for customization. :-)

I have a VI that is reentrant. I save the real VI at coordinates X, Y. On the block diagram, I put an FP:Open method call. When the clones run, they open up their FP, but the windows are staggered from the original VI position. I can see how this helps with debugging most reentrant panels, but in my case, I'm trying to put together a user interface where the clones all open stacked up on each other -- playing with transparency to fade windows in and out on top of each other. Does anyone know of an easy way to say, "Hey, dumb clone, open your FP in the same place as your original"?

No CARs have been filed matching the situation you describe. For the record, Save All should save all VIs in memory in all projects. Save All (this project) should save everything currently in memory in this project (note: it won't load VIs from disk that aren't in memory but are listed in the project). Any deviance from this behavior is a bug. I've just run through a bunch of "Save All" tests on a few different hierarchies and I didn't see any problems. Is there any thing special about the particular VIs that aren't being saved? Can you post a set of VIs that demo the bug? QUOTE (kevintho @ Jul 8 2008, 09:17 PM) I know this isn't true. I rely on that every day, and it works just fine... a VI need not have its panel open to generate the Save Changes dialog. Now, if you load a VI using Open VI Ref and then close the ref, you won't be prompted, but straight up closing the panel will indeed throw Save Changes. Again, if you can post a VI hierarchy that demonstrates the bug, it would be most appreciated.

QUOTE (neB @ Jul 8 2008, 07:35 AM) I'm not familiar with the term in this context. Can you post a link to an article describing this "active object" concept? I might be able to suggest a recommendation on how to implement.

Those are part of the LabVIEW DSC package, not part of LabVIEW itself.

QUOTE (Yair @ Jul 7 2008, 12:14 PM) LabVIEW does not have any metaclasses. LabVIEW Object is a class. It is the ancestor class that all other classes inherit from. When Tomi dropped the rectangle, he instantiated an object. An object is an instance of a class. There's no such thing as a "metaclass" in LabVIEW*. * unless you're talking about the C++ code in the LabVIEW.exe which contains a class "LVClass" which is the C++ class that defines what it is to be a LabVIEW class and inherits from class Library which inherits from ... well, something else. I've put this as a footnote because I felt it was important to specify what a metaclass would be -- if G code had one -- but I didn't want to confuse anyone who just wanted a straight answer and would just glaze over footnotes. QUOTE (Ton @ Jul 7 2008, 12:41 PM) Yes that's right, it's the reason LabVIEW names the front panel palette element 'LabVIEW object' No. We name the front panel element "LabVIEW Object" because that is an FP control for the class LabVIEW Object specifically. The data value of that control is an object. What kind of object? LabVIEW Object. If we add other class FP controls to the palettes in the future, they'll be named for their class. QUOTE (neB @ Jul 7 2008, 05:47 AM) Do plan on realizing UML in LV? Already done, and done incredibly well, by the folks over at Endevo. If you need UML, check out their UML tools. Very powerful, very clean user interface.

Could you instead do something where you read the project build specifications from the .lvproj file to determine what needs retesting?

Save the setting you want to a config file, the set the operate value to that saved value on load. You cannot change the default value for the VI when it is running -- that's an edit to the VI and we don't support those in the runtime engine.

QUOTE (normandinf @ Jul 3 2008, 09:24 AM) Virtual folders are supposed to be just that... virtual. Moving files physically on disk breaks source code control. I don't want to have to do a "perforce rename" command every time I change a VI from public to private, or whatever other organization scheme I may be using for my VIs. I don't want to have to make sure that all caller VIs are in memory so that they're kept up-to-date about the path change of the VI. To me, making the physical structure reflect the virtual structure is no different from putting "_private" in the name of the VI. It causes problems if you ever decide to change how you've got the VIs organized. Once you're completely done with development, you can use "Build>>Source Distribution" to create a particular disk layout if that's desirable for some reason.This is all just my opinion, not a rule. But, as has been noted, things do work better when you use a tool the way its designers intended. :-) Now, there are those who advocate the opposite, and for those people, the "disk sync'd folders" exist. I loathe the disk-sync'd folder feature. Why? Because it does not and never can work with libraries (including .lvlib, .lvclass, .xctl and .lvsc). The physical hierarchy and the ownership hierarchy cannot be simultaneously reflected in the tree, and the two features end up fighting with each other. But if you're just using raw VIs, you may enjoy disk sync'd folders. Assuming you're not using source code control, of course. :-(

QUOTE (neB @ Jul 2 2008, 02:26 PM) One class per directory. No subdirectories beneath that. Classes specific to a single project are in subdirectories next to the project file. Classes common to many projects are in another directory.

QUOTE (Phillip Brooks @ Jul 1 2008, 05:35 AM) Sort of. Not so formal. It would probably be closer to say there's enough downtime in any job such that if you want to work on something you can and, if it shows promise, it can, with minimal red tape and minimal hierarchy approval, become your assigned task for the next round. It is more true for R&D folks, but people in many different areas of the company move into R&D for a time if something they've built in their spare time looks useful. It isn't so much a break from your assigned task, the way Google's is, but more a high willingness to allow people to choose their next task when the current one is done.

QUOTE (Norm Kirchner @ Jun 30 2008, 10:12 AM) Ah. And there's the rub. No one could really justify putting in transparency for panels originally. The developer who did it just thought it was a cool idea and did it in his spare time. Now he's moved on to other things. Doing *more* work on a feature that was of dubious use in the first place is going to take lots of justification (cash or gallons of gasoline are considered acceptable forms of justification).

QUOTE (Justin Goeres @ Jun 30 2008, 09:03 AM) Here here!

QUOTE (bbean @ Jun 29 2008, 06:48 PM) No, there's not, but...QUOTE (Norm Kirchner @ Jun 29 2008, 10:53 PM) But will we be able to use it w/ the "In-Place" element structure?!!!!" No. Until this post, I never thought about it. But that would give us another major performance boost for the variant attrib storage mechanism. I'll pass along the request to the owners of that structure. If we did this, then, yes, there would be an advantage to the True case over the False case.

QUOTE (LV_FPGA_SE @ Jun 27 2008, 06:42 PM) Most benchmarks have found that the variant attribute (like the one you implemented here) is a fairly efficient lookup table mechanism in LV8.2 and later (it was dog slow before that). I'm surprised if the array version was able to keep up. I can say that the variant attribute model will get a further speed improvement in the next version of LV -- not much, but a bit. You might retry benchmarks when that becomes available.

QUOTE (xtaldaz @ Jun 27 2008, 12:39 PM) Keep drinking... it could be. :laugh:

QUOTE (Yair @ Jun 27 2008, 06:33 AM) I have no idea. That's how PStrs are encoded whenever they're flattened in LabVIEW data.