robijn

In most cases you can use this code for doubles. I think this is faster than any of your attempts so far !

QUOTE(LV Punk @ Sep 4 2007, 08:15 PM) This article clearly demonstrates very clearly points to think about when optimizing your generic classes. If you spend time to keep things organized well, you can save time later. Same goes for the balanced tree. Because of the way a balanced tree is organized and the "unpredictable" item-insertion time, it is a bad choice if we need real-time behaviour. However it can be very efficient and good for many problems. It's just that every structure has its own strategy and its own benefits. What I thought of while reading the article was, if we want to use objects in a real-time environment, we also need to think about cleaning up space after use. In by value semantics, object data space will in most cases be cleaned up when the VI execution has ended. If you have a complex data structure in there, you may first want to "clear" the object data yourself. The time needed to cleanup the data will then be spent right then, and not whenever LabVIEW feels like cleaning up. It would be nice to know more about when LabVIEW cleans up data of objects. Maybe AQ can shed some light on this ? BTW, I think also for by ref semantics real-time behaviour is possible, even with ref counting and auto destruction. I don't like scavanging, it's too unpredictable for a t&m environment. Doing the destructor call and the cleanup actions immediately when a ref is released and the object becomes unused (i.e. use count decremented to zero) means you know where in the diagram cleanup time is needed (or might be needed). Joris

Hmm I didn't look carefully and answered the poll incorrectly. I don't write with either hand (right only) so that wierd one can be forgotten... Sorry. Joris

QUOTE(Hacti @ Aug 31 2007, 12:35 PM) Hi, I think you need the DSC toolkit for that. It can connect to a supplied shared variable and it gives you a datasocket connection reference (IIRC). You will need an URL starting with psp:\\ Joris

A by value object can never contain itself. As in a cyclic graph it is a requirement to (indirectly) point to itself, it is impossible to implement this. Hacking with pointers is another story. But that's not clean programming. Joris

QUOTE(Aristos Queue @ Aug 30 2007, 01:32 AM) 3 hours, that's quick ! I like the consistency that you basically say "we have dataflow, now we just need to flow efficiently". So just make sure that the data arrives at the correct place in a single time, without accidently generating copies. A copy can probably not be prevented everywhere. And it is tricky: can you guarantee the efficiency when it's embedded in a larger application ? I.e. will the tree not become slow because of the way the tree is used in the app requires LV to make copies of the tree when a tree manipulation method is called ? Oh BTW, I think a user should never need to think about locking anyway (unless he wants something unusual). Read back my short story on multi-level locking (which works, proven). But that's of no relevance now. But you also still have the locking requirement: if you call a tree manipulation function from two places at the same time, you would still need to lock the entire tree to prevent one mutation to get lost. QUOTE(Aristos Queue @ Aug 30 2007, 01:32 AM) Let me be very clear here: If I do not wire the output of the Unbundle node, LV is correct to optimize out the Bundle node. Every rule of dataflow says that the execution of that bundle node should not be necessary -- there's nothing downstream from the Bundle node to need the data. Remember, we're violating dataflow here -- we're saying that we need LV to change the value on a wire even though that wire isn't going anywhere because the memory is actually shared with items that are going on down the wire. [..] thinks. I see a certain elegance to it, but this may be the same romance a moth feels for a flame. I think I know some fatal attraction Joris

Gee, you get into a lot of problems only implementing something simple as a map structure... Joris This page also contains some code. You can compare the clarity. http://www.cmcrossroads.com/bradapp/ftp/sr...+/AvlTrees.html Joris

