Aristos Queue

QUOTE (JFM @ Apr 20 2009, 02:05 PM)

You should probably initialize the "EXIT?" boolean to FALSE before you enter the loops.

I concur. That's probably the problem.

QUOTE (normandinf @ Apr 14 2009, 05:47 PM)

And you're right, from a comment written by AQ some months ago, we should expect the classes and XControls to converge in the future.

The long future, not the short future. Short = 2 years.

QUOTE (Paul_at_Lowell @ Apr 13 2009, 05:55 PM)

Creating a cluster manually (by which I mean the cluster definition is determined before compiling), of course, possible, but I think it kind of defeats the purpose and it will be quite difficult to set up the hierarchy correctly.

It doesn't defeat the purpose. The XML form of an object is meant for preserving the object as the object. If you want to change it to a different object -- and that includes changing to a different object in a different language -- you would go through some sort of stabilized, exported interface, such as creating a non-object structure (aka cluster) and serializing the information. That's pretty much standard procedure for any sort of export/import operation. That leaves you free to still change the private details of your object -- add fields, remove fields, etc -- without changing your import/export format and thereby creating incompatibilities with the importing system.

The LabVIEW queues are circular buffers. You enqueue data at one end, dequeue from the other. All the mechanics of circular buffering are handled for you. You can bound the queue to a particular size or have it grow if it exceeds the current buffer size. See the online help for the Obtain Queue function to get started.

This works for in-memory buffering. If you really need to go to disk, you'll need to do something like the examples you posted. Why isn't something "out of the box" supplied? Because generally the in-memory solution works, and when it doesn't, almost always some custom solution is required to manage the data because of the size and scale -- there's usually some custom requirement about how the buffering works, when is it acceptable to toss data and when is it required to hold, what kind of compression can be applied, etc.

QUOTE (JustinReina @ Apr 8 2009, 12:29 PM)

I will be attending the Seattle event. What topics are going to be covered in the 'architectures' lecture?

Hypocrisy, guilt and tedium, and tools that NI provides for reducing all three of these. Specifically, we will be discussing practices that all of us software engineers should (generally) be doing on every project (to varying degrees depending upon business need and risk profile), including architecture planning, documentation and testing. We will discuss the lip service we all (myself included) are tempted to pay to these practices, the guilt that we can feel at knowing we're not doing them right and admitting to ourselves that a large part of why they're not done is that they are mind-numbing and tedious. And, so that we don't all leave feeling depressed, we're going to talk about a number of NI and third-party tools that can be used to decrease the pain involved so that these tasks (necessary and ultimately beneficial to ourselves, not just other programmers on our teams) can become part of our regular workflow and let us get back to the sexy part of our jobs -- connecting generally rectangular graphics together with pretty vertical and horizontal lines... man, that sounds so much cooler when Marketing says it... something about "designing algorithms that support business, science and engineering and change the world." Yeah, that's what I meant. ;-)

Jdunham and bsvingen: Is there a difference -- in your opinion -- between unrevealed features in the editor, unrevealed features in the runtime engine and unrevealed libraries of VIs? Because your arguments (and I'm still contemplating their validity) only have applicability to unrevealed features in the runtime engine itself, and there are damn few of those (I am not sure I can think of any to be honest, but I'll keep trying to think of them). In other words, that which you use, you use, and is documented, and your final application has no reliance on unrevealed things. Does that lessen your objections?

"I only want to see the important parts, but it keeps showing me every play-by-play. I thought this was supposed to be execution highlights."

Join the beta program. Or wait for the next release... ;-)

QUOTE

(I know about the ini file option to make all new inputs required, but that seems like the nuclear option)

And yet, it is the option I and a whole lot of people use. C++ has burned too many of us too often with optional parameters, so I've always been reluctant to use optionals in LabVIEW (by which I include both Recommended and Optional since neither requires the terminal be wired). After a bad experience with someone changing the default value of an unrequired terminal a couple years ago, I decided I wanted this option. I polled a lot of other folks and found huge support for it. And when I needed a training feature for some new members of the R&D team, I used the opportunity. Note: it makes all new terminals required inputs except for the error code cluster.

