Aristos Queue

I have often thought how useful it would be to have a text save format for LabVIEW VIs. But then I read this and I think maybe it is better that we don't have it. Why? Because someone will create a preprocessor. And then this... http://www.dadhacker.com/blog/?p=1274 Let me just state now, for the record, in some future LabVIEW where such features exist, if you ask me to look at your VI, and I open that VI and find the entire block diagram written in Fortran, and you failed to adequately warn me ahead of time, I cannot be held responsible for any retributive actions I may take during my psychotic breakdown. I used that language professionally years ago... please don't dredge up those nightmares.

It's more like a parent calling the kid on low grades when you know the kid can do better. ;-) (The irony in this case is that the kid can only do better if the parents did better, spent more time, etc., so it's really me critiquing myself and my team.)

Just let the process that uses it use it would be my normal go to in this case. The only reason I would consider a different route is if I had reason to obscure where the settings were coming from -- i.e., sometimes they come from a config file, sometimes they come from an object simulating a text file. Testing is sometimes easier if you can feed in objects that represent specific configurations, rather than having the config files for various tests.

This was a post-signature, but I moved it up to the top because I felt my tone could be taken as dismissing your idea out of hand when, really, I was just trying to do a brain dump of the analysis I had already done on it years ago. If you think there's some direction to go with this, I'm definitely open to making the overall system for defining classes be more graphical, but using a VI to do it doesn't seem like the right way to go. (PS: I'm not just rejecting your idea on the fly... it's one of the diagrams I had drawn up in brainstorming while working on classes 8 years ago. I worked on it because something like that *is* how poly VIs are defined -- they have a block diagram, and floating on that block diagram are nodes of all the instance VIs. The actual block diagram is hidden behind the dialog because it turned out that you needed more control than just "this is the set of instance VIs". Tried something similar with LV classes at one point. Really, it is the same as what you're asking for except that we put a different interface on the definition and changed the save format to be human readable instead of XML.) You're confusing syntax with semantics. There's no C syntax for declaring a class -- C++ had to introduce new syntax. Likewise, there's no nodes you could drop on a diagram to define a class. We were going to have to put a new file framework together. We chose to save it as XML instead of binary, but we could have used binary, like VIs do. A VI is a function. A class is a set of functions. A higher order construct -- like the higher order keywords in C++ -- had to be introduced. We do use the syntax of the existing language for defining the data contents and the methods of the class. The class file is nothing more than the braces around the methods in C++. BUT, your point is that we could have introduced a new type of VI to do that, right? Let's consider where that rabbit hole leads... Problem is, that's a valid VI, not a class. And, really, it is *exactly* equivalent to the private data control VI that you do create -- only in yours, you have that extra useless front panel. You brag about not having a conpane, but you generate a whole extra window! :-) Which is actually where I was at one point, until I picked the whole thing up and moved it to the panel and eliminated the block diagram -- thus the private data control. Next, a block diagram isn't declarative -- it is execution semantics. In your later images, you are littering your diagrams with executable code as a way of declaring types. Although useful for on the fly type instantiation (a feature that would well be worth having in some really advanced use cases, and something we've discussed in R&D), it is wholly useless for defining a static type definition... you don't know when to execute these diagrams. See, the types have to exist *before the program is even loaded* because LabVIEW has data values for controls *immediately*. The dependency ordering is invisible. An execution syntax really isn't appropriate for a declarative semantics. Finally, there's no way to distinguish these diagrams from regular diagrams, where a programmer might have mixed in any number of runtime behaviors. Those declarations of functions that you've written? They look to me like function calls. What stops you from forking that LV class wire? why do you even have to wire the LV class wire? It's a sloppy syntax -- some methods do not have a class in. Some do not have a class out. Some do not have either. Some are global VIs and some are control VIs. SO... rather than wiring them together, take away the requirement to actually wire those nodes together -- you end up with a bunch of floating VI declarations and a cluster constant. Now, arrange them in a column. Now turn on labels. Now hide icons. You know what you get? The project tree. Yep. Exactly. You are asking for New >> Class VI. That ends up being pretty much the equivalent of New >> Class as it stands today. The project tree offers a more compact layout than a diagram and allows for folder organization. It also allows for New >> VI From Template so that new VIs are created already knowing what class they'll be a member of and thus can populate their controls/indicators. With a plain Class VI, you'd still be introducing some sort of gesture exactly equivalent to the project gesture for creating a new member VI. In the end, the question of what is "syntax" in a graphical language turns out to be rather more amorphous than most are comfortable with -- the final save format of the files is nearly irrelevant, which is the entirety of syntax for text programming languages. And, honestly, I think the project tree would be a better environment for defining PolyVIs if we were creating them from scratch today. So, for me, the lesson ends up going the other way. :-)