QUOTE(Aristos Queue @ Aug 29 2007, 03:24 AM) I think there are two reasons why you would want public data: 1. easy of use (no methods needed to do the work) 2. speed (no method calls needed to do the work) I got to understand NI's way of thinking when I got told that the idea was to do much more optimization for methods. That solves the 2nd point. But for the ease of use I think there is no solution. There is a workaround to have public attributes: in Pascal they were called properties and they are also known as getters and setters. They can be used to seamlessly replace an attribute later in the class' life with a pair of methods to set and get. Users (i.e. other classes/functions) of the attribute will not notice the change. There is one fundamental problem with that, that it is impossible to get decent error reporting. So maybe to avoid getters and setters is best anyway. That leaves us with the current solution. I support it. QUOTE(Aristos Queue @ Aug 29 2007, 03:24 AM) But on re-reading, I think you're actually asking about the ability to display in the probe the full child data when the child is traveling on a parent wire. That data is really very usefull, because you often need to know the state of the parent to understand the state of the child. Hmm, I don't understand why collecting this data is very difficult... It a matter of checking what classes the current class consists of and displaying all their data. Actually I would think you have already done this work while building the object data list. You have no child-parent attribute overrides, so that simplifies the situation. QUOTE(Aristos Queue @ Aug 29 2007, 03:24 AM) No. You couldn't have dynamic loading at all. The whole point is to use this for targets such as FPGA where there is only a single deployment to the target and all possible classes are known at compile time. I think I miss something here. Dynamic loading of classes is a very important feature. For example for instrument drivers. It has to be available. But I think that was not the real reason this point was brought up in the discussion here, was it ? Was it only to be able to create an object of a given class by specifying what type it should be ? There is another way for that, a case structure. Indeed then all classes need to be known from the start. But they will be anyway on an FPGA because it cannot load code. And then they use exactly the described amount of memory. Was this what you meant, Jacemdom ? Joris

QUOTE(Tomi Maila @ Aug 20 2007, 09:39 PM) Why don't you just place the decoder settings in the decoder class ? They are the "properties" of that class. Each child class has its own settings as well. Why separate the decoder functionality from the decoder data (=settings) and create two worlds ? After all, object = code + data, they are one. Joris

QUOTE(Val Brown @ Aug 27 2007, 08:49 PM) It is a proved concept, long discussed in the computer science world. OK, that world did not have parallel programming natively (excelently presented at NIweek this year!), but for the rest most programming concepts are shared between LabVIEW, C, Java, Pascal and many other languages -- pointers not fortunately . In a way dataflow is also present in those languages, but only implicitly, not explicitly like in LabVIEW. LabVIEW is just a programming language, like many others, with advantages in certain areas. And I like its advantages a lot. Like editing a single VI and running/testing it right away. I don't want to write a program to test a simple function. Actually this is a point that has not been filled in in LabVOOP, it is not Rapid development yet. But I have no doubt that this is high on the list of the developers. QUOTE(Val Brown @ Aug 27 2007, 08:49 PM) Now I have no problem with this KIND of goal -- as long as it doesn't become mandatory in ANY WAY. I think co-existence is fine but dominance or demand for the "pure" OO implementation AS IF it were inherently superior doesn't really jibe with reality and it esp doesn't jibe with LV and it rich history of dataflow programming. I completely agree with you. I have always disliked the way objects are presented as "the solution for everything". I think you should use every feature for things that it is best at. Objects should in many places not be used, if you ask me. There are many places where they are very convenient, but also many places where they add nothing and rather distract from the simple things that are actually being performed. Joris

Hi, i have some time scanning / timezone conversion VI's available on my site. They still use LV6 style DBL's so are not really up to date, but they worked splendidly there. I have a temporary version laying around here that has the big TS's and is probably OK but I have not had time to release it. If anyone wants to try that TS version let me know. http://robijn.net/labview/ Joris

QUOTE(Aristos Queue @ Aug 13 2007, 10:52 PM) Yeah, operator overloading, brrr, scary stuff ! Joris BTW, objects do fit in in the original idea that I presented by starting this thread. The type of a class OR parent class should be settable in the case selector. If you were to insert a method of a given parent class, all derived (child) classes would also be accepted, because they "are" also of the parent type. Fits perfectly in OO philosophy. This ensures the VI can handle all known types connected to the typeless input VI. Of any child you usually know sufficiently via its parent. If not, you could define the child class behaviour in a separate frame. The child handling should preceed the parent handling, because it is more specific. You don't need this structure to do something on ANY type. For that you can use a variant. But then the distinction between types is lost, what I meant the structure for. With this structure, on type A you want to perform action X and on type B you want to perform action Y. Probably the results of the actions is alike (but that is not required). Joris

