Aristos Queue

I am STILL extremely concerned that 2009 required a "Service Pack". My multiple daily crashes only fuel my anxiety.

Every version of LabVIEW going back at least to 3.0 has had a bug fix release. There's nothing new about the 2009 one except that we called it a service pack. It's curious that you mention 8.6's stability. By the CAR count, 2009 was more stable than 8.6. But these sorts of things are subjective to the parts of LabVIEW that affect you daily, so different customers may have experiences that vary greatly from the objective count.

In case you haven't heard, LV 2011 is going to be largely a stability release. The entire LV team, acting on requests from customers, is going to pull back on features, focusing on bugs, performance and integration between existing features. There will be very little that is new in LV 2011, but we think customers will want it nonetheless.

Thanks, everyone.

Ok, this is cool. It's not exactly LV, but it is computer science, and since LabVIEW is dedicated to making CS more accessible to non-programmers, I decided this fits the Design & Architecture theme.

Background: There are different processes that can be used to sort data. Some LV users may just know the Sort 1D Array primitive, but under the hood, that primitive implements a particular sorting algorithm. Different sorting algorithms have different performance characteristics. Some algorithms are categorically worse than the others. Some are really efficient on different types of data -- some work well when the data is completely random, others when the data is already nearly sorted, some are very efficient when the data is too large to fit in memory and has to be occasionally loaded from disk.

Understanding what is actually going on with each algorithm is sometimes hard to grasp for students, especially if they're just reading source code. Someone has taken various sorting algorithms and set them to music and video. How? He sorts an array of randomized numbers, and every time two values are compared, he plays a tone of the frequency of the value. For some sorts, as the array gets closer to sorted, you can hear the sound becoming ever more like a single rising scale. For other sorts, it gets closer to silence since those sorts don't have to keep checking back to see if they have all the data sorted.

Here are the Youtube links:

Insert, bubble, selection, merge, and a gnome sort:

Heap sort:

The other issue I see is that LV doesn't support generics, so you will need to implement the linked list for every class and can't reuse it.

For a lot of the work that OO programmers coming from other languages want to use it for, they'll be able to make good distance with the version where the core type is LabVIEW Object and just downcast when they extract from the list. This applies to all the container types. JAVA didn't have any sort of generics for a long time, claiming that the common root object (java.lang.object) was sufficient and they wanted to avoid the complexity that C++ had developed that was (at the time) the source of most bugs in all C++ compilers.

it really makes me consider whether having interfaces is worthwhile! I'm probably just lazy though. Got any tips to make me a more efficient LVOOP coder?

Once you get the pattern down, spend some time writing an automation tool using LV scripting to take care of some of that work for you.

Hi, I'm fairly new. I used LV for a little bit of measuring but my next task is to do data handling and storing of huge datasets. So my idea is to use a double linked list to store and search in the datasets ( >1000 entries).

Just use an array. As Tim said, 1000 entries is trivial compared to what a lot of LV apps handle.

I strongly do not recommend that you do anything with references until you've been working in the language for a while. There's a reason they didn't exist in the language until LV 2009 -- you generally don't need them and you probably will get burned in some way since refnums and parallelism don't play so well together.

Thanks for the example, I found this implementation too but it is also confusing me. http://decibel.ni.co.../docs/DOC-12668 why is in this example the linked list build of two classes?

Because LV does not allow a class definition to refer to itself, even through a reference. A class can refer to its parent class in its own definition. So the linked list uses a node which has references of type "parent of node".

Linked lists have been a foreign concept in LabVIEW until rescently when objects were added to the language.

They're still a foreign concept. :-)

Hi,

I'm new to Labview and I need help by the implementation of an double linked list in Labview2009. I've found an example from NI but it's more confusing me. I want to design the double linked list with a LVclass as data member and the data should be an reference to one instance of this LVclass.

A) How new are you to LabVIEW? If you are fairly new, you may be surprised by the lack of a doubly linked list as a formal library in LV. That's because it is rarely needed or desirable, relative to other programming languages. There are often better ways of handling the situation in LV, which might be worth investigating.

B) Here's a full implementation of a singly linked list. http://decibel.ni.com/content/docs/DOC-12668 You should be able to adjust it to be doubly linked with little effort. This mechanism is *much* easier to grasp (and use) than the XControl impl. that you were looking at.

This is exactly the way I look at the situation, code generation is irrelevant to me.

However, I do wish I had the ability to reverse engineer my projects to generate up to date UML which reflects changes I made during design time which I did not account for when initially drawing out my UML.

The Symbio tool can do the reverse engineering.

So stability will improve in 2011 right? Any chances of getting improvements in the 2010 SP?

The SP is always a bug fix release, so I'm not sure what your question implies. We do shy away from significant refactoring projects in the SP because those do not go through the same deep beta process as a full release, but the major issues that we know about that have no workaround, we do address.

== Stephen

This actually is not my number one LabVIEW need, although it is high on my list. I am just not a fan of the "sort of" approach, especially when it comes to supporting standards.

The problem you'll find is that LV has a lot of coding concepts that standard UML does not cover. The Symbio tool is able to reflect features of LV that a generic UML diagram would leave out.

The attachments for this post appear to have gone missing. Where can I find VIpreVIEW these days?

Where did you see this statement?

It's in the Notes section of my PowerPoint presentation. NI as a whole talked about this in the Keynote presentation.

