Aristos Queue

To the best of my knowledge, the answer is "no". We've had the XStructure on the drawing board for almost a decade but no one has gotten around to building it. There's minimal impetus to do so... the number of control structures that we've built into LabVIEW over the years has been fairly small -- they still fit in one palette. Very very few ideas are put forth that call for a new flow-control structure, so no one has felt compelled to build the G mechanism for defining one. I suppose in theory you could build up an XNode that draws a very complex inner image and maintain all your own editor state operations for the fake diagram inside your node, but the work involved would be excessive in the extreme. If you look at the Sim.xnode, I think you'll find a bunch of stuff that isn't actually implemented in G. I know, for example, that their whole interior is back in the C++ code. I don't know how extractable that layer is for a different XNode.

Something is wrong with your library if you're getting hundreds of hits with that operation from vi.lib... or something is broken with that function. This feature finds items that will be broken when they load into memory because the library claims them but they do not reciprocate the claim. The library somehow thinks all of those VIs are its members. Weird.

jcarmoody: Yes. AS DOES ALL LAW. All law is based on the ultimate ability of a government to force compliance. Any sufficiently flagrant violation must be met with force or the law is meaningless. The whole point of the law is to make sure we are all conforming and to penalize non-conformity. That's the *goal*. Now, when we talk about ethical government, we talk about force commensurate with the particular law being broken. We talk about rational checks and balances on the use of force. We talk about law written to maximize certain principles and minimize others. Yes. Exactly. Now the open questions are:A) Is this a justified law? B) If so, what is the justified force to use in enforcing it? Those "appeals to emotion" that you hear are answers to these questions. Asking whether it is fair for X to be penalized if Y is allowed can be seen as an emotional appeal, but it is also asking the question of just balance.

I was, in all honesty, under the impression that it was covered by the various wire fraud laws, like the ones that prohibit pulling a scam over a telephone.

Nope... this one is password protected because that property is unsafe. Toggling the retain wire values at the wrong time causes LV to enter a bad state and crash. I have no idea if this is a technical limitation (i.e. adding the code needed to detect the crash and just return an error would require some change that would have a runtime performance impact) or if this is just a crash we decided not to fix. Regardless, this feature was not made public for a reason. As I've said before, we don't make things private just to be obnoxious. > Also, must every topic containing a mention of disabling LabVIEW's password "protection" turn into a moral debate? No. It is a moral debate from the beginning. It never turns into one. In this particular case, one could make the argument that the NI employee who posted this VI used poor judgement in releasing it, as the VI has the same potential flaw as the property node itself. There is nothing special about the VI that would make it any safer to use than the property node, which we deliberately made private. From that point of view, one would see it as a case of "R&D made the call to make it private, others who have access to private things decided to make it public without actually doing the legwork needed to make it public, but private things must be password protected to limit the spread of them, so they followed procedure and locked it down." Because there are times when wrapping an unsafe property node in some G code can turn it into a safe node, and in those cases, the node should be viewed as atomic... there isn't any "taking it apart" any more than you take apart a compiled DLL. Demanding to see the G code is absurd since all you're doing is disturbing the parts that make it safe to use. From another point of view, it is *mostly* safe, and releasing it as a VI on LAVA is vastly different from it being discoverable in the property lists of LabVIEW ... someone who gets that VI probably gets it from a place where it comes with the warnings about "may crash your LV", whereas someone discovering it in the property list would not. In neither case is it as "look how good I am". It is more that exposing it one way promotes it differently than promoting it another way. No one is preventing peers from learning anything. There isn't anything to learn in these cases. Doesn't even matter if they are making a profit from it. If you play a video game that you didn't pay for, you aren't making a profit. You're still stealing. Cheaper and free alternatives might *not* exist -- they definitely don't exist in the case of a game title, and often don't exist for specific types of professional software. Doesn't matter. If nothing else, you commit a crime by promising to abide by the EULA and then not doing so. That's called lying. Tell that to the game manufacturers... their software is *always* used for a non commercial purpose. :-) Even if you limit this to production-type software, there's a problem of the software author screwing his own paying customers. You have to be very careful ... if you provide your software free to one group and charge to another group, both groups can now produce whatever it is your software provides. That means you're empowering a non-profit group to completely undercut your paying customers. I have seen student projects worked up in dorm rooms that can be every bit as good as the professional software. You'll lose your paying customers if *their* market is undercut by labor willing to work free that has access to the same high quality tools. I'm not saying that there isn't merit in the idea, but it isn't the slam dunk you claim. Which would be problematic since then the VI wouldn't recompile for upgrades or alternate chip sets or when you change the compile optimization settings. You gained an ability you did not have by using your copied software. The owner has also lost an ability -- the ability to make further software. The owner has lost the chance to recoup the time, talent and treasure that went into making the software in the first place. Just as what you gained by your theft was an opportunity cost, what they lost by your theft was an opportunity cost. Measuring gain/loss based on first-order value is very 19th century. As any capitalist will tell you, money loses value just sitting in the vault. We measure the economic value of all sorts of things as what they could be traded for, not what they actually are traded for. Software is no different. Weigh the cost of buying the software vs the cost of writing it yourself. Flarn: I realize I have contributed to the hijacking of your thread, but I figure it's ok because I also contributed to the main topic at hand first. :-)