External DVRs are a behind-the-scenes thing we create when LV IDE talks to a LV-built DLL that uses DVRs and things like that.

Published in January 2013, this is the official directive on closing references: when you need to and when you don't. http://www.ni.com/white-paper/14393/en In your picture, the code shown is fine. Moving the Open and Close inside the loop would just create a performance burden. Moving only the Close inside would cause run time errors since the reference would be closed on the second iteration.

Don't kid yourself. Those are different OSes. ;-) But, yeah... the diagram follows the OS theme, and when it changes, argh.

If it helps, I do about half of my LV work over a VPN connection, working on my laptop but saving on my work machine. I prefer to work locally on my Mac, but because of the font size differences between Mac and Windows, once I'm going to start publishing something, it's better to maintain the code on Windows. (Dumbest part of LV in my opinion -- the lack of a standard, across-all-platforms font for use in all property nodes, diagram constants, comments, etc.) Anyway, over the VPN connection, LV is sluggish at times, but the only place where it burns me is when I'm wiring a node -- have to have a half-a-heartbeat pause between placing the mouse over a terminal and clicking otherwise it may pick up another terminal that I passed over. Other than that, the twitchy pauses don't cause me difficulties. I am not saying it's great, but I do feel it is totally workable if you find yourself needing to do that. Working on your local machine is nicer.

You can optionally add it through the VI Properties, like in documentation, but there's nothing saved by default.

What is a DVR object? What is a normal object? These are not terms I understand. There are objects -- they are the values of a data type that happens to get the name "class", no different than values of a integer or a string or a path or a waveform or a timestamp. There are DVRs which create a reference to data -- any data, including objects, integers, waveforms or timestamps. Objects don't becomes some other type of thing merely by being held in a DVR, any more than they become a different type of thing when held in a Global VI or a queue or any other data storage. There are a number of ways of packaging the DVR inside or outside the class, and it sounds like you're interested in the outside-the-class version. I *think* you are asking, "In this model, what prohibits someone from opening up the DVR and copying the object to some other location?" Answer? Nothing. It's a by-value object and it can be copied freely. There's nothing the copier can do with the object other than call the methods on the class, so unless you've stashed more references inside the object, there's no worries. If you've stashed more references inside the object and you're worried about structured access to them, then you probably need to look at an inside-the-class model for by reference.

monzue: yes, it seems easier. Yes, the code can be lighter. It is one of the best ways to introduce race conditions into your actor interactions.

mzu: There's a behind-the-scenes feature that I added a long while back for vugie that might help you here, if you don't mind turning on execution highlighting on the caller. http://lavag.org/topic/9281-new-config-tokens-in-8-6-to-help-you-tap-into-exec-hilighting/ You could use the info about where exec highlighting has gotten to identify which nodes have already executed. Not what you're looking for, but perhaps useful? You could also add a custom probe on caller diagrams for any diagram that has multiple calls to the same subVI. The custom probe could announce that it has executed. For non-reentrant subVIs, this would let you distinguish which one was executing unless they both tried to run at the exact same time (both probes would trip but you wouldn't know which one won the race for the mutex). For reentrant VIs, that wouldn't help because they could both go ahead and execute. [unless I'm wrong about the reference from a subVI node for reentrant VIs in previous paragraph, in which case the probes would solve the non-reentrant case and the reference comparison would solve the reentrant case.] Just because you have different numbers, they all refer to the same VI. The different numbers are just independent references to the same object, no different than opening multiple references to the same named queue. I think you'll even get the same VI from a node for reentrant subVIs -- they'll all refer to the real VI from which the clones are made -- but you'll have to check my memory on that. I can't think of anything that will give you that information.

Ton: No, you don't need to load the VIs... there are methods on App references to get info about VIs without loading them. Take a look at the invoke node. And I am using an OO approach ... each of those VIs maps to a class, and the class maps back to the VI, but the VI is not a member of the class. This is giving me some interesting freedoms for componentization. Not an option I would pick for most projects, but one I believe to be the right choice in this case. If it all works out as planned, I'll have more to talk about.

mje: Since this is a scripting tool, the menu items are functional choices, so I think this meets even your objection... the VI Description is the description of what it does.

