Aristos Queue

Steen, thank you for posting this information. I have held off replying in this thread... I'm still trying to take all of the content in and formulate a reply, but I can give some feedback at this point. Your first post is a set of use cases. However, all three of them make assumptions about what the code needs to do, a bit too late in the design process from where I hope to intercept and redirect. Take the "stop parallel loops" for example. The way you've written the use case, there's an unspoken assumption that the code requires a special communications channel among the loops in order to communicate "stop". This particular problem is *exactly* the one that a group of us inside NI have spent over a year debating. We found a wide variety of techniques used in various applications to do this task. After a lot of analysis, where we were looking for ease of set up, correctness, inability of a stop signal to be accidentally missed, etc, we came to a conclusion. I just typed that conclusion and then deleted it. I am unsure what the best way to approach this is, whether to bootstrap this conversation with some of the preliminary ideas of the small group inside NI or whether to let this LAVA post develop and see whether the results that develop here are the same as have developed in our small group. The problem is debating all of this over threads of LAVA is a LOT harder than doing it in person. I'm going to be presenting some portion of this content at NI Week this year -- I'm still working on the presentation, and at this point, I have no idea how much I'll pack into the limited time I've got. Ok... let me try this and see how it goes. Continuing to focus on "stop two parallel while loops." Suppose we have two loops, Alpha and Beta, both in the same app but not on the same block diagram. Let's ignore "stop" for a moment and focus on the normal communications between these two loops. Global VIs, functional global VIs, queues, notifiers, user events, local variables, TCP/IP, shared variables, etc... We've got a list of about 20 different communications technologies within LV that can all be used to do communications between two loops. Suppose for a moment that Alpha is going to send messages to Beta. Alpha was written to have two queues, one for high priority messages and one for low priority messages. What does Beta.vi look like? Assume that it, like Alpha, is an infinite loop that does not error checking... what I want us to focus on for the moment is how it receives and processes the messages from Alpha. Assume that the goal is to call a subVI "Process Message.vi" for each message, but don't waste time processing messages in the low priority queue if there are messages in the high priority queue waiting. If it helps, feel free to assume that an empty string is never a valid message. How efficient can you make Beta.vi? Does it sleep when there are no messages in either queue? How much wiring did it take to write Beta? Is it more or less wiring than you would expect to have to wire? How does the complexity of code scale if the architecture added a third queue for "middle priority", or even an array of queues where the first of the queue was highest priority for service and end of the queue was lowest? What are your overall thoughts on this communication scheme? [LATER] I have now uploaded three different variations that work for Beta.vi in a later post. But before you skip ahead to that answer, I encourage you to try to write Beta.vi yourself. It's a really good LV exercise.

Nope, that's the only one.

Right... renaming still preserves a lot of the history because any child class that tries to unflatten its old version may need the mutation records of the parent as it was.

Ever get the sense that the scripting API is a hodge-podge of features that we built as we needed them for our own internal needs and then released to the public because users said having it was better than nothing? If you do, that's an accurate feeling. :-) If it's any consolation, we have a couple guys who have been spending the last couple years polishing on it, and they continue to work on it more.

A game is unfair when someone changes the rules. Life is a game. As a teenager, all the rules are changed by forces outside the player's control. By that standard, being a teenager == unfair. The biggest problem, of course, is that English allows you to stop after the word "unfair." We have transitive verbs which require a direct object. This is a situation that would benefit from some sort of "transitive adjective", where just speaking required you to fill in the blank "unfair between _____ and _____". Unfair, after all, requires an imbalance between two parties. There is no "unfair" in a game of solitare.

It's just the place where they manufacture the CDs/DVDs. No development or other manufacturing is done there to the best of my knowledge. There is a sales office there, but I doubt that's of interest to you.

IPE may not be on that list. Doesn't look like anyone ever added scripting support for creating that node. If you want to script it, you may be able to work with having a template VI that has nothing on it except an IPE and use copy/paste to copy it to your target diagram. I'll file the CAR to add IPE creation support. As a workaround, use this:

There are VIs in vi.lib\utility\editlvlibs\lvclass to allow you to inspect the mutation history information.