I hope what you are doing *is* fine. I would want to live in a world where it is fine. I tried asking our NI lawyers, without mentioning your name or pointing in LAVA's direction, whether this sort of thing is ok. You know what answer I got? It is *illegal* for our lawyers to answer that question on your behalf. We have published the EULA. It is up to you, in consultation with *your* lawyers, to decide what that EULA means and whether it applies to you, and if at some future point we feel that you are not abiding by the EULA, that's what judges are for. I was very plain... "Are you saying we cannot tell our customers what they can and cannot do with our software?" They replied, "Of course we can. That's what the EULA does. We can't put it in any other language as that would be considered a separate binding contract." Let me repeat, just so it is clear... this isn't an NI thing. This is the legal requirements of lawyers operating in the USA: they cannot give legal advice to clients they do not represent, especially if those clients are possible future opponents in court to clients they do represent. So then I asked the next logical question... can the *business* side of NI tell our customers whether what they are doing meets the EULA or not? Answer: Yes, but we would advise them not to do so because it wouldn't be binding. In other words, the EULA is binding, and if someone from NI says, "It's ok for you to do that," you might still be sued later if we decide we didn't mean it and as long as it isn't an official legal opinion, it doesn't amend the EULA. This is what is referred to as "adversarial justice", which is the style of law that we have established in the USA. Lawyers are meant to square off against each other and judges decide who wins. In the meantime, a company, indeed, an individual, should treat all other parties as legal enemies, even those that they are friends with in other domains, i.e., commerce. The more I learn about this stuff the more I am convinced we need a really different legal system for some of these modern constructs. By the way, here's a fun one... I heard about a company that has the children of workers come in after school to install software. The kids click on the EULA when doing the installation. Contracts signed with minors are non-binding, so this company feels that the software, by failing to validate the competency of the person clicking that I AGREE button, has allowed itself to be run without any of the EULA terms applying. Is this legally sound? Their lawyers think so and it hasn't been challenged in a court of law. And until you've been to court, saying something is legal or illegal is impossible. It is just what your lawyer says is likely to be legal. Yeesh. Good luck, flarn. At the end of the day, I think the only thing I can say is that as long as you're not wealthy from any revenue source, you're probably safe from lawyers. Probably. Although Rolf makes a good point about why you might not be. So if you're going to use any software you didn't write yourself, I think you have to retain a good lawyer. Unless your EULA requires binding arbitration, as some do nowadays. Yeesh.

