Aristos Queue

The Sequence Structure and Flat Sequence Structure should be placed in a restricted palette that can only be accessed with a security code that is given to you when you complete LV Intermediate. It would also automatically unlock after you have been using LV for one year. I'm joking, of course, but my point is that sequences are something that should never be used until you know enough to know when they should be used.

Can you please repost this topic over on ni.com here so that AEs can investigate it? If there is a bug that needs to be addressed, that's the best way to get it started.

QUOTE (pallen @ Aug 20 2008, 09:27 AM) There are features of 8.6 that do not exist in 8.5, and if you've used those features, the save for previous still works but the VIs are broken in 8.5, where you would need to fix them up somehow. But if you steer clear of those new features then in theory save for previous should work for you. Of course, Newton had a theory, and it worked in most cases, but it had to be patched by Einstein for certain conditions. Will your VIs be "special cases"? I appreciate the vote of confidence in LV R&D's programming abilities, but while your faith in our perfection is admirable, a pragmatist might suggest that loading those VIs in 8.5 -- just to check -- would be recommended. Also, you can't save for previous and then load the VIs in the runtime engine. Any VI that has been saved-for-previous must be loaded in the development system in order to be recompiled using the old compiler. So if your VIs are going to be deployed on systems with 8.5 development system, you're fine. But if you're planning to load them with the run-time engine, you'll need to pass them through the dev environment. * I believe I will begin using "special cases" as a euphamism for "bugs" :-)

The _goopsup.llb was removed as part of a sweep to get rid of CINs. There are now zero CINs that ship with LabVIEW. They still work in the code if you load them, but we do not ship any ourselves. They were a major support burden for cross-platform work.

You have filed a CAR, right?

Use the "To More Generic" node to hide these coercion dots.

QUOTE (jdunham @ Aug 19 2008, 08:10 PM) Ah, irony...Let me tell you a story... there once was a LV developer who had as his first assignment the task of creating the queue and the notifier primitives. And, at the same time, this developer created a palette of associative map primitives. Very fast, parallel safe, etc, modeled on the same API as the queues and notifiers. The queue and notifier primitives went into LV. The associative map primitives did not. Why? Because customer feedback said that while queues and notifiers are used for communication, and therefore are appropriate places for reference data types, an associative map should be a dataflow type. Who would want to use a map by reference? That was eight years ago. This developer went on to develop LV classes, propelled to some degree by wanting a structure in LV that could express the associative map that had been implemented all those years ago. And now, today, there are two very different map implementations: http://forums.lavag.org/Map-implemented-wi...r-85-t8914.html and http://www.ni.com/labs/ (search for "LabVIEW Generic Container Map")<h4></h4>

QUOTE (jbrohan @ Aug 18 2008, 08:16 PM) From Cairo, of course, where you stashed it after the last search you did for an elephant ended in dismal failure...If you don't get the joke, try reading this: http://en.wikipedia.org/wiki/Elephant_in_Cairo :-)

QUOTE (JiMM @ Aug 19 2008, 01:54 PM) It is valid at least back to LV5.0. I suspect it goes back to 2.5, but I've never tried using LV that far back.

Ah. Your reply makes things make sense. Thank you. QUOTE (hfettig @ Aug 19 2008, 06:30 PM) I was writing my reply when his was posted and I didn't see it until I sumitted. :-)

QUOTE (hfettig @ Aug 19 2008, 01:19 PM) No. *Classes* cannot be unloaded. *Objects* are freed up just fine.QUOTE Basically what I am wondering is the following: I have a class called DataFile. When I call Open an instance of the class is created, the data is loaded and parsed. Once I am done working with the class I call Close, which empties out the private data. However, as far as I know there is no way to destroy the actual instance, is there? I am just wondering that although I empty the private data, every time I open a new file the instance of the old one(s) is (are) still in memory, slowly increasing my memory footprint. The preceeding list of steps makes zero sense to me. Forgive me if the following questions sound dumb, but I'm really confused. Is "Open" a VI that you have written or are you meaning the Open Library Reference invoke node? Is "Close" a VI that you have written or are you talking about the Close Reference primitive? How the heck do you "empty out the private data"? Are you talking about just writing default values to the fields using a Bundle node? What do you mean by "destroy the actual instance"? My answer depends upon what you mean by "destroy". QUOTE I guess a way around that would be to instantiate the class outside the Open function and re-using the instance for each file. Huh? Are you using LV classes or one of the reference toolkits?

QUOTE (crelf @ Aug 5 2008, 11:05 PM) I don't think the Report Gen VIs will ever change their conpane to be by-value. That doesn't make any sense for this API -- files are a system resource that is better handled by reference than by value*. But the under-the-hood implementation may convert over to a lot more classes. Also, new VIs may very well have classes as part of their connector pane for parameters other than the report refnum. * "But, AQ, I thought you said never use references." No, although there were a couple folks at NI Week who thought I had said that. Let me be clear: I've never said that you should never use references (except for those people who are addicted to references and need to kick the habit). What I have said is that use cases for references are much much rarer than use cases for dataflow, and thus references were less of a priority when we were developing LV classes. My rough estimate, based on two years of observing LV applications from customers and NI developers, is that references are appropriate for about 5% of all class types; the rest of the time the by-value classes are preferred (higer efficiency, fewer race conditions).