Paul:

I suspect you will -- believe it or not -- NOT want to use the Flatten to XML primitive for the LV Objects directly. Rather, I suspect you want to add a member VI to the class that outputs a custom XML format of the data within the class. Why? Because you're using it to move from one platform to another. The XML format of objects is designed to be mutation and version aware in LabVIEW. There are many shortcuts that the format takes that are not comprehensible without the .lvclass file. For example, if the output XML is just the class name followed by a version number of 0.0.0.0, that means unflatten this as the default value of the class. But without the .lvclass file, how can you know the default value at all?

Any time you're going to be leaving LabVIEW, the standard format of XML for objects is not going to be useful. Instead, build a cluster of the data that you want in the XML and then flatten that cluster as XML. That will give you a format that is completely LV independent to read in your JAVA code.

-- AQ

None of the XControls events will fire unless the FP is loaded into memory. If this is a subVI, it won't be normally -- but if you use any local variables in your diagram (for the XControl or for anything else), that will cause the FP to load into memory. Once the FP is in memory, then writing the value -- using the terminal or the Value property -- will fire the update functions of the XControl.

Austin apparently has a radio station KOOP.

I can't believe LabVOOP has never been asked to present. I mean, what else could they possibly talk about with those call letters? Stroustrop and C++ are all the way down in College Station, TX!

The NI Developer Days 2009 conferences are going on in various places around the country. This is one of the few events each year where R&D folks from NI get a chance to meet customers other than NI Week. I will be traveling next week to the Portlant, OR, event on Tuesday and the Seattle, WA, event on Thursday. You can still sign up to attend the events if you are interested:

http://www.ni.com/devday/

DevDays are targeted to customers who are know LabVIEW and are interested in stretching their skills a bit. Each one has a slightly different series of presentations depending upon the interests of customers in the area and the areas of expertise for the R&D staff attending the event. For Portland and Seattle, I've circled the presentations I'll be giving:

QUOTE (Yair @ Mar 24 2009, 12:55 PM)

Yeah, but most 16 year olds are still in high school.

I'm just wondering about his involvement. We work with a local school where we do let some of the high schoolers use proper LabVIEW (as opposed to Mindstorms which the younger kids use), but I don't think any of them is really interested in it.

By high school, I was programming around 2 to 3 hours every day on my own, and let me tell you, if I'd had a copy of LV, it probably would've been dissected like just about every other piece of software that passed through my hands in those days. And I could point to a number of my friends who would've been right there with me. I find it totally plausible that flarn is 16, which is why as much as I'm willing to answer his questions, I'm also raising questions for him about the whys and wherefores of doing it -- there's a lot more illegal aspects to reverse engineering these days than there were 15 years ago.

QUOTE (BobHamburger @ Apr 5 2009, 07:12 PM)

can you write LabVIEW in LabVIEW? Well, if you include scripting and other related features in all their gory, er, I mean, glory, then the answer is yes. If you exclude them, the answer is no.

If you exclude them, the answer is still yes. It's just not as easy. But it can be done.

Yes, but you have to have the Professional Edition of LabVIEW. If you have it, look in the online help for Application Builder.

QUOTE (flarn2006 @ Apr 4 2009, 03:56 PM)

I just believe that software should never have features not revealed to the end users, with the prominent exception of easter eggs. If a file format has a certain feature, the program should allow anyone to use it, not just the developers.

Ok... this should be fun. I'm going to spawn a new thread to respond to this challenge so that this thread can return to a discussion of typedefs, if there's anything further to discuss.

The new thread is here:

http://forums.lavag.org/Secret-features-et...hem-t13742.html

QUOTE (flarn2006 @ Apr 4 2009, 03:56 PM)

I just believe that software should never have features not revealed to the end users, with the prominent exception of easter eggs. If a file format has a certain feature, the program should allow anyone to use it, not just the developers.

I accept your challenge. I believe that unrevealed features serve more benefit to users than harm, and I suggest that software that does not have such features is likely not innovating sufficiently.