Not meaningfully. For one thing, there's no syntatical meaning to that for the compiler to latch onto. For another, Timed Loops aren't on all platforms. And last, the EIO doesn't have any relation to the borders of the timed loop.

This would be "a field that you could declare to count how many times that particular data structure had passed through that particular method". So similar to static but with an added dimension of allegiance (I use that word in this context because I'm not sure how else to describe it). I suppose, describing it like that, it would be akin to having a database of "people". Then you have a "Look up records" function. Every time one person's record is looked up, the "# of times accessed" field would be incremented. Then you would have a record of how many times that person's records had been pulled up. But the only function capable of doing anything with that number would be the "Look up records" function... no other function even knows the value exists. So you *could* use it as a security check, "This record has been accessed too many times." And, like you said, you could make it an output from the function if you wished (like copying out the value of an uninitialized shift register). But at that point you're exposing the value out of the function, so isolating it to the function doesn't seem to make much sense. At least to me, at least right now at 4:20am. I am not seeing any useful data encapsulation that it buys you that private data doesn't already buy. If there is any value in it, it is in refactoring ... were I to delete the "Look up records" method, this field of the object would go away without me having to change the private data control. Similarly, if I added the "Look up records" method, I could add it to the object without editing the private data control. Akin to Java aspects? Maybe... worth researching. Although I've never really been too fond of aspects... They behave a bit too much like Befunge's "Come From" statement... any of you who have ever heard of the "goto" statement, well, Befunge, as a joke, added the "come from", so your program just jumps randomly when it hits a particular memory address, to some other part of the program. Totally impossible to debug. Aspects have that sort of "glommed on" feel. This might too, but since it gloms on it a more obvious way, it might have utility there. I'll put it on the back of my breadth-first-search queue.

Protected wouldn't make any sense in this case since it really would be just *one* VI, and protected implies at least two. So I think you're vote is the same as mine that there's not much use in a feature like this coming into the language. Like I said, it was something that cropped up when I was playing around, and I was trying to figure out if it had any utility. None so far.

It's just back-of-napkin stuff at the moment. I'm looking at Pi-Calculus notations and actor encoding languages and trying to wed them to the object models of programming. One expresses elegantly "data goes from here to there". The other expresses elegantly "data changes here but not there" and "this maintains similarity to that, with the following adjustments". That lead me in the direction of "What if data is not static on a wire? Suppose it were actually doing something as it traveled down the wire?" In other words, package up a still running state machine and send it, as it is running, down a wire to be transformed. Can we express that visually and, if so, what computationally interesting things fall out of it? Well, if a VI sans subVIs becomes something that other VI can act on -- and I don't mean act on as in scripting, I mean act on as in trigger or adjust its running environment -- then the local variables within that VI is object data. Does such an expression buy us anything? As Mje pointed out, no, not really, unless you can make it a set of VIs. Ok... so... oh, crap, ran out of space on the napkin. :-) If all this sounds like near nonsense, it might be. A lot of the time I spend trying to weld ridiculous ideas together and see what sort of chimera comes out. Most are genetically non-viable, a few are mules, useful for hauling but not reproducing on their own, and one or two turn into new unique species valuable in the environment. And about half the time, I lose the napkin, get bored, or move on to the next topic just because there's so much to explore and so little time.

On topic? No. Flarn, I get that you don't like that we only release features when they're actually finished and that you loathe the fact that we only promote APIs for the purpose they were intended and that we don't have a raw pointer to memory exposed on every diagram. Shaun, I get that you have little use for object-oriented programming, that you don't use the vast majority of its features and you hate what it does to the programmers around you. You've made your opinions known. Really. I don't mind the occasional snark, but can it please be accompanied by a response on the topic? I missed Jack's question earlier... Jack, yeah, the object level makes it significantly different. I don't think it would solve your problem.

Right... So... Back to the conversation at hand... Any proposals for utility for private-to-one-VI fields of an object?

Shaun: That whole argument is why you would use protected *accessors*. Those can be overridden to provide alternate behaviors. Fields can't be.

Flarn wrote: All languages have syntax. Dataflow isn't special in that sense. What does a For Loop look like? How do you declare "repeat this chunk of code over and over"? Compare the Shift Register to the Feedback Node. They both express the same concept but in very different syntax. To some degree, the Select node and the Case Structure are the same semantic meaning but very different syntax. My primary job over the years has been the syntax of LabVIEW: what visual elements constitute the block diagram of LabVIEW and how do we translate those elements into a semantic meaning. Let's take recursion as an example. Someone said, "A block diagram should be able to express a function calling itself." That's the semantic meaning that a LV user should be able to express. How do they express it? There's one approach of just putting the VI's own icon on its own block diagram. I argued strongly that it should be a structure node, not a simple function call node. Here's the syntax I wanted for expressing recursion: The structure reflects multiple calls to itself. New terminals are automatically added to the inner "recurse node" every time a tunnel appears on the structure node. That would be a very different way for a programmer to express a recursive function, but it has some major advantages (one, for example, is that the compiler has the ability to check the correctness and eventual termination of the recursive function because the decision of whether to recurse or not is broken out explicitly and the structure guarantees the existence of a base case). There's more to the proposal than just this single image (handling multiple interrelated functions, for example), but the point is this could have been the syntax of recursion in LabVIEW. And I still like it better as a model for recursion. What finally won was that a direct subVI was what everyone was expecting because that's what all other languages have, for good or for ill. So the syntax of LabVIEW is any visual element that has meaning to the programmer and to the program. I can make it easier to express things by changing the syntax of LabVIEW. The dynamic dispatch subVI is a syntax element representing a call to many possible subVIs. We could have represented that differently. We could have made it look nothing like a regular subVI node. An Express VI, with it's halo, is a syntax element, mimicing a subroutine call, but with additional configurability separate from the normal configuration abilities of wiring constants to the terminals. Although LabVIEW does not have a textual parser, there remains the human *visual* parsing of a diagram. Back to the topic at hand... What I've been playing around with is different ways of expressing data communication on the diagram, both intradiagram and interdiagram (both two diagrams on the same VI (i.e. between two loops) and diagrams on different VIs). As I've tried different ways of expressing such communication, I've looked at how would a programmer express "I want this communications path open from this diagram to that diagram and ONLY that diagram". As such, there's a degnerate case where the send and receive diagram are the same diagram. When I combined that with some of my ideas for changing the syntax of objects such that a single dataflow diagram can express both references and values (a way futuristic project that I'm not prepared to get into for a long while), I ended up with a syntax that would naturally and easily express "this is a field of the object that is only accessible on this one VI". Jack wrote: Not really... that's kind of what I'm fishing for here. Functionally, it would be like having a class "MyThing.lvclass" that has a private data control containing an integer X and X is restricted so that only "MyThing.lvclass:ThisOneVI.vi" could bundle or unbundle that variable. It would be so restricted that it wouldn't even show up in the private data control itself. It's state data that would only be usable within "MyThing.lvclass:ThisOneVI.vi". If you deleted that VI from the class, without having to make any modifications to the private data control, that field X would disappear from the objects. Such a field raises some interesting questions for serialization -- it could be serialized by the LabVIEW prims that have access to all the data, but writing something like my Serialization Library would be impossible because no other function would even know about the field. fabric wrote: No. This would be the opposite... *uber* private, where not even the other methods of the parent class know about this data. Protected and community scope data is an abomination against nature. Flog yourself with your mouse whenever you find yourself desiring it. This will either beat the desire out of you or at the very least destroy your mouse so you cannot contaminate your fellow programmers. Aitor Solar wrote: Yeah, that seems to be where I end up when I think about uses for this.