Redownloaded and got the same error. Copied the file over to my flash drive and it works. Weird.

Phew.

The attached ppt was corrupted in my download. Anyone else have this problem?

I just tried downloading it again and it worked fine. Try again... I posted an update this morning... maybe you happened to be downloading during the exact 3 seconds when I was uploading the new version and something got confused.

What's your actual goal? I mean, why do you need the names of the ancestor classes at runtime? What are you trying to achieve? I ask because the reflection stuff works in editor environments, but not runtime environments. We may be able to propose an alternate approach than getting the class name because i doubt you're going to find a satisfactory solution to that exact problem... and we haven't made the reflection API part of the runtime engine because a) it would add to the size of the runtime engine and believe it or not, there is some effort made to keep the thing from becoming ever larger and b) no use cases have ever arisen where someone would need that kind of info in a running application. But perhaps you can explain the use case that would compel this addition in a future version...

Definitely! Fingers crossed..

Post this to the Idea Exchange. I think it is worth tracking as an idea.

P.S. - I need to have a talk with the judges next year about literal interpretation of the rules, because Robert's answer for the 7-segment display was NOT a 7-segment display. Thankfully he messed it up just a little bit, which gave me enough time to finish my real 7-segment display while he tried to fix his...

Speaking as a judge, I did confer with the other judge on this one, and we decided that it visually looked like a 7 segment display and that was enough. Honestly, we never imagined Robert's solution when we were brainstorming how each of these problems would be solved (we have to verify that they're actually doable in a reasonable amount of time). Once we saw it, we felt it was a reasonable approach to the problem. Consider this... he made a 3x5 grid. Had he made a 9x15 grid, using the same basic idea, you would have seen bars of LEDs, clearly visible as segments. I don't think there'd be any argument then. If the idea is generally valid, then I think we give it to him for having the simplest form of that idea.

Erm...

"Regardless I'd like to move all discussions over to the community site so we have a single point for information."

There is a spoon, we're just hiding it while we figure out what the spoon will look like.

I hate to tell you this, but if you're creating a new copy of the conversation that will branch off the old one, that's called a "fork", not a "spoon".

:-)

The Actor Framework that I mentioned earlier is now available. Read about it here:

[This message was also posted here on the ni.com forums.]

All of the presentations for NI Week 2010 are available in the NIWeek 2010 Community. If you attended NI Week, you should already be a member of the community. If you did not attend NI Week, click on the link and request to join the community (you will have to create a user profile if you have never used the NI Community pages ever before). Approval to join the community may take a day or so.

Once you are a member of the community, you can go here to get a full copy of the "LabVIEW Classes: The State of the Art" presentation that Mike Benza and I gave, along with all the VIs used during that presentation.

I spent the bulk of that presentation discussing my new Actor Framework.Many users have spent time developing mechanisms for starting up multiple top-level VIs, establishing communications among those VIs and then tearing those VIs down when the app completes. It is easy to make a system that works sometimes. It is very hard to make one that always starts cleanly (so no VI misses early messages), avoids deadlocks during communication, and actually shuts down all running processes. Very hard. Multiple users have posted their attempts to me.

At the same time, I've been looking at state machines, that very common design pattern for LV programmers, and lamenting that if I build one state machine for a project and then I need that same machine but with just one more frame of the case structure in another project, I have to copy all the code. How do I build a state machine that I can inherit from and extend?

These twin challenges lead to the development of the Actor Framework. It incorporates ideas from several similar frameworks developed by users (both internal and external to NI), and adds a few extras to make it really robust. I found one CLA who lives near NI to test drive the framework in a real-world application. That work is still ongoing, but so far, the framework appears to function well, with good performance and no missing functionality. More importantly, it is easy to pick up and learn -- we decided that was important since so many of the macroscale frameworks that have appeared in the last five years have a steep learning curve.

The framework should not be considered "finished". The presentation includes some notes about further refinements that we have planned, and I am open to further suggestions from the community. I would like to see this develop into something that we can share next NI Week as a polished set of VIs and classes that any of our users can pick up and run with.

Please post any comments you have about the framework on the community page where the framework can be downloaded. That way any conversation about it is centralized instead of being spread across the forums, LAVA and the NI Community.

PS: The Actor Framework is saved in LV 2009. You do not need LV 2010 to view and use the framework.

CAR 236169 is fixed in LV 2010.

233951 is a duplicate. It is also fixed in LV2010.

CAR 236169 is fixed in LV 2010.

Daklu is correct -- the behavior was actually a bug in LV 2009. This CAR is fixed in LV 2010.

At the LAVA BBQ last night, I introduced the community to Songs For The LabVIEW Programmer, a little project I started in response to user requests at last year's LAVA BBQ. Admittedly, not all of the users were sober at the time they made the request for "some LabVIEW drinking songs", but I believe it is important for NI to be responsive to our users, even the inebriated ones. :-)

The songs are now posted here on the NI Forums. There are some drinking songs and also some teaching songs if you have kids who are learning LabVIEW. I particularly recommend "The Execution Highlight Went Down The Wire Route." Very educational. And it has hand gestures. ;-)

If you want to find Justin to buy a ticket and you've never met him (count yourself lucky), here's a photo of him lounging in a lounge in the NI-Week 2010 Lounge:

And if Justin tries to share with you any new Australian slang that he has learned recently, run. Don't ask questions, just run. A ticket to the LAVA BBQ isn't worth that kind of trauma.