Both Daklu and Black Pearl have some gist of it. But it isn't perhaps about eliminating one or the other. If I take Black Pearl's analogy and extend it, having a bathroom separate from a kitchen is healthy, and having one room that tried to support both activities would end up serving neither goal well. But notice that both the bathroom and the kitchen have lights. They both have running water. Air conditioning and heating ducts. Walls. Electrical sockets. Doors. Indeed, there's a whole set of "room" attributes that both things have. Bringing this analogy back to LabVIEW... We have a "conpane" for subVIs but we have "tunnels" for structures. Do we need two separate concepts? Maybe yes, maybe no. Both have a description and tip. Are there other settings that apply equally well to both? Could a structure node be meaningfully marked as password-protected? How about marking a structure as "UI Thread"? The execution settings page of VI Properties is the most intriguing point of congruence between VI and structure. What about a subVI that is marked as "inline" -- can we just show its contents directly? Could a user looking at the caller VI be able to edit the inlined subVI right there without having to switch windows? How bad would that be? How common are subVIs small enough for that to be even slightly useful? What if I had a subVI that took a single scalar input and produced a single scalar output... could I have "autoindexing" on the subVI and just wire an array to the input and get an array out? How much commonality is there between marking a subVI as "reentrant" and marking a for loop as "parallel"? How far could we -- in theory -- go with unifying these two aspects of LabVIEW? These are two features that essentially developed in isolation from each other, and although I have no idea whether anything will come of it, it's been interesting to explore the design space around the commonalities. This is the part of my job they call "research". Just sitting around drawing pictures... :-)

"Looking up globals programmatically" is itself very high on my list of architectures that do not scale. I want to better understand the original problem was that made this feature desirable, because I cannot believe this is a good solution. At best, it is like treating heroin with methadone -- effective, but fraught with its own problems. So tell me... why do you need this? Can you go into details about some concrete project that drove you toward such a solution? If you can, I think posting that as a new topic on LAVA would be appropriate, and then I'd like to discuss the architecture in this public forum.

I just realized that people are looking at these VIs and planning to use them for something entirely different from what I had assumed. What I saw as a useful tool for good I realized could be turned to darkness in the wrong hands. If you haven't heard my position on by-reference data in LV before, it is this: References sometimes necessary -- rarely, and only in well-defined situations with extreme limitations on their use. I do not claim that references are always bad; I do claim that they are overused by today's LV programmers and generally references create many more problems than they solve. And, no, I don't think users are stupid. I think most references are dangerous in the most experienced hands, mine included. Now back to the topic at hand.... As I said, I have built for my personal use VIs that are fairly similar to these. And mine have a string input for "queue name", just like these do. But when I use my VIs, the name is ALWAYS wired with a constant. ALWAYS. They're full reentrant and store the underlying refnum. If I ever released the VIs, I'd probably add an assert that the name passed on each successive call was exactly the same name as the previous call and return an error if that wasn't true. In fact, if I ever got ambitious enough, I'd probably make "name" something to configure on the node, not an input. I never really considered that someone would look at these as an API for creating a misbegotten by-reference lookup-table. I always forget that various people keep trying to strip LabVIEW of its major assets by turning it into a mush of procedural, by-reference code. Wired with a constant, VIs like this can become a great addition to LabVIEW. Debug tools can be built to track the start and end points of these "off diagram wires". And there a number of code correctness proofs you can apply. Wired with a non-constant, they introduce code maintenance problems that are very hard to debug. I know I'm not a full-time G programmer. I do theory more than practice when it comes to G. Those of you who actually have to produce working G code for your jobs are right to be suspicious of my opinions on topics like this. Most of the time, when someone who works G full time tells me they really need XYZ, I pay attention and try to see how LV could provide for that need. But when I read things like this idea -- Globals that can be created during run-time and accessed by name (i.e. native Current-Value-Table/VIRegisters) -- I just can't in good conscience help. That sort of architecture just should not be necessary. It might work. It might even work well sometimes. But my theory is that it will never work as well as building software that solves the problem in a more dataflow-like manner, and when it doesn't work, it will be much harder to figure out why than the comparable dataflow architecture. I really wish that all the time poured into tools to support references over the years could be poured into really nailing down dataflow-like architectures that scale. I know they exist.

Yes, you're right... for now. Does it tell you anything about some of the design proposals I've been working on lately that I've kind of stopped differentiating "structure node" and "VI"?

Look, if it's going to be weird, shouldn't it say this around under the armpits? Or over the shoulder?