The good reason is that is all that can be stored within the VI because we've never bothered to expand it. Sure, we could render more colors, but we don't. One of those historical facts, and upgrading the compiler optimizations and making LV compile to VHDL have taken priority over the years above expanding the render capacities of the icons. Made available on ni.com following every release of LV (2011 and 2012 thus far).

Hm... this wouldn't provide any accessor VIs. Just entirely sealed up data inside the VI method.

I don't officially work on LV classes any more, but I still sketch out syntax ideas from time to time. Tonight, I had something weird happen when I combined a couple of futuristic ideas. Has anyone ever felt the desire to declare fields of a class that are private to a single method of a class? I came up with a syntax that would let me declare fields of a class as part of writing a VI that used that field, but it would be restricted to only that single VI. I couldn't think of any use case for such a thing, but then, I've never had a programming language that would let me declare such a thing. Maybe if I had it, I would have used it and found it invaluable. So I'm asking... suppose you could write a method of a class and in that method declare "this is data that is local to this VI but it becomes part of the state data of the object overall such that if the wire forks, this data would fork too." It's kind of like a local variable, but instead of being part of the VI, it's part of the object. Like I said, it's weird, and it just sort of came about as a result of some other strange syntax ideas I was playing with. I was wondering if anyone felt it was worth me exploring further.

