Aristos Queue

I have this weekend been studying a most fascinating document, analyzing the nature of object-oriented programming vis-a-vis Aristotle's conception of categories. The analysis leads to some very concrete conclusions. It is somewhat amazing to me that I've never stumbled across this sort of argument prior to this weekend. Thank you to AdamRofer for inspiring this Internet hunt. What follows is a single paragraph from the paper. I'd like to hear discussion on the pros/cons of the two definitions of "node" mentioned here: Personally, I find the block of gray text annoying in this day and age of font control and formatting options. Also, there's a typo in the paragraph, too, that you have to deal with. So let me restate the problem in a way that might be more readable: When programming a file system, one might consider two different class hierarchies: A 'node' is an element of a file system. A node may contain other nodes. 'Files' are nodes; 'directories' are nodes. Files are those nodes that choose to not include further nodes. Directories are those nodes that chose to include further nodes. A 'node' is an element of a file system. A 'file' is a node. A 'directory' is a node with the ability to include other nodes within itself. Which of these two class hierarchies is the better choice and -- here's the important part -- why? Should the ability to include other nodes be a capacity of the node class itself or a capacity only of the directory class? What are the ramifications between them? If we say that "file is a node" and "directory is a node", which definition of these classes best reflects the implementation? Side note: This is but one point of discussion highlighted by the document. Honestly, if I had read this three years ago, LabVIEW classes might have a very different implementation!

QUOTE(AdamRofer @ Apr 27 2007, 12:43 PM) So, Adam, your post made me go do some digging across the Internet. An interesting dig. ;-) You said this raised a new critique of OOP, so I had to go see what was up. The only section of the critique that I could find was the section already posted by you -- no further text appears to be available. The authoritarian site (cite) for this work would be here. Based on reading, I find that Aristotle believed in a tree of categories. Have you ever played the game 20 Questions ? You think of an object, the program asks you 20 questions about that object, and then tells you the object you're thinking of. Basically, it is a 2^20th decision tree, large enough to include all the items that a person might commonly think about. (the goal of the game is to find something that it couldn't guess, but that's a tangent from my point). Such a tree seems to be what Aristotle believed the world could be organized into. That very much resembles the presumption of OOP -- that there is one or more root clases (a presumed "root of all trees" class would be "things that we can think about"). The palimpeset raises concerns about such a hierarchy of things (see the quoted translation above). To answer the critique, Aristotle (or the OOP programmer) might reply that the critiques is abusing language. In the case of "footed", Aristotle might say, "It is ambiguous to ask about footed. You need to ask about 'animal-footed' or 'construct-footed', but not generic 'footed'. Using 'footed' is only valid in an already established context." This is akin to saying in programming that you can use the same class name twice, but only if you use it in different namespaces, and when both classes are used together, you have to use the fully-qualified name to specify. But that's a shallow response. After all, we really do have the same meaning for footed when talking about animals as we have when talking about beds. The critique is really pointing out the need for multiple inheritance and -- specifically -- diamond inheritance (A derives from B and C, both of which derive from D, thus forming a diamond in the inheritance tree, something that we discourage among human inhertiance). In this sense, the critique is not a new critique -- it is one that has been recognized by programmers over the years. The most recent answer to the challenge -- the one that I prefer -- is the JAVA interfaces, which create a secondary tree of attributes that map onto the core tree of objects. I am now thinking you meant 'new' as in "newly discovered", not as in "original." The critique is indeed a valid critique, but I didn't find anything in it that hasn't already been found by other thinkers about the problem. And, yes, it would be a valid critique of the classes as they currently stand in LabVIEW. Did I miss something?

QUOTE(Tomi Maila @ Apr 28 2007, 07:57 AM) It looks an awful lot like LV DSC. I've never used that LV module, but just from the visual, that's where I'd start. Cool graphic, by the way.

QUOTE(i2dx @ Apr 26 2007, 02:07 AM) The AE was wrong or you misunderstood. 8.2.1 installs to replace 8.2.

PS: A couple of the other posts are right -- you may have more luck finding introductory material over on http://forums.ni.com .

QUOTE(Submeg @ Apr 25 2007, 12:34 AM) When you say "takes you to" do you mean "opens the front panel for display, let's the user interact with it a bit and then when the user closes the panel he/she is back at the main VI" or do you mean "invokes a subVI to do some calculation" ? The phrase "takes you to" is used in other programming languages to mean simply "invoking a function" but gets a bit ambiguous when the UI is integrated the way it is in LV. Assuming that you mean the former -- which is what it sounds like but I want to be sure -- do this: 1) Launch LV and choose Help>>Find Examples... 2) Go to the Search tab and search for the keyword "buttons". 3) Double click on the keyword "buttons" in the list of keywords... this will pull up a list of examples. One of these is "Using Buttons to Initiate Actions.vi". May be helpful to you. 4) After you've digested that one, use the Search tab again and search for "events". In the results list, look for two examples. a) Old Event Handler.vi b) New Event Handler.vi Both of these show how to handle button clicks to launch subVIs. The Example Finder is your friend. Good luck.

