Aristos Queue

This can be done now in one VI.

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.

Taking my previous statement about "static". In other languages I could put a static variable in one of the methods to count the number of times that method/function had been called. This would translate (I think) into a single VI method with local (to that VI) storage outside the purview of the cluster (i.e. only accessable inside the function but could be exposed via a terminal of that VI - the return value in other languages). Is this a similar scenario to what you are describing here? Or am I really out there in my understanding?

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.

Make them protected not private or give us a choice how to scope them with protected being an option!

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.

NI could learn from this...

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

The gist is to truly scope data to the BD of a single VI, discouraging abuse of exposing data across a SubVI (or even structure) boundary where it does not belong. Is this idea kinda like what you're proposing? Or an alternate solution to solve the same problem? (One obvious difference: this declaration would be held at the VI level, not the object level)

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:

What exactly do you mean by "(you) came up with a syntax"? Is it just something normal that anyone can do, or are you referring to LabVIEW's source code? I just haven't heard the term 'syntax' used in the context of dataflow programming.

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:

Can you give a concrete example? For this new feature, do you envision restricting fields to exactly 1 class method, or a defined subset of class methods?

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:

 

Could this syntax be adapted to specify certain class data as protected or community scope? That would probably be of more interest to me...

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:

 

but what I'd really need is a "this field can only be modified by this subset of VIs".

Yeah, that seems to be where I end up when I think about uses for this.

Wait... It uses a limited palette? WTF? Why? There's no good reason for that on today's hardware! Where can I get a copy of this modified icon editor?

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.

so now you have to download the source separately.

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.

I didn't mean a single VI with "Actor VI", of course a single VI can't do the job that efficiently. Actually I meant to say that some type of file .lvclass (say .lvactor) that will hold all the stuff (messages, functions, etc.) related to that actor. Currently you define actor by one .lvclass and messages to it are some other .lvclass; why don't we combine these together? I mean if you are using actors then these should be actors not objects. Anyway  it would be almost the same thing what we currently have, I thought if we abstract OO part from actors then it would be easier to play with them.

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.

PPS One thing I WOULD like is the ability to have static class methods with the same name but different connector panes.  That would be übercool.

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).

I think in Actor Framework things have been made pretty complex by mixing OO and AO.

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.

At this point I have a question that is Actor Framework reflecting what is described here:

http://ptolemy.eecs.berkeley.edu/publications/papers/07/classesandInheritance/Classes_Final_LeeLiuNeuendor.pdf

Yes, pretty much.

why not introduce something say "Actor VI"

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

They are orthogonal insofar as the implementations of either do not require stepping on the domain of the other, though they certainly may. A lot of this is philosophy of categorization. There's no right or wrong answer, really. To me, it helps to see them separately because it emphasizes the domain that each has when designing software.

On the question of whether LV is object oriented or actor oriented: Neither, inherently. Both of those are design styles, and they are orthogonal to each other. One speaks to a way of data packaging (object) and the other speaks to a way of controlling execution flow (actor). It is possible to design a system that is pure procedural, purely object oriented, purely actor oriented, or both. Such systems can be built in just about any programming language. Having said that, various languages provide syntax support to make it easier to implement these designs. LabVIEW supports object-oriented programming through the .lvclass files and related features. LabVIEW supports actor-oriented programming through the queues and VI Server systems. The Actor Framework provides syntax to unify the two, though there are plenty of other ways to achieve that effect.

 

As for the singleton pattern... I do wish that pattern would die. Yes, it is terribly useful and I use it all the time in C++. But I also get burned by having used it all the time. The single static instance of an actor/object (because you're treating it as the same thing in that case) makes it nearly impossible to fork two copies of your application or module within your application, and you'd be surprised just how often an app becomes successful and someone says, "Hey, let's run two of these side by side!" and suddenly that easy-to-implement global singleton that was so nice in the original version becomes a liability that is damned hard to refactor because you now have to rewrite your API to propagate a parameter to the far reaches of your program so it can know which of the two former-singleton objects to use.

This will give you the basic idea:

https://decibel.ni.com/content/docs/DOC-1180

 

You have some independent VI that the XControl spins up that controlls the blink rate of each LED. In this case, it is blinking all the LEDs in a particular pattern, but you could easily have them blink independently.

CancellationTokenSource and CancellationToken provide the same signaling functionality. I don't know of anything that has the data transfer built in, but you might look around in the same assembly.