Aristos Queue

I have read your document. Will comment later. Maybe a lot later given current work load, but I wanted you to know I had read it.

QUOTE(yen @ May 9 2007, 02:52 PM)

It's not by-value, but that seems to be a good thing for most people.

If by "most people" you include C++ and JAVA programmers, then yes, I agree. If we restrict "people" to be the set of LV programmers, then I think your statement needs to be amended: "It's not by-value, but most people seem to think that's a good thing."

QUOTE(Wolfram @ May 9 2007, 03:48 AM)

I found out how to get this error dialog. See attached VI-Lib.

Hope this will help someone to get rid of this error dialog when

exiting LabVIEW or the application you made.

Wolfram

Bug confirmed. I'm investigating. I'll try to get back to you before the end of the week.

CAR 49882DJ1

QUOTE(Eugen Graf @ May 8 2007, 09:55 AM)

Why I should use another GOOP Tools? Its not possible with LVOOP (LV8.2) ?

Read the FAQ about this:

http://zone.ni.com/devzone/cda/tut/p/id/3573#toc2' target="_blank">LVOOP & GOOP

QUOTE(Tomi Maila @ May 8 2007, 08:14 AM)

In my experience it's quite normal that a LabVOOP project has unsaved changes immediately after it has been opened from the disk. Of course there really cannot be any chages but LabVIEW seems to think so and saves some VIs when one presses Save all.

8.2 or 8.2.1 ? To the best of my knowledge, all those are fixed in 8.2.1. If you know of a case that still has a problem, please file a bug report.

QUOTE(BrokenArrow @ May 7 2007, 10:53 AM)

If something is more than a few inches away or in a different frame, a local variable was used.

That suggests an idea: Could you write something using scripting to find all local variables for a given FPterm, display them in a list, allow the user to order that list, and then create a wire from one write local to the next read local, then delete the locals?

QUOTE(JFM @ May 7 2007, 01:51 AM)

This is probably more or less covered in your first point, but I think it is worth a separate entry.

* a "conditional disable" structure in a VI will cause recompile, if the active selection symbol changes.

E.g. using the TARGET_TYPE symbol in a VI that is used in more than one target. Opening the VI (or building applications containing the VI), will then indicate changes of the VI if it was not saved for the specific target.

/J

Ok --- then we should add

"Loading the VI in a new version of LV"

"Loading the VI for the first time after it has been saved for previous"

"Loading the VI on a new platform (saved on Mac, load on PC)"

I was sort of treating all of those as changes to its own diagram, but I guess you're right that the diagram itself isn't really being edited under those conditions.

In the ni.com DevZone thread, I mentioned inplaceness. I didn't talk about LV classes since those have their own oddities, which are being ironed out. I'll mention it here since you explicitly asked about LVOOP...

In LV8.2, let's be blunt: My team got paranoid. When a VI is a member of a LabVIEW class, we'll recompile it six, seven times on a single mouse click. Oh, that's a bit of an exaggeration, but it's a measure of just how far we went on a couple of fronts. There were a number of cases that we couldn't prove we didn't need to recompile the VI, so rather than have a VI that needed to be recompiled not get recompiled, we went to the other extreme and made sure that just about everything recompiled all the time.

I believe that LV8.2.1 has flushed all the paranoia cases out. I think I can now say the following with confidence:

A VI will recompile:

* for a significant change of its own block diagram (you can change free labels for example without recompiling)

* for a change of a typedef used on FP or BD

* for a change of the connector pane of a subVI

* for a change of a subVI's inplaceness

* for a change of a subVI's scope (public/protected/private)

* for a change of name (File>>Save As) of any VI, library, or other item on which the VI depends

A VI in a LabVIEW class will recompile for the above reasons and these additional reasons:

* for a change of the class' private data control

* for a change of the class' inheritance [meaning the class changes who its parent is, not just an edit to the parent]

I *think* we are now at the point where you could build a source distrbution of a class and all its ancestors and hand it out to other developers and then build a source distribution of just one of the ancestor classes and give that out to those developers... assuming no connector panes changed and no public/protected/private scope changed, the descendant classes of the replaced parent should not need to recompile. The goal, which I *think* we have achieved, is to get to the point where a LV class could be distributed as a module, saved without block diagrams, and you could provide new versions of the parent class and even in a built app everything would keep working assuming the parent's public/protected API didn't change -- that includes an inplaceness change. Inplaceness has been largely invisible in LV heretofore, and we want it to stay that way for the vast majority of customers, but in some cases it's useful to be aware of. I can't go into any details here, but there are features under development in R&D to help the developer guarantee that the changes made to a class don't change the inplaceness of public/protected VIs, to help guarantee that no recompile of child classes will be necessary when a new parent version gets released. As always on those rare occassions when I alude to features still under development, no promises are made about what version, if any, such features will ever appear in.

QUOTE(sachsm @ May 2 2007, 09:02 PM)

I was wondering if there is any plan to update the MsgQueue libraries so that they do not depend on the classic notifiers which one day may become deprecated.

Open up the "classic notifier" VIs... you'll find that internally they use the new notifiers. No plans to update any existing callers, nor to depricate the older VIs. We took them out of the palettes but they continue to ship with versions of LV.

QUOTE(Darren2 @ May 1 2007, 03:16 PM)

I am trying to decide what would be the easyest and most reliable way to control several machines that are running the same test program from a remote machine running a master program. Data Sockets? VI server? Web server?