QUOTE(tibobo @ Apr 24 2007, 03:14 AM) I can't say what is wrong with your particular build. The known issues for 8.2.1 recommends that if your build does not work, you should try changing to Do not disconnect type definitions or remove unreferenced members on the Additional Exclusions page of the Application Properties dialog box. If you are willing to share your app, please contact NI tech support and file a bug report so we can debug your app better.

QUOTE(crelf @ Apr 22 2007, 10:16 AM) What if we had some way to flag a thread as "if you regularly answer LAVA questions, don't bother reading this thread until the original poster posts more information." Just a signifying mark that shows up in the "view new posts" display, and posts a generic template reply along the lines of "Your post is incoherent and inscrutable. Your punctuation resembles line noise, and your grammer cannot be parsed by any known technique. What you apparently intended as mature information reads to others as the incoherent wailings of a wanton child. We invite you to try again in this thread, to clarify and elucidate, to rephrase and repost, in such a manner as the rest of the human race can attempt sentient communication. We presume you are capable of such communication. If you are actually a machine attempting the Turing Test for the first time, we congratulate you on your efforts but regret that they are insufficient at this time. Information that may help you learn how better to simulate a human posting to the forums may be found here." And then link to that info. When the poster extends/edits the post, the mark would disappear. Just a thought.

QUOTE(njkirchner @ Apr 21 2007, 09:16 PM) Two possible improvements: * an error code cluster wire doing a diagonal "S" squiggle across the icons like a mustache * or a blank space. After all, then you could point out that it "was here."

Thanks, all.

QUOTE(Val Brown @ Apr 20 2007, 01:17 PM) I first started learning about classes back in high school, where the word "class" had a very different meaning. For a long time I thought it was chosen because the keyword "class" delimited the section of your code where you taught your objects how to behave. It wasn't until college that someone pointed out to me that the word was short for "classifications", which would be a better term to use, perhaps, except that it is too long for programmers to type. ;-)

QUOTE(Thang Nguyen @ Apr 20 2007, 12:14 PM) If a process is going to do a "read modify write" then it needs to block other "read modify write" operatoins during the time it is doing the modification. Which means that a read has to block other reads. Although technically a "read modify write" doesn't have to block others that are just doing a read, it is a very rare application that needs that kind of functionality. A bank might have an object for a user's account. The bank might be doing a "read current balance, add some charges, write the balance back." During this time, should the customer be able to read the balance at an ATM? If the modifications are reasonably fast (and "reasonably" varies from process to process) then there's no real problem of the read-only process waiting on the read-modify-write process. Now, the objection can be raised that a read-only shouldn't halt all other processes. If a reader is going to take a long time before putting the value back, then it should read the value and make its own copy, freeing up the object for other processes to continue using. Here's the tradeoff : Either the read process is fine if other threads proceed with modifying the value, in which case having made its own copy is important so that it isn't sharing some pointer to a value with other processes that may be changing that value. OR the read process is not ok with others modifying the value, thus locking the value is appropriate. Trying to create a scenario in which multiple readers share a pointer and yet all readers halt when ever that shared pointer is updated by a writer is a nightmare in any system and one that really isn't worth supporting most of the time.

The LV shipping documentation covers this in more detail. Long and short of it ... when you open your application reference, wire a port number to the Open App Reference node. This should make the CBR work. The logic behind this is something we can discuss some other day.

Ok, I edited my original post. There's now a second .ctl file there in addition to the first one, and I renamed the first one to reflect that it isn't actually borderless because of the 1 pixel.

A marvelous walk through of OO design, complete with common points of failure, in the design of a coffee maker. Ashe, I expect you to appreciate this fully. http://www.objectmentor.com/resources/arti...CoffeeMaker.pdf Problem: All the example code is in JAVA. Need someone to convert JAVA to LAVA. Not a project I'm going to get around to doing, but I think would be useful for someone to do.

QUOTE(Pablo Bleyer @ Apr 16 2007, 01:56 AM) How can we know at compile time what Control Refnum you will be sending down the wire? The Control Refnum could be a reference to any control in LabVIEW, thus we have to be able to give you the data in a type agnostic format -- the variant. When you tell us what type you'd like, we check the variant to see if that type is what is there and give it to you if possible (we also return an error if the types turn out not to match). To say that we ought to have a more specific type on the value wire is a logicial problem -- how can we know the type if you only give us a generic refnum? Now, what you could do is change the data type of your FPTerminal... instead of using a generic Control Refnum, use a Numeric Control Refnum. If you give us a strict type in the first place, then we'll give you a strict type for the value. Like this: http://forums.lavag.org/index.php?act=attach&type=post&id=5536''>http://forums.lavag.org/index.php?act=attach&type=post&id=5536'>http://forums.lavag.org/index.php?act=attach&type=post&id=5536

