Aristos Queue

I have not. I just tried my LV 2009 SP1 and 2010 installs. No such bug. I am on a Mac, so that might be a difference.

You can all send a thank you note to JGCode. He posted a question in the ni.com forums that happened to hit at a moment when nothing was screaming for my attention, and I finally got around to going through the VIs that handle New Accessor and the New Override and removing all the passwords and posting those VIs to the forums. http://decibel.ni.com/content/docs/DOC-13196 http://decibel.ni.com/content/docs/DOC-13195 The first link will get you the files that actually handle creating new VIs within a LV class and scripting the different behaviors for the terminals (including the UI for the New Accessor VI dialog). You'll find a wealth of scripting helper functions in this library. The second link will get you the files that handle updating VI icons when the library icon changes, including the composition of inherited class icons. Open the file "MemberVICreation.lvlib". That's where you should begin your explorations. You'll quickly see the two top level VIs -- one handles new accessors, the other handles new overrides. Remember, with great power comes great responsibility. What do I mean by this? I mean that I'd like someone to finish writing the ElementWrapperRetooler.lvclass for me. :-) It's one of the classes that is now unlocked. That class is the start of a solution to "I have a class X that has another class Y as a private data member. I want to create a new method on X that has the same conpane as a method on Y but with all terminals of type Y replaced with terminals of type X. On the block diagram, I want to unbundle the Y, call Y's method, and if there's an output, put the Y back into my X cluster." This has been requested by many people over the four years since LV was released to accelerate development of the Delegate pattern and similar patterns, but I've never finished writing it. All calls to any of the VIRetooler classes start by calling "MemberVICreation.lvlib:VIRetooler.lvclass:CLSUIP_RetoolVI.vi". Honestly, that should be the only public function in the VIRetooler class and the others should all be protected, but since the classes themselves are private to the MemberVICreation.lvlib, no one on the Language team has worried about setting the access scope correctly on the individual VIs. Have fun. PS: Although the passwords are all removed, the VIs and classes are all private to the MemberVICreation.lvlib. This keeps users from using these VIs on their own diagrams. If you want to use them on your own diagrams, make a copy of this library and make it public. That way when I completely change these VIs in a future version of LV, you're linked against your own copies instead of linked against the ones that ship with LabVIEW. We'll all be happier that way, trust me. :-)

Making it a symbolic path would encourage you users to link against it. If you thought we were cavalier about changing VIs in vi.lib that aren't in the palettes, that's nothing compared to what we feel free to do to the Resources directory. ;-)

I was working on a dual degree in both Journalism and Comp Sci. I didn't finish the Journalism degree -- had one year left to go and decided to focus on CS -- but I did work on the university newspaper for years. I don't think that is a fair evaluation of the journalist. Indeed, I found the two degrees most compatible.

Unfortunately, we can't do that either. Those types were written long ago and they use the ancient "this is a datalog refnum of an enum type" trick. So, properly, this is a type that the Not A Refnum primitive can accept, and it is possible that you might actually have a datalog refnum of the type and it might actually be a valid open file. We got rid of the CIN but we kept the API identical. All of it. By the way, Wolfram, congratulations on being only the 6th user I've ever heard of using the Rendezvous VIs in the 10 years I've been working on LabVIEW.

This whole thread should be posted on ni.com so some AEs can dig into it and file CARs as needed. I frequently file CARs for threads I see on LAVA, but a lot of what you're discussing here is beyond my knowledge to write up.

No reason to rename the VIs. AppBuilder uses lots of things out of VI.lib. So does the Getting Started Window. If it really is something that both LV and customers use, put it in vi.lib and let LV use that copy. It means that any bug fixes we find for Tools >> Options also get fixed for users of the dialog.

Really? Even though I likely buddied the code that introduced this bug?

You should know that under the hood, notifiers and queues are the same class. Notifiers always set a bounding of 1 and always use lossy enqueue. Wait For Notifier is almost identical to Preview Queue except that the Notifiers have the ability to ignore queue elements that the node has already previewed.

Yep. That's a bug. I'll file the CAR. CAR 246266

A) Definitely NOT the experience we hope our customers get. B) Please take a moment to post on forums.ni.com the bug reports on what you were doing when it closed.

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:

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.

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.

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. 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". They're still a foreign concept. :-)

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.

The Symbio tool can do the reverse engineering.

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

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?

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

Phew.

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.