First, let us differentiate "unrevealed features" from both "undocumented features" and "undocumented behavior". Undocumented features are publicly exposed features, such as items in the palettes or menu items, that are undocumented. I am not defending developers who fail to communicate with their tech writers or publishing errors that result in documentation being dropped. It is poor practice to leave the feature hanging out there with no reference for the user who might invoke it. Similarly, undocumented behavior is behavior of public features in edge and corner cases for which no help is available. Common instances of undocumented behavior include the value of the output if the function returns an error, or the behavior of a menu item when the application is in a non-standard mode, or differences in behavior on non-dominant operating systems. These are hard to track sometimes, but nonetheless, they should be documented.

No, when I speak of unrevealed features, I mean things that you need either a special config token or a special license key to access, features that require an input file that can only be generated by hand-editing the file, or features that require a long series of keystrokes to activate (Up, Up, Down, Down, Left, Right, Left, Right, B, A, Select, Start). Some of these features are what we call "easter eggs" -- little surprises that have no effect on how you use the software but are fun to discover, such as "SuperFunkyPrivateSpecialSecretForumStuff=true" in LV 8.5 only. Those are fun, but are not true unrevealed features. No, what I'm talking about is truly useful functionality of software. In LabVIEW, the first item that everyone will list is VI scripting, the ability to make calls into the LV editor that let you make programmatic modifications to a VI. But there are smaller features: custom wires for classes that go way beyond what the dialog will let you edit; plug-ins to the Project Window; password access to certain block diagrams. These are the sorts of features that I am suggesting it is right, well and good* for software to include.

I believe, first of all, that unrevealed features can add to the usability and stability of software. To say that I have made a feature unusable by users for the sake of making the software more usable is not a contradiction of terms. There are plenty of tricks, backdoors, hacks, etc, that can cause myriad problems. For example, LV has an event structure. With this structure, you can catch events fired by the UI. There are private events that are not listed in the structure's configuration dialog. Why? Because some of those events look useful, but if you don't use them right (put too long a process in those event handlers, or use them in parallel with some specific other process), you end up hanging all of LV and having to kill it and restart. Should a regular user see such events listed in the config dialog? I argue no. They are system specific events that are only needed in the most rare of occassions. By exposing them privately, LV is able to write more of its functionality in G code, which means that higher level functions can be easily exposed as subVIs for users' general consumption. If customers are having problems and come to us absolutely unable to solve a problem without a particular event, we may give that particular customer a customized handler for that event. But there is no point to having regular users think they are using something useful, having it hang on them, and then having them believe that LV is somehow inherently unstable. Even burying such things in an "Advanced" pull-right is no help. 19 years of programming has taught me that users will open every menu, will click on every button, and then blame the developer when things go awry. Telling a user "Sorry, you're not advanced" seems to just upset them. It is far better for the collective user experience to to have those users that actually are advanced go hacking through files, trolling through forums, and wheedling insiders for secrets than to put generally useless junk in the interface, even if that junk is extremely useful in the .01% of cases.

Unrevealed features also foster innovation. When a feature is not complete, should LV not ship it until it is finished? Or is it better to ship it behind a config token and then call a few key users up and say, "We think this works, would you give it a try and let us know?" We've gotten a lot of feedback over the years by doing this. Some of you who are alliance members or LV Champions may be reading this and thinking, "What? I've never been asked to test secret features, and that's part of my role as alliance/champion!" Don't get mad -- most of the time it is an individual developer who drops such half-finished features in so they can be used completely within National Instruments. You're not being left out of any secret beta. And, to be perfectly honest, most of the time you guys find such features anyway. It is a hard balance to strike -- users want stable versions of LabVIEW, but they also want development of new features, and they want some way of knowing which features are safe and which are not. On the flip side, NI doesn't want to be maintaining multiple versions of LV simultaneously if we can possibly avoid it -- that's very expensive. So for certain features, this "hide it and take the feedback of those who find it" approach is extremely valuable. If you had to enter a config token by hand, or if a certain node only worked when you dropped it at least 16,000 pixels away from the origin, or if you had to adjust your contrast way way down to even see something in the palettes**, you can be pretty sure that it is not considered to be on the "safe and trusted" feature list.