I am educated in computer science and I have tried to work with LabVOOP objects from the beginning. Those who have have followed the OO-by-value-or-by-ref debate know my position. I think they are quite unintuitive if you've learned to see objects as self-sufficient things, items you can command and query, and which have their own knowledge of the part of reality that they represent. LabVOOP objects are not self-sufficient. You need to do work to store the state and maybe lock that state if you are using the data from multiple places, which is prone to error. I know there are templates that implement that but they always have disadvantages, like a huge number of subVI's, extra code in the method VI's or wrapper VI's. This obfuscates the methods and makes the objects more difficult to use effectively. To summarize, the non-self-sufficiency is my main biggest problem with LV objects. As I've stated before, I think the behaviour would not really be that different for starters if the wires were referencing. Starters would not notice. But for an advanced user the by-ref behaviour is just so much more valuable. I really miss that. And only by-ref is ready for the future, with distributed objects anywhere. I don't care where my objects is physically located, I just want to use it. I know there has been a tremendous effort to get the object system working. I understand how much work it must have been and it must have been hard on the crew to have to delay the release of a new feature yet another time. But, despite the comments that I've made above, what you now have is really quite an achievement. So many obstacles have been overcome that noone thought in the beginning that would be present. Now place the final spoke and make it by ref. That unleashes the unrivaled potential that OOP has. Joris

QUOTE(Aristos Queue @ Jul 18 2007, 11:35 PM) Is this not simply all the available methods for the class of which the wire is ? Hmm, maybe I am now re-raising the debate about whether the wire type should be fixed or adjust dynamically to whatever you connect to it... I think it should be fixed, this should solve your whole problem, the callable methods are known then. You could create a non-obligatory popup to remind the user that he's connecting something wierd, offer him a menu with possible solutions: adapt method to type or keep type (and possibly keep error)... This maintains the strict typing, edit-time checking, and prevents automatic uncouncious adaptations by LV. Yeah, I'm a fan of strict typing... QUOTE(Aristos Queue @ Jul 18 2007, 11:35 PM) All in all, I've decided it is low priority -- if you're creating a class to be reused, when you're done with development you can create a palette by hand and set it to appear in the context menus (using the class' property pages). If you're still developing the class, just use the project tree as the palette -- it's close at hand generally. Yes you're right. Access to VI's to place has never been the biggest problem. I didn't know you could make a class appear in the context menu. Sounds nice. Joris

It seems like the C string parameter is now behaving slightly different on the DLL call. I have a function that requires a prealocated space, so I supply it with a string of sufficient length and tell the function in the next parameter how much space it is allowed to use. There is a difference between how LV 7.1.1 handles the returned string and how LV8.2 does that. The former leaves the string unbothered, even if there are null characters in it. LV 8.2 seems to think "it's a C string, so a 0 means end of string" and consequently it cuts the string just before this 0 character. This is usually good, but not always: often we knew that a C string was the same as a C U8 array so we used strings as medium to transfer bytes even if they could be zero. It seems we cannot do that anymore in LV8. Well, maybe it's better this way. Joris

Steaks, great. Count me in. What data do we need to fill in for the carpool ? Joris

I've always missed the possibility to use an array of indexes to index a single element of a multi-dim array. Just like having an array with sequential indexes that you just described, this could also be very convenient. It prevents quite a bit of wiring. But these features are conflicting. (although there's a way to have both by having the behaviour selectableby an option and a change in the node appearance.) I think with polymorphism appearing everywhere in LV having a multi-dim index in an array becomes more and more an interesting feature. I'v so far built my own functions to use a 1D array as an N-dim array by converting the indexes to 1D. Talking about indexes, I've always found the Array size node a bit strange. On a 1D array it gives a scalar, but on a multi-dim array an 1D array. This sounds ok, because there are not many reasons to have a 1D array with only one element. But a collection of scalars would be nice too (preventing an index array node). Why does the node not resize to the amount of dims ? Is this line of thought also what you meant, Mike ? Joris

