Aristos Queue

QUOTE(Michael_Aivaliotis @ May 22 2007, 01:53 AM) Did you mass compile the directory <labview>\resource ? Nevermind... 8.2.1 is a full installer so all the VIs ship mass compiled. I forgot about that. I don't know what would be causing your slowdown. ... the failure to mass compile can affect my development build, but if I use a real install of 8.2.1, it's just as fast as 8.2.0.

QUOTE(Jim Kring @ May 17 2007, 09:08 PM) So... it sounds like County Line *does* have tradition on its side... I'd back the County Line -- I've been there for a couple large gatherings and it can handle the crowd.

QUOTE(Jim Kring @ May 17 2007, 03:55 PM) Simple! Create a LV2-style global that wraps around all "Open ..." and "Create ..." functions, returns the value to you in a variant (which you can then change to the specific data type). That VI should hold an FP reference to itself, intercept both the AppExit event and the PanelClose Event, and provide whatever clean up for the refnums. Disabling the Abort button is easy -- just have a loop in memory that polls for all open block diagrams/front panels in memory and clones a reentrant VI that itself doesn't show the abort button and have it float over the relative position of the abort button on each panel and diagram. Now all the holes should be plugged -- you can add ways to early dispose the refnums as needed by adding other actions to your LV2-style global. Honestly, I can't believe OpenG hasn't already rolled out a tool to do all this.

QUOTE(Jacemdom @ May 17 2007, 12:24 PM) As a short reply, let me know if there's another section that you want me to specifically comment on. As I read it, the rest seemed to be explanation of how you came to your suggestions and the advantages of those suggestions.

Yeah, I voted for "somewhere else". But after that I realized I didn't have a better suggestion, and seeing as how everyone else is good with Salt Lick, just pretend like my vote was for Salt Lick too.

Well, it took a while to dig into. But I (with help) found it. Turns out to be a bug beyond just Notifiers. A refnum acquired by any VI or its subVIs is supposed to be released either by an explicit call to a primitive that closes the refnum or auto-closed by LV when the VI stops running. Well, for subroutine VIs, the auto-close just was never happening for all refnum types. The refnums were leaked. In the case of Notifiers, the problems you saw at exit was caused by trying to shutdown the notifier system with notifiers still in existence. Most refnums won't have the same crash behavior (in fact, Queues, which are tightly related to Notifiers, do not crash). But all of them leak. Workarounds I can think of... a) Call Release Notifier as part of your VI's execution so you don't rely on the auto-close b) Make the subVI not be subroutine priority. c) With the functional global, you could have an input on the conpane for Notifier In. When you pass Not a Refnum as the input, the functional global would use the value last stored in the shift register. If you pass a value, then that value would be stored and passed out as the output. This allows you to initialize your Notifier outside. This bug will be fixed in the next release of LV.

QUOTE(aka @ May 15 2007, 07:00 AM) That should work. There are examples that ship with LV. Check those out.

Gray probes are probes where the type of the probe doesn't match the type of the wire. This almost always happens from having a wire that is a typedef, putting a probe on the wire and then changing the type definition to be some other type. If the probe itself doesn't use the typedef'd type, then the dot on the wire will turn gray instead of yellow.

QUOTE(Aitor Solar @ May 15 2007, 05:49 AM) With thermometer example, I don't see a crash with either 8.2.0 or 8.2.1.

Dear Jacedom, Only two sections of your document seem to need a reply. 5.3.2.3 is your idea of defining the entire class hierarchy in a single control of a cluster of clusters. 5.3.3.3 is your idea that all data would be public. The 5.3.2.3 idea is similar to how the classes work under the hood. You, the user, create each class independently. Behind the scenes, each class is represented by a cluster of clusters -- all the clusters of the ancestors clustered together with the current level of data. As I said, it is similar, but we don't create the branching cluster structure that you propose. Something like that structure is being toyed with for getting classes onto targets that have to have fully preallocated data -- every object on those targets would be a composite of fields such that the whole was capable of containing all possible descendants (obviously no dynamic loading on those platforms). The idea is a good one, but it doesn't really work for the editing environment. Problems with having them all in the same cluster up front: 1) You couldn't have multiple users creating child classes of a parent, since they'd both need to be editing the same file. Integration would be hell. 2) You couldn't dynamically load classes -- every descendant would always be in memory. 3) The parent implementations would be open and visible to the child implementations. You'd lose the independence of separating implementation from interface. As far as "all data would be public"... you are hereby banned from using the word "encapsulation" ever again. The disadvantages of public data and the advantages of private data have been so thoroughly talked about in so many forums I'm not going to go into them here. We do need to make the process of creating accessor VIs simpler. But making public data would be a disservice in the extreme to developers (yes, that's my opinion, and yes, I just stated it as fact, and you're not going to make much headway with any counter argument).

The 8-dot-3 file names are there because they were required for some platforms and the printing code has never bothered to change. The system is in general a good idea, but you should consider picking more meaningful abbreviations for items since the option exists.

FYI, in LV8.2 and later, it is possible to replace the built-in icon editor with one of your own. To read about it, open the Icon Editor, click on the Help button and scroll to the bottom of the help topic.

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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) 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) I'm not sure yet. Among the points of consideration: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: The term ‘inheritance’ is often used in a metaphorical fashion in ob ject-oriented programming to describe the relation between a sub-class and a super-class. Here we compare the meaning of the word inheritance with five kinds of transference relations: that of a prototype and its imitation; incremental modification; the Darwinian relation of evolution between species; the Aristotelian relation of logical abstraction between a species and a genus; and the Aristotelian relation of logical abstraction between an individual and a species. We include the incremental modification relation here because it has been said to be the ‘essence’ of inheritance (or, more precisely, incremental modification in the presence of a late-bound self-reference [35, 32]). We find that ‘inheritance’ seems to be an acceptable metaphor for the first three relations, but that it is an exceedingly poor metaphor for the Aristotelian relations of logical abstraction. 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.