QUOTE(Tomi Maila @ Apr 16 2007, 10:56 AM) Nope, I actually didn't know this. My last answer there was quite serious -- I don't know. I've never really dug into that code. I've never had cause to work with the G providers. Other members of the LabVOOP team handle that stuff.

Anyone using LabVOOP should upgrade to 8.2.1 ASAP. (If you're concerned about getting the upgrade, that's a discussion for a separate thread.) Thank you to Tomi for finding bugs in corners of LV that I didn't know existed. The combinatorial problem of testing a new feature against all existing features is always hard. With a feature such as LabVIEW classes, it's nigh on impossible to find all the interactions, and I expected bugs to be found. I didn't expect that 20% would come from a single user. Thanks for the dedication, Tomi.

QUOTE(crelf @ Apr 15 2007, 09:05 PM) Oh, let's see, what answers can I give to this one? Hm... "Carefully." "With a VI." "The same way the NI programmers do." "What's green, hangs on a wall, and whistles?" "I don't know, and I'm pretty sure I couldn't tell you if I did." Honestly, given how much documentation LAVA has about the mythical XNodes (one would think you people were anthropologists and not programmers given how much time you spend hunting that imaginary beast), I have been surprised that no one has posted anything about the project architecture. I mean, really, the project has been out for two versions of LV now, yet its secrets are still hidden. I mean, wow. It's enough to make me think that I could put an easter egg right on the splash screen when LV launches and it would slip right past all of you for a couple years.

QUOTE(Gavin Burnell @ Mar 29 2007, 04:37 PM) All these holes in the functionality. And you wonder why NI never releases scripting? It isn't that this is something "you're not supposed to do." It's actually that it is something that no one internal has ever needed to do so no scripting method has ever been created. The things you find when you dig into scripting are not the unshielded parts of some master document. They're the bits and pieces that various internal tools have needed to get their job done and nothing more.

QUOTE(Ami @ Mar 4 2007, 02:07 AM) The built EXE does not apply any optimizations that are not applied in the development environment. There are pluses and minuses to this approach. The minus, of course, is that seemingly obvious optimizations -- such as inlining -- are not performed in the one context where it seems they could be safely applied. The plus is that the code you debug on and the code you eventually release are identical, thus dodging one of the major headaches of development in other programming languages. Inlining is actually a bad example to use since the compiler really has a hard time recognizing that any given VI can be inlined. There are some big reasons: 1) The VI is the fundamental unit of serialization. If there are two calls to the same non-reentrant subVI, then those two calls will execute serially, guaranteeing protected sections of the code. If the VI is reentrant, then inlining pretty much doesn't buy you anything since the caller already has its own instance of the subVI to access. 2) Inlining a subVI could change the preferred execution thread of the caller VI. A VI that has components -- most commonly VI Server property/invoke nodes -- that require the UI thread will generally try to upgrade its entire diagram to run in the UI thread. But maybe you have a rarely used case and generally you want to avoid the UI thread. You can drop the property/invoke nodes into a subVI so that the caller VI stays out of the UI thread generally. Since that might be the only call to that subVI, it would look like a prime candidate for inlining, and undo the whole reason for using the subVI. 3) Since any VI can be dynamically referenced at any time in your code -- without a hardcoded path to that VI necessarily being present anywhere in the code -- the compiler doing inlining could conceivably break code. Could we add features to LV such that a user could mark a VI explicitly as inlined or explicitly not inlined (which direction would be the best default could be something of a debate). But then you get into issues of having to make non-programmers aware of the implications of choosing that setting, something that LV tries to avoid. And it's not often that inlining would buy you any performance improvement. Yes, there are many cases where inlining a VI will save substantially on memory and/or performance. But these are not the common case. Calling a subVI is a very efficient operation with overhead measured in microseconds. If you happen to find one of those uncommon cases, you can manually inline the code (I know -- not good practice to copy code, and a maintenance nightmare, but it can be done). If you're having performance issues, there are other places I would look first before inlining any subVI.

This would seem to me to be a pipe dream. I wish you luck, but I cannot believe there's hope. The project's UI is made to be plugged into, not made to be plugged in. Although the project is written in large measure using G code, it controls many of the underpinnings of LabVIEW and as such cannot itself use many of LV's features. I suspect if you do find a way to host the project, you'll also find many ways to deadlock LV's user interface.

QUOTE(Michael_Aivaliotis @ Apr 15 2007, 03:09 AM) Bundle is good most times, but not so good for a typedef. Typedefs would be the real value of this, I'm thinking.

Here is a .ctl file -- a borderless cluster. How did I build it? I hacked around in the debugger. But the resulting .ctl file passes all sanity checks and should be usable. The control file is saved in LV8.0. Borderless Cluster.ctl

QUOTE(steve m @ Apr 13 2007, 08:29 AM) A worthy suggestion! Please file it here so it gets properly reviewed: http://digital.ni.com/public.nsf/allkb/EDA7C01C684ACB6286256FF0000238D5' target="_blank">http://digital.ni.com/public.nsf/allkb/EDA...6256FF0000238D5