QUOTE(yen @ May 30 2007, 07:52 PM) I have a central heater here that also supplies the warm water, from what I think is a french brand. I used to have a problem with the warm water getting cold after a few minutes. For routine inspection there came a guy from a plumber company and after a minute of looking at the machine he had established that everything was ok. So I told him it was not ok and there was a problem with the warm water after a few minutes. He explaned that he only had to check that everything was ok and he had seen it was. I explaned I did not completely agree with that. So he opened the warm water and saw it coming out warm and he again concluded it was ok. I almost got angry and told him it only occured after a few minutes. It was as if he just did not want to believe it. I almost had to guard the tap with my life to prevent him from closing it too early to prove it went cold after some time. But indeed it went cold. Now he was very surprised. It appeared that the water became cold after a few minutes... Hmm. What surprised me next though, was that he actually could fix it. He temporary removed a sensor and said he had to put in a new one and he would have to order it. We had a small but nice conversation and he told me about his son that was studying. He had seen some of the electronics stuff in my house and told me his son studied something in computers. And that he could not follow any of it. He was actually a nice chap once you got over the first bumb. Then he understood I could also plug in the sensor myself and he said it wasn't officially allowed that the customer plugs it in and everything, but the company would send me a sensor. I turned from almost angry to quite happy with the solution. I still have not received the new sensor yet after two years but I have stopped calling after a couple of months. The systems works like a charm however. Heating systems can be very strange. Joris

It would be a pity if I would only be at animal level We all like to think we're much better than animals. But maybe we're not that different in our stuborness. It's about religion and that's always a difficult thing to talk about. People feel connected with what they believe in. Then, if you say something "bad" about their sacred things, they themselves are also insulted. People have been bashing in each other's heads for these things for many centuries. And the first (self declared) atheists (amongst whom Freud) were not really welcomed either. So it's sensitive material. We can agree and disagree professionally on technical stuff, but if we disagree on our beliefs many people consider it becoming personal.

QUOTE(alfa @ May 23 2007, 05:53 AM) It seems I was not entirely correct. But he said similar things, I'm sure. However mighty Google gave me other answers: http://www.google.com/search?q=%22I+AM+CREATING+GOD%22 So there's a book and when you add Freud to the query: http://www.google.com/search?q=%22I+AM+CRE...+GOD%22%20freud you'll see this books mentions Freud. Tell me, what were your parents like, Alfa ? ============ So there's evidence after all: First published in 2005 by ALFA STRING 3892 Bathurst Street, Suite: 202 Toronto, Ontario, M3H 3N5 ISBN 0-9739852-0-8

QUOTE(alfa @ May 21 2007, 01:05 PM) Sigmund Freud did. Joris

Hello oopers, I've got a presentation to do next thursday on OOP in LabVIEW. I have to confess I have not done too much with LVOOP so far, I just have a hard time thinking in objects that I cannot reference. So I also have no good idea on how to create something that can be used to store data in a hierarchy without too much of a hassle. I would be interested to hear from anyone that has built a nicely working tree structure. There was a thread of Tomi here about this subject. But unfortunately he mentioned it couldn't do recursing the tree. I consider this pretty vital, so if anyone has one that can recurse/traverse the tree I would be rather interested. Or any other template or pattern, because I'm just gathering all kinds of OO stuff to learn how people did things with LVOOP. Joris

QUOTE(dsaunders @ May 10 2007, 07:43 AM) Oh, you don't mean the option to search a VI in a VI and its subVI's ? That's just in the standard search function, but you need to press Ctrl-F in the root VI of your search tree. Joris

QUOTE(Eugen Graf @ May 9 2007, 06:58 PM) You could try my Time scan/format functions (http://robijn.net/labview/''>http://robijn.net/labview/' target="_blank">http://robijn.net/labview/). They still use the DBL time format, but work fine. I have not updated much lately, I do have a "modern timestamp" version laying around but I yet have to finish the Excel conversion function yet. You could use a modulus 100 twice as well. Joris

QUOTE(Jacemdom @ May 9 2007, 07:14 PM) I have an axis. I can control a stepper motor to change the angle that the axis is at. For that reason I have created a class A and created one object of it, X. Now, when I call X.goto(30) the axis rotates to a position of 30 degrees. The object stores the position of this axis because next time we need to rotate from this angle to a new angle. For example if we need to go to 45 degrees, we need to rotate only 15 degrees. That means the current state is stored in the object and used to calculate the new movement. In C, Java and other languages that have referencing class systems, the programmer of the class has means make sure that he always has full control of the state of the object. With dataflow, like in LVOOP, if you connect a wrong wire your object data gets mixed up, gets lost and/or gets currupt. It is very very easy to make an enourmous mess of your object data in this way. Let alone what happens if you have parallel access to an object that is stored in some repository. Retrieving twice and then storing twice results in loss of one of the two mutations and can only be prevented in an easy way by locking it, but this may give deadlocks. Preventing them is quite difficult. I guess a search on "parallel universe" should give more examples of these problems. Joris