Aristos Queue
-
Posts
3,183 -
Joined
-
Last visited
-
Days Won
202
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Aristos Queue
-
-
QUOTE(MikaelH @ Aug 23 2007, 04:59 PM)
QUOTE(Tomi Maila @ Aug 23 2007, 11:34 AM)
Was it even close?
Answers will be posted over the weekend or possibly on Monday. :ninja:
-
This issue has been reported to R&D (4CML9UJ1) for further investigation. I've marked the CAR with screaming high priority. It's a test case that just got missed. Damnit.
-
QUOTE(jaegen @ Aug 23 2007, 10:50 AM)
Is this considered the final solution to this issue? I really hope that the end goal is to have a single *.exe with all the VIs inside it (with names "mangled" like they already are in the development system). Jim's "security through obscurity" issue is minor compared to having individual VI files out in the wild with every built executable.The "VIs not inside the EXE" bug (and, yes, I do consider it a bug) remains in LabVIEW 8.5. It is on the "must fix" list in the next LabVIEW version.
The end goal is to be able to store multiple files of the same name inside the EXE without mangling them.
QUOTE(Michael_Aivaliotis @ Aug 23 2007, 12:10 PM)
until NI forces us to use classes (which they probably will).No. NI probably won't. There are very few believers within the walls of NI.
-
QUOTE(Tomi Maila @ Aug 23 2007, 05:35 AM)
http://en.wikipedia.org/wiki/AVL_tree
a) the show buffers tool works fine for LV classes, and all those dots are places where buffers are allocated, but you need to know that allocating a new LVClass is dirt cheap -- 1 pointer in all cases since there's only a single shared copy of the default default value.
b) As for explanation of the various swap nodes and force copy blocks, read the LVOOP white paper and focus on the section titled "What is the in-memory layout of a class?" and the paragraph that starts with " For advanced LVOOP programmers there is a counterintuitive feature that we considered removing"
QUOTE(MikaelH @ Aug 23 2007, 01:06 AM)
BTW, how do you set the default data to a leaf Node in the Map class attribute named Root which is a Map Node Object?In 8.5, drop a constant of class Child and wire it to an indicator of class Parent. Run the VI and then use Make Current Value Default. Change the indicator to a control and move it into the private data control.
Make Current Value Default does not work for LV classes in LV8.2.
PS: This may be a situation that your UML tool should be aware of ... Class A may have a control of class Parent in its private data, but it may use an even lower Child class as the default value of that control. I don't know if you care to highlight such a situation in the UML, but it is a relationship that LV has to track in order to know to load the child class into memory whenever Class A loads.
-
Here's my attempt at implementing Map in LV8.5. Very straightforward. I need someone to write the tree balancing algorithm on one of the subVIs (Map.lvlib:Branch Node.lvclass:Node Insert Pair.vi). I don't have the patience to hunt down the AVL-tree balancing algorithm and make it into LV code.
You'll find some *fascinating* code that definitely only works in LV8.5 (uses the new inplaceness nodes) on the block diagram of Map.lvlib:Branch Node.lvclass:Node Delete Key.vi. 20 points and a bowl of gruel to the first person who can explain why the *empty* Sequence Structure is labeled "Do not delete". ;-)
NOTE: The attachment got deleted when LAVA was wiped out in early 2009. Here is a link to it:
http://lavag.org/topic/5983-map-implemented-with-classes-for-85/page__view__findpost__p__70238
-
If you have comments about the *overall* nature of LabVIEW classes, please post them here. Please don't post feature requests here. I'm interested mostly in getting a feel for adoption rates. I'd like to know how secure everyone feels doing professional development with LabVIEW classes. If there is a particular sticking point (other than you haven't upgraded at all yet) that is keeping you from developing with classes, I'd be interested in that.
-
The Get Default Value VI is new in 8.5. In 8.2, there was a property on an LVClass Library reference that would get you the default value. This was depricated because it does not work in the runtime engine. The subVI in 8.5 will work in the runtime engine.
QUOTE(Jim Kring @ Aug 22 2007, 05:19 PM)
The documentation says that all LVLibrary properties and methods do not work in the run time engine. Perhaps a specific method or property got mislabeled, but the top level docs are pretty clear on this point. There was some misinformation posted to LAVA by me early in the 8.2 release because I thought that the properties/methods were available in the run time engine. That lack of functionality lead my team to develop the 8.5 subVI.function fails (error 53: Manager call not supported) in a built executable (dispite the fact that the help docs claim that this method works in the run-time engine). -
Please file this with the NI Product Suggestion Center.
-
mane: Here's the post that covers specifically what you're doing:
http://forums.lavag.org/index.php?showtopi...ost&p=34203
QUOTE
To be able to convert it from a base to a child in runtime is not allowed, maybe it will be some day.No, it won't be allowed someday. As I explained in the other thread, that would be a major violation of encapsulation to provide such a generic casting mechanism. You're free to write such a conversion tool (as shown in the post above) for making children out of parents. But LV (nor any other OO language) will never provide such functionality directly. (Again, see the other thread for details about why.)
-
QUOTE(Paul_at_Lowell @ Aug 21 2007, 02:54 PM)
1) The problem only occurs if the method that calls the DataSocket function is wired with dynamic terminals. Rewiring these terminals as nondynamic (if possible) gets around the problem.The problem also occurs if you call Datasocket Open using a Call By Reference node. The problem is not restricted to LV classes. It is restricted to any dynamic invocation of the VI containing Open Datasocket primitive. The wrapper workaround works for this case as well.
-
QUOTE(Pana-man @ Aug 20 2007, 04:52 PM)
actually the opposite, I expect the parent class to access the data of the child class.And therein lies the design flaw. The parent doesn't even know it has children. All the VIs in the parent class are written in terms of nothing but the parent fields and the parent methods. Those VIs assume that the data on the wire is some type of Parent, but they can't know anything more specific. Child data may actually be on that Parent wire at run time, but it is behaving as its parent. An example:
Class Shape has data "anchor point" and four member VIs: Get Point, Move, Draw, and Tesselate. Tesselate simply does an iterative "move and draw" over and over to fill in a space. The entirety of Tesselate is written in terms of Shape.
At run time, a Circle may come down the wire. Circle has data "radius". It inherits an anchor point from its parent, Shape. Circle can't access that point directly, but it can use Get Point. Circle defines its own Draw method. Now when Circle is passed to Tesselate, the Tesselate function moves the circle, draws it, and repeats over and over... but the entire time it is not accessing any specific data of Circle. Only when the dynamic dispatch to Draw is done does anything specific to Circle get invoked.
-
I really want to know... what sound did your keyboard make? What is the sound of one hand typing???
-
QUOTE(i2dx @ Aug 19 2007, 02:05 AM)
QUOTE(i2dx @ Aug 19 2007, 02:12 AM)
www.labviewforum.decurrently: 2900 users with 33.903 postsYou'd think that of 2900 users, more than 33 would post something. And who only posts 9/10ths of a post? Definitely a strange place, this Europe of which you speak.
-
You didn't even mention the LAVA logo appearing on the LV splash screen.
-
QUOTE(jpdrolet @ Aug 18 2007, 03:26 PM)
AH. That looks like the elegant solution that I was hoping for. Yes, that looks like good LV style.
We should record that somewhere; add it to the recommended design of block digrams.
-
QUOTE(yen @ Aug 18 2007, 01:33 PM)
By the way, just to make it clear, the Show Inplace Set right click option does something different than the Show Buffer Allocations tool - it allows seeing all the points in which a specific buffer would be reused and as such should be more helpful in this case.It is, however, undocumented and as such might not work entirely as expected.
I've never even heard of this option. When you say "undocumented", that would include the internal docs. Where did you find such a thing?
-
Remember that the object is not holding onto the queue. The VI is holding onto the queue. The object is just holding onto a number.
The Endevo objects are still in existence because the VI that holds the objects is still running. If it were to go idle, your references to those objects would likewise go idle. You described them as referenced clusters. There's no such thing as references in LV per se. There are numbers that are indexes into an array of data. That array is still live because the Endevo tool is still running in the background.
-
QUOTE(NormKirchner @ Aug 17 2007, 11:19 PM)
Some of the string functions work with the picture string directly (most do not).
http://forums.lavag.org/index.php?act=attach&type=post&id=6680''>http://forums.lavag.org/index.php?act=attach&type=post&id=6680'>http://forums.lavag.org/index.php?act=attach&type=post&id=6680
-
QUOTE(silmaril @ Aug 18 2007, 01:40 AM)
No. What it means is that if the library is part of your project, you just drag and drop items from the project window to the diagram. If you've created a library for distribution (as a toolkit for others), then add a .mnu file that gets installed with the library.Wait a second... does this mean, there is a way to have a library that comes with it's own .mnu file in my project and whenever I load the project, I get an additional sub-palette in my functions palette?Your misinterpretation of my comments is a good idea however. I'll pass it along.
-
The queue references get invalidated when the VI that created them goes idle. Could this be the source of your problems?
-
QUOTE(Daklu @ Aug 17 2007, 05:19 PM)
The biggest objection I have to this solution is that it requires LV to evaluate all possible tests. In this particular case, the tests are all cheap, but one could imagine one of the tests being expensive (i.e. "if this number is prime" or "if this number is found in this array"). Even though LV will work to try to schedule the tests in parellel, there's still the cases where you shouldn't run one of the tests at all unless the previous test fails (if device is not installed { fail } else if device is not enabled {fail} else {success}). I think we should look for an idea that doesn't evaluate all the code paths.
-
QUOTE(Jim Kring @ Aug 17 2007, 08:55 PM)
But if your test harness calls private members of a class then the test harness must be a member of the class -- but, it shouldn't since this violates the "test harness never gets distributed with your production code" rule. It's too bad that LVOOP classes are so unfriendly to test harnesses
Depending on your view of class testing, this shouldn't be a problem. If the only part of your class that can be invoked is the public API, then a test harness that validates the public API is all you need. If there's a bug in an underlying private subVI, but that bug doesn't affect the public functionality, then who the heck cares? But, yes, your comment is noted. :ninja:
-
QUOTE(jdunham @ Aug 17 2007, 05:56 PM)
QUOTE(Omar Mussa @ Aug 17 2007, 06:04 PM)
So, in the end, a project does have a 1 to 1 relationship with aLVApplication (even though it is possible to 'try' to make it 1 to many) -- a definite shortcoming of the project environment.One man's shortcoming is another man's intended design. :-)
-
[LATER] Oh, I just thought of another solution that may meet with boos from some people... the Formula Node can do the if-elseif-else type work. You could use it to either do your calculations directly or to generate the aforementioned enum. It isn't dataflow, but it might be cleaner depending upon what you're testing.
"Get LV Class Default Value.vi" equivalent in 8.5
in Object-Oriented Programming
Posted
Jim:
Query... once the VI is loaded into memory, thereby loading the class, can you give a path to the Get Default Instance.vi that is just the class' name and have it work successfully? I can't look at the code right now, but my memory of how it is implemented suggests this might work.
-- Stephen