Your idea is clearer now. I thought you were trying to pull inheritance out of the picture entirely. With the clarification, I am more agreeable with your idea. I certainly wouldn't rule out a better system of implementing actors+inheritance... I've got several sketches for such variations in my notebooks. :-) Having said that... most of my recent sketches have moved me in a direction that would not create a .lvactor separate from .lvclass but instead would move *all* classes toward being more actor-like. I'd like to be able to handle the by value data model and the by reference process model in a single unified code base so that there aren't two different programming styles depending upon which system you need/like more.

I agree with your analysis on the polymorphism. Jack's idea works better if we get interfaces first. No idea when that will be. I don't work on that any more.

I've been told that any thread safe class has to be sealed as anyone who inherits pretty much cannot be type safe because they cannot be given safe access to all the mutexes/locks.

GAHH. No. Overloading is not cool. It is the source of tons of bugs in text based languages, and the only justification there is the ease of typing. In LabVIEW, we don't type the names of functions, so saving them with different names isn't a penalty, and it keeps accidental shadowing from happening. I dug into that one *extensively* when planning out LVOOP. For LabVIEW, there's no upside there. The ability to aggregate several statics into a single selector in the palettes exists through poly VIs. That's a mechanism that could be more elegant, IMHO, but it does work if polymorphism in the editor is your concern.

Nope. There's no creator info stored in a VI.

manigreatus: Yours is certainly a valid way to look at it. What is key is that there is some communications mechanism between independent pieces of code. If that's a local variable for you, great. For me, that's always a queue/notifier/event as I have simply had too many problems with local variables to ever use them as a synchronization tool (even just a simple stop button runs into issues with mechanical action and requires extra code to reset the local, code that is too often forgotten). The AF is meant to solve hard problems, not to invalidate the basics of LabVIEW. When you start having a hierarchy of actors, need for lots of code reuse, or many actors that are similar to each other but not quite identical, then the AF comes into play. Yes, pretty much. Because an actor is not and cannot be defined by a single VI. A VI is one function. A .lvclass *is* simple -- it is a set of functions, and the Actor class defines an entire Actor. You just don't have the richness to define functionality in a single VI. Besides, most actors need private support functions.

National Instruments has published the canonical document on closing references in LabVIEW. This document codifies everything known about closing reference data types in one place and should be considered the definitive documentation for all questions thereto going forward. This supersedes any other documentation we may have published on the topic. If you find other documents that contradict this document, please CAR them or, if it is something like a forum post, refer them to this document. Closing References in LabVIEW http://www.ni.com/white-paper/14393/en

There is a very small book that I like to recommend to people. It is the best general programming teaching tool for OO that I know of: http://www.amazon.com/Object-Oriented-Thought-Process-Matt-Weisfeld/dp/0672330164