Finally, unreavealed features show good use of developer time. There are certain operations in LabVIEW that you can trigger from the menus that are complex sequences of operations, and there may not be any way to trigger one of those substeps by itself, or to stop the process midway through. If we took the time to put a nice clean UI on every bit of LV functionality, we'd never ship anything. The rendering system of LabVIEW may use the OpenGL library under the hood, but that doesn't mean we take the time to wrap every OpenGL feature and expose it as a LV VI. The LV Project may be able to register with the OS to get updates when a file changes on disk, but that doesn't mean we take the time to provide a way for a user to register interest in files of theirs. It might be done eventually, or maybe not. Developers spend time on the features they think will be most valuable to users, and along the way they may include any number of smaller features that users have no access to. They may put all sorts of notes in the save format of files to support those features, bits that are not intended for users to twiddle. Providing twiddling access means supporting error conditions, means documentation, means tech support, means time lost to other projects. Sometimes it is better to just leave the feature hidden.

In summary, I believe that unrevealed features support the values of usability, stability, innovation and accelerated development of more valuable features. I would be very interested to hear flarn2006's position on why such features are some combination of wrong, bad or evil*, and what value propistion he/she feels is gained by deliberately minimizing the existence of such features.

* Right/Wrong: is this thing acceptable by some observer's subjective standard; well/bad: is this thing acceptable by its own internal standards; good/evil: is this thing acceptable by some objective standard agreed to by the debating parties.

** To the best of my knowledge, there are no easter eggs hidden at 16000 pixels from the origin or in nearly the same color as the palette background. These are just ways I've thought of over the years to hide easter eggs.

QUOTE (shoneill @ Apr 4 2009, 01:32 PM)

That's cool, any other hard-wired Typedef names out there?

To the best of my knowledge, no.

Here you go: Functional Global

When in doubt, check the wiki... it's probably in there. :-)

A) No, the wire pattern is not stored with the typedef.

B) It is hardcoded into LV that if a typedef has a particular name "Matrix.ctl" then draw an alternate pattern for the wire. I'm pretty sure you can do it by naming any typedef "Matrix.ctl"

C) There is no feature in LV for establishing a custom wire pattern for control VIs, so don't bother hunting for it. If you want custom wire patterns, LV classes are your answer.

This suggestion has been explicitly rejected by LV R&D multiple times over the years because it would contribute to the ease-of-use of stacked sequence structures, thereby encouraging their use.

QUOTE

You're absolutely right.

But the very reason a stacked sequence exists is because a flat one sometimes takes too much space, and then a shift register would come in handy.

No -- the reason stacked sequence structures exist is that we didn't have flat sequence structures at the dawn of LV and taking them away now would upset people.

QUOTE (shoneill @ Apr 1 2009, 08:33 AM)

Can you reply again to this message tomorrow with the same content so that we know it isn't an april fool wind-up?

It would not be unreasonable to assume that we might be working on something like that.

QUOTE (Aristos Queue @ Mar 29 2009, 04:42 PM)

You might be surprised at the easter eggs you discover somewhere around the 9,876th click (in a single session of LabVIEW).

I would just like to say at this point that I could not resist the temptation to set this up as an April Fool's joke. My apologies to those who spent an evening right-clicking. Since the original poster had a hex editor, I just assumed he'd set the count to 9875 and see what happens.

For the record, I don't know why LV would be counting mouse clicks, but my guess is that it is a common strategy for marking objects that have been visited -- instead of using a flag that you have to clear after every traversal, use an integer and just increment it when you visit for a given traversal, so you can tell whether you've visited on this traversal or not. Just a guess.

QUOTE (Vladimir Drzik @ Apr 1 2009, 12:53 AM)

Yair, are you serious that you can open older versions of LVOOP objects? Never heard about that... How does the conversion work? Is there any document that describes the mechanism?

Lots of documentation... it's one of our "six major reasons why you should use LV classes" that I presented at NI Week 2008. I linked to a bunch of stuff in http://forums.lavag.org/LabVIEW-Class-Data-Preservation-Details-t11259.html' target="_blank">this forum post.

It would be reasonable to assume that LV R&D might be working on something like that.