VI Server will have the richest protocol for controlling (start up, shutdown, passing data) the VIs. Anything else will require you to develop your own protocols (such as passing a particular value over DataSocket and having a VI on the other end listen for that value and then interpret what needs to be done). With VI Server the functionality for opening, calling and closing a VI are already well-defined APIs.

QUOTE(PJM_labview @ Mar 20 2007, 11:45 AM)

Here is one for OpenG Developer (Feel free to improve)

{{OpenG Developer}}

The G seemed a bit closed. ;-)

http://forums.lavag.org/index.php?act=attach&type=post&id=5685''>http://forums.lavag.org/index.php?act=attach&type=post&id=5685'>http://forums.lavag.org/index.php?act=attach&type=post&id=5685

QUOTE(Tomi Maila @ May 1 2007, 02:41 AM)

AQ, was the LabVOOP project at NI just a regular project among other new functionality projects or did you leverage external programming language research knowledge by including related research groups or research scientists to the concept planning phase of the project?

There weren't any external-to-NI researchers on the team. The published design papers from many such researchers were used, and various members of the LV team have been hired because they were themselves knowledgeable about language design.

QUOTE(AdamRofer @ Apr 30 2007, 03:19 PM)

P.S. The article you link to looks awesome but I'm afraid a lot of people don't have a SIG or ACM membership, which appears to be required. Free web signup does not allow one to download this PDF.

Weird. I don't have an ACM membership -- I've let mine lapse the last couple years since I had access to most of the journals in other places. Yet I was able to download it. I couldn't get to any of the secondary documents. Seems like its a good thing that I saved it off -- perhaps a momentary lapse in their security?

So do I post the document somewhere or not? I guess not -- I thought it was a free download, but if it turns out not to be I probably shouldn't promote their security mistake.

QUOTE(Tomi Maila @ Apr 30 2007, 07:53 AM)

What would LabVIEW Object-Oriented Programming have been like should you have read the document?

a) Documentation. Should we have used "inheritance" as the best term for expressing the relationship between the super class and the sub class? We chose it for its accessibility to users without a programming background, but the article contends the metaphor breaks down in enough places that without an a priori understanding of inheritance, the metaphor isn't helpful to those who are trying to learn its meaning. Here's a paragraph from the document that talks about some of the problems with the term:

b) Proving the correctness of an object hierarchy. Here's a simple case: Class "Person" has two children classes "Female" and "Student". There's a problem with these classes -- they do not divide exclusively the set of objects in class Person. Situations like this do arise in code, particularly when two developers are both creating sub classes. Could the way we establish the inheritance relationship -- through the UI -- be modified to check that all child classes of a given parent use the same discriminator test?

c) The entire discussion about the critical need for all super classes to be abstract. This is one where I had treated it as "a good idea" to have abstract base classes and only instantiate at the leaf levels. The paper includes a proof that it is possible to have all possible hierarchies follow this theme and, moreover, a proof that doing so increases the logical correctness of code. See the section discussing "Is a Square a Rectangle or is Rectangle a Square"?

I spent part of last week sitting in on a Software Engineering capstone course at the University of Oklahoma. The students were working in a language called ACL2, which allows for them to not only code their solution but also to use an automatic theorem prover to prove that a given function is correct for all possible inputs, which blows the socks off of any empiric test suite which cannot possibly cover all possible test cases. This document raises many points for consideration that the syntax used to express the super-to-sub relationship can go a long way to proving the correctness of the code overall. A fascinating area to consider.

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:

Vlissides gives an example of exceptions (again in the programming language sense) being used to express the categorical negative proposition file nodes cannot contain other nodes [33]. His example models a hierarchical file system, which can be expressed by the following categorical statements: files are nodes; directories are nodes; a node may contain other nodes; file nodes are not nodes that can contain other nodes. He discusses the trade-offs between replacing the last two statements with directory nodes may contain other nodes, or keeping them as stated.

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:

1. 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.
   
   
2. 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.
   
   

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)

This refers to Aristotle's Categories. From the article Categorization: "The classical Aristotelian view claims that categories are discrete entities characterized by a set of properties which are shared by their members."

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)

Hmm.. I wonder if it would be possible to wire this with LabVIEW in real...

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)

I have a question about the LV 8.2.1 Installation:

An AE at the Hannover Industry Trade Fair told me, to install 8.2.1 in parallel to 8.20. When I start the LV 8.2.1. installer, it seems, it wants to replace 8.20.

Have you installed in parallel or replaced 8.20?

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)

I wish to have three buttons on the main VI. When one of these is clicked, It takes you to a subVI. I want to be able to return from this subVI back to the main.

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)

The executable crash at load time. Is there any way to know where the crash comes from ?

Building of executables is quite long so I would like to find a nice strategy to find out the cause of the crash...

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)

OK - I think I know what you're after now: you want a button that any user could press to suggest to the administrator that the post is somehow inappropriate for the forum that it's in - is that right? We've already got that - it's a button labelled "report" on the lower left side of the post. I figure a flag goes to the admin to check if the post's appropriate and then he/she can do whatever they like with it.

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)

Just thought I would have to chime in w/ my own little piece.

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)

and that's esp true in re: to "classes" as that's a term/word that just never "fit" well for me with what it was supposed to be representing.

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)

One of the problem I met when I work with this pattern is I can only get the variable of the object one time. In the meaning of an object, it's wrong here. I think we should be able to get the value of variable whenever we want without update these value.

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.