You might be interested in the Wii library for LabVIEW that let's you interface your Wii controller to your laptop or other computer... some interesting apps are possible... http://forums.ni.com/ni/board/message?boar...ssage.id=249428

When the Mindstorms NXT came out, I started composing nursery rhymes for teaching LabVIEW to children. Somewhere there's a video from NI Week this year of "The Execution Hilite Went Down The Wire Route". But I've also contemplated more adult musical fare. And one of the most interesting possibilities (to me) would be G drinking songs for the LAVA BBQ. Just imagine: a mass of LAVA users singing the joys of dataflow over flowing beer. So, I'm offering one song here. Feel free to either add verses to this one or to post your own songs. What Do You Do With A Broken Wire? (to the tune of What Do You Do With A Drunken Sailor?) Chorus What do you do with a broken wire? What do you do with a broken wire? What do you do with a broken wire? __________to fix a broken VI? Verse 1 Change one of its ends to an indicator! Change one of its ends to an indicator! Change one of its ends to an indicator! __________that'll fix the VI! (back to chorus) Verse 2 Insert a node to convert the source type! Verse 3 Check all ends connect to terminals! Verse 4 Use control-B and just remove it! Final Verse (always the last verse even if more verses are added before) Do whatever the Error Window tells ya! Do whatever the Error Window tells ya! Do whatever the Error Window tells ya! __________that'll fix the VI! (Cheering and whooping)

QUOTE (Michael_Aivaliotis @ Aug 14 2008, 02:43 PM) Ironically, in this case "IE works fine" means that IE is still subject to the security exploit that both Firefox and Safari fixed. :-)

QUOTE (Gavin Burnell @ Aug 14 2008, 04:16 PM) Is there a CAR on that?

QUOTE (Pollux @ Aug 13 2008, 04:22 AM) It means that some part of your VI has a configuration that LV has no idea what to do with -- such as a bit setting that only has meaning for numerics being set on a string control. Search around on LAVA for "insane object" and somewhere you'll find a thread that talks about identifying the offending item and deleting it. Ultimately this is an NI error that should be CAR'd (by posting at NI.com) so it can be investigated and fixed.

The single best CD to code to, in my opinion: A Kind of Magic by Queen.

QUOTE (eaolson @ Aug 11 2008, 12:50 PM) This is exactly the differentiator. By convention, across every programming language I have ever worked in, it is always (x,y) and it is always (row, col) and these are backwards from each other. Arrays are row,col because of the tight association of arrays with matricies, but graphics APIs are x,y. Even more exciting -- monitors use x,y, but the origin is at the top left, whereas Cartesian coordinates have the origin at the bottom left. So the Y coordinate is inverted from the usual direction. This is also consistent across every language I've worked in, LV included.

QUOTE (neB @ Aug 11 2008, 12:44 PM) With "every possible add-on" affecting user.lib, this is indeed a reasonable time to load the palettes. I've been involved in timing the palette loading in past releases of LV and it is entirely possible to get those sorts of times. The "load palettes in the background" works, but it only loads palettes when it thinks you -- the user -- are not actively doing anything. So when you're writing VIs, there's usually a lot of downtime while you think of the next node to drop, and in each of those spaces LV will load one or two palettes. But if you want QD right off the bat, you do want to do "load at launch".

QUOTE (Antoine Châlons @ Aug 11 2008, 01:44 AM) We've talked about removing the "index" tab now that the search tab is more efficient. It's sort of the difference between Yahoo and Google -- a human generated index of keywords only works if your mind works the same as the particular human that generated the index. The search will find all the words used in the text. Now that we have a better "page rank" system for the results, the search tab should generally be more helpful than the index.

QUOTE (TobyD @ Aug 8 2008, 03:30 PM) And I would agree with you, if I were using a Windows trackpad. The Mac trackpad has many shortcuts, including "one finger points, but two fingers scroll", and "click with one finger is left click, click with two fingers touching is right click". There's a modifier key so that you can zoom any app (including LV). It makes programming LV on a laptop really nice.

QUOTE (neB @ Aug 8 2008, 09:34 AM) Nope. You can just type the names of items as they appear in the palette without providing your own shortcuts. So you can type "While" if you want the while loop.

In general, LV avoids type coercions. We do allow many numeric type coercions, but there's a lot of folks that wish we didn't do those automatically. In general, the more automatic type coercions that you allow, the more accidental miswirings are possible. Allowing enum wires to attach to string terminals would be a severe break with the strict type system of LabVIEW. Given a) how rare this behavior is desired and b) how easy it is (see previous comment from jdunham) to get the conversion when you want it, there's no way that we'd put such a conversion into LV. The coercion dots are a constant balance of ease of programming vs correctness of programming. I don't think this conversion is one that would serve that balance.

QUOTE (Darren @ Aug 7 2008, 12:27 AM) Which I will be doing for the Mac. See, on the Mac, the shortcut is cmd+shift+space because cmd+space is the shortcut for spotlight. But requiring a double modifier is a real pain for this accelerator. Why didn't we make it ctrl+space on the Mac? I know cmd is our normal modifier, but the ctrl key is available in this case and it seems like a more reasonable choice than adding the shift key.