If you've got some down time, there's a science project that needs community help. It's called IceHunters... I helped with the beta of this site, and it is ready for prime time now. http://www.icehunters.org/hunt.php IceHunters is part of the Galaxy Zoo project, taking massive quantities of astronomy data and crowd sourcing it to find interesting tidbits. This particular branch of the zoo is looking for Kupier Belt Objects (aka KBOs), which orbit out around Neptune and Pluto, trying to find one that can be the target for the New Horizons space craft in 2015. A side-effect of this survey is finding asteroids and variable stars. Basically, you create an account and start looking at images, and then you circle the white blobs. Not the black blobs. Not the white blobs with black centers. Just the white blobs. And if you think that sounds like an easy task, wait until you see the noise in the images. See, they're not real images. They're composites designed to highlight the KBOs. But there's lots of room for interpretation, which is why this has to be a human instead of computer task. Every image gets seen by at minimum 15 people, so don't worry if you get it wrong... that's the beauty of crowd sourcing... collectively, we tend to get it right. Here's the tutorial for all the juicy details. If you get bored with IceHunters, there are many other branches to the Galaxy Zoo, including supernova hunting and galaxy classification. Vaguely mechanical, almost zen-like, it can be a calming way to pass the time, and it helps science figure out what our solar system is made of.

In 2008, Austin hosted the World WiFi conference, and as a consequence, our WiFi downtown was upgraded to the at-the-time state-of-the-art. It's kept pace since then.

Sorry... no ideas come to mind.

<snip> I've built a similar library for myself over the years. Never released it or anything. I'm not sure I agree with your decision to put a verison in the palettes that doesn't have the error terminals. For one thing, even the Obtain could fail on a low memory system. For another, asynch behavior like queue writing often requires serialization with other operations. I'm one of those people who frowns on local variables not having error terminals, for similar reasons. If you always had the error terminals available, then you could allow the name to be the only identifier and successfully return the queue error when the types and names mismatch, thus allowing the polymorphism. For my money, the ease-of-wiring of the nodes trumps the compile-time-type-checking, which is a very odd thing for me to say considering my position on other similar LV features. I'm not sure what makes this one feel different, but, well, for some reason it does.

You should post these questions on a forum where more Web UI Builder users and developers hang out: http://forums.ni.com/t5/LabVIEW-Web-UI-Builder/bd-p/480 I strongly suspect you'll get faster, better answers there.

It is possible to get a problem with this node if you, for example, flatten a very large integer then pass that string to unflatten and claim that the data that was flattened was an array. LV will read the first 4 bytes as the size of the array and will try to allocate that large an array. I've run into situations where that leads to LV running out of memory and crashing my system. I do not think that applies in this case, but I offer it as something to check for when investigating this CAR.

Yes, use the Variants.

I was just about to post a link to HGF. Holger beat me to it. :-) The other alternate architecture to look into is the NI Week 2010 Actor Framework: http://forums.ni.com/t5/LabVIEW/Actor-Framework-from-NI-Week-2010-presentation/td-p/1211309 SHORT STORY: A) Use of by-value classes does not mean you never use references. It means you think before you use references. B) You should avoid the trap of thinking of an object as a living process. That thought model works in C# and JAVA. Instead, think of a top-level VI as a living process and model communications among those running VIs. The state of each VI is an object. The messages passed among the VIs are objects. If you can hold that separation in your mind, whatever design you choose will be much much much stronger.

Yes, that should work.

Since "extern C" means to export a C style function, it doesn't make any sense to apply that to a function that has any parameters that are class data type. My understanding is that you can only apply "extern C" to functions that have only POD parameters. [POD = plain old data, yes, that's the actual technical term] Since all non-static member functions of a class have a "this" parameter that is of class type, that means that none of these functions can be made "extern C". The workaround that I know about is this... If you start with this: class X { public: int DoSomething();}; then you can do this: extern C int DoSomethingOnX(void *xPtr) { X *x = (X)xPtr; return x-&gt;DoSomething();}

I don't know what to do about the first one, but the second one I do know about. You loaded a VI dynamically and tried to Run it, but the VI is broken. That's pretty much the sum total of the problem. What more information would you want to see?

Which version are you running? LabVIEW has had the ability to diff (compare) two VIs since LV 5.0. LV gained the ability to do the graphical merge of two VIs in LV 2009. These features are under the Tools menu, and if you've enabled source code control integration, it's pretty easy to diff and merge your local version with the version in your SCC repository. You can also use LVCompare, which someone else mentioned, which is a small stub program that you plug into your SCC application and tell it to use as the diff/merge tool for files with .vi, .vit, .ctl and .ctt file extensions. That small stub launches LV and does the graphical diff/merge when requested by your SCC app.I've glossed over a lot of the details... lots more info exists in LV's online help and in various web sites both within LAVA and on ni.com.