The tl;dr is the two lines in bold face. I'm building a plug-in system. This is a project on my own, not a work assignment, although I will admit that this is one of those side-projects for which I have greater plans, should it pan out. Plug-in authors write a single VI that goes in the plug-in directory. When the application runs, these VIs are scanned to provide the functionality options. The user of the application will be presented with a selection list to choose the operation he/she wants. That list is a list of all the plug-ins. I don't want to just show a list of VI names, primarily because I may be localizing these VIs for different human languages. I also want to be able to have a context-help-like system for each menu entry so users know what they are picking. Here's my question: If each plug-in is defined by a top-level VI, is it good practice to use the VI Title and the VI Description as the place for the plug-in author to define the menu text and the help text? I'm never going to show the front panels of these VIs, so I don't have to worry about a VI having a title that only makes sense in the context of a menu or something like that. These VIs won't be in anyone's palettes nor appearing on block diagrams, so the usual venues for the VI Description do not get used. So it is totally *technically* feasible to reuse these fields. The idea appeals to me most especially because the Title and Description are fields of a VI that are exported by Export Strings, making them easy to localize. If I use something like VI Tags, I have to build a custom localization tool. If I put controls on the panel, those become part of the compiled code of the VIs. Both the tags and the controls require a lot more VI Server code to extract the text from the VIs, and require plug-in authors to follow some sort of naming convention for the tag or control. I think I can even get the title/descriptions without actually loading the VIs (haven't checked on that). The only other option I can think of is that the plug-in actually is a text file of some sort that lists the VI and the menu text and the menu description. Again, requires a custom localization procedure. I have a general phobia of custom text files... they tend to become crufty as new features get requested over time. I've built many of them in my personal code, but the only one that I've inflicted on users in my professional career at NI is the *-errors.txt files for defining error codes. That one is full of rookie mistakes in file design, but even if those were cleaned up, it wouldn't have helped the file's development over time. Over the last 13 years, we've started hiding several new things in parts of those files that previously were comment blocks. But, hey, it worked for HTML, so it must be a good idea, right? Right. But that's what happens with custom text formats. (This ties in to another "is it a hack?" question: "Should you always include a gratuitous string field in any significant API in version 1 so you have a place in version 2 to stick all the fields you never thought of in version 1 without breaking backward compatibility?" But that's a question for another thread.) Using the Title and Description feels like a solution that is right, well, and good. If you know of any reasons to declare it wrong, bad, or evil, please share.

Ton: Today is Memorial Day in the USA ... most folks on vacation... Mike'll probably not see your post until tomorrow.

To the best of my knowledge, LV ownership rules follow the operating system in all instances. You'd have to check your OS vendor for the rules on reading when another process is writing. The "not seeing an update" is likely due to the other process not flushing its write buffer... just because you write to a file does not mean the file on disk actually gets updated. Most OSes will batch up writes to a file, especially if it sees them happening frequently to the same file, and only commit them when some in-memory buffer fills up or if the process explicitly calls some sort of flush command. LabVIEW includes the Flush File function in the palettes for forcing this.

I would ask your coworker why he/she thought that would impact anything. That person clearly knows more about the execution system than I do, since I would have stared at them like they were crazy for making that suggestion.

Code may well include proprietary information from the project he is working on. This is frequently the case with bug reports that NI receives.

Sorry to hear about the problems... glad you were able to find a workaround.

klessm1: Try this... WITHOUT loading the project file... Open just the database class. Does it open without loading the XControl or the Main GUI class? If so, good. If not, bad. If that is good, then try opening just the XControl. Does it load the database class but not the GUI class? If so, good. If not, bad. If both of those are good, then the issue you are experiencing is probably a different issue and you'll need to post to the ni.com forums for an AE to try to help you. If either of those doesn't work, you'll need to restructure your code until both of those are true. And the NI forums are back up now.

You're just printing out the extended ASCII characters.

Exactly which exception is thrown? What code actually throws the unhandled exception? Is it OpenCL kernel throwing the unhandled exception? I suspect it is not, otherwise you'd be able to catch it. There are two ways that the out-of-bounds-write exception could be generated: The exception could be thrown by the kernel code that is bounds checking every memory write *before* that write occurs The exception could be thrown by LabVIEW when it inspects the guard bytes around the allocation *after* that write occurs I suspect it is *LabVIEW* that is throwing the unhandled exception because LabVIEW is detecting the overwrite *after* the write has already occurred. Since the overwrite has already occurred, there's nothing to except shutdown -- memory is at that point known to be corrupted. Safe execution is not possible after that. It is common for kernels to not do bounds checking because it can be a severe performance hit. Basically, if this is what is happening, you're not going to be able to stop LV from shutting down because LV has already determined that it is not able to safely continue executing.

LabVIEW simply does not support working with any generic data type. See "Which .NET Features Are Not Supported In LabVIEW?" here: http://digital.ni.com/public.nsf/allkb/DC41DCDA972642CF8625787E00732DDD You will need to create a wrapper (in C# code) around some ICollection class of a concrete instantiation, compile that as an assembly, and then instantiate that in LabVIEW.