Aristos Queue

I suspected I'd offend some folks with my statement, but it really is the view that I get from the VIs that I do get to see. Knowing that my view is skewed is part of why I lurk on LAVA and info-LV -- users are willing to share code with each other that doesn't necessarily get shared with NI, and if I happen to be looking I get to see it too. But such lurking still only reveals small utilities and snippets. I've heard the comments about not trusting NI before from others (didn't know you, Michael, were in that camp). I don't know why/when that attitude developed, but the lack of trust causes a blindspot that makes it hard to evaluate what LV features would be helpful to users. I'm probably going to dig myself a deeper hole here, but I want to expand my comments a bit. The lack of programming experience among LV users is well-documented -- indeed, NI focuses on such users, since our goal is to provide easier control of the computer for those who would otherwise have to hire someone to do C code. My second-most-favorite bug report of all time is "If my wire is over 16k pixels long then when I right click on 'Clean Up Wire' the function deletes my wire." The common joke to make when that bug report came in was, "Well, it seems like Clean Up Wire did the right thing..." But if you looked at the VI, it wasn't badly written, just huge. It came from a long-time programmer of LV (you'd have to be a long time programmer just to have a VI that spanned 16k pixels...), but it seemed as if no one had ever mentioned the concept of "subVI" to this programmer. I don't mean that stupid things never occur in code from people with CS degrees. Heck, my own code is rife with dumbness that I realize a year later when I review it. But there's a difference in the types of errors between those who ought to know better and those who just never got shown how to do it right. The latter group is arguably the stronger group since they've had to puzzle it out by themselves. But the former group may eventually realize the mistake and correct it. The academic training provides tools for recognizing such code. Further, the academic training gives people a common background and a common terminology, and, in a team environment, that commonality is important. To me, the problem with a pure experience candidate is the same as with a pure academic. Without the work experience, the academic's theory and training doesn't get honed, and you end up with bloated class hierarchies and impractical ideal designs. An ideal candidate for employment has both the on-the-job experience and the academic training. So if I'm hiring for a job on a programming team, my bias will be first to the person with both experience and academics, and then second to the academic who can gain experience while working, and only third to the pure experience candidate -- because there's no way to get the academic training from holding the job. Now, if I'm recruiting for an academic environment, then the pure work experience is prefereable because they're moving into an environment where they can learn the academic. It isn't that there aren't incredible programmers who have learned their craft by pure OJT. Those folks do exist. I've met many, and some of them are better than anyone with a degree. But such folks are rare. And that's why I think filtering a resume based on whether or not the person has a degree is a legitimate filter for a business to apply. Without that, you have to, as others on this forum have said, have the personal connection to know that someone's skills directly.

The LV compiler already does some loop unrolling. That's something you'd never actually see on the diagram, just as you don't see it in C compilers, etc. If we ever had distributed parallelism, where each frame of the loop passed to different computers, that's something that would be displayed to users.

New>>VI will always generate a blank VI. Not every VI in a class has the inputs/outputs you're talking about. New>>Dynamic VI does what you're asking for and, in LV8.2, if you want a static VI using the template just generate a dynamic VI and then turn off the dynamics in the conpane (right click on terminal, select "This Connection Is >> Required" -- for both the input term and the output term). My team would like to add more useful templates as time goes by (such as a New>>Static VI that does as you request), but the New>>VI will always give you fresh starting point. Have you submitted a resume? http://ni.com/jobs

Fascinating... it bugs you too! I thought I was the only one. Someone should do something about that.

Wouldn't you just drop a Bundle node, bundle the two pieces of data together and then wire the cluster to the write node?

Heh... at this stage of the game, anyone claiming to be past the learning stage of OOP with LabVIEW is not being honest with themselves. As far as the feature request -- you can code the dynamic type tests to validate inputs easily enough. Adding them to the language would be a VERY VERY long term feature, if at all.

The Texas Motor Speedway (between Austin and Dallas on I-35) is open to amatures who want to race their own cars in the off-season. I'm going to offer a bit of an opposite take from a lot of the posts here. Several posts have suggested that self-taught, on-the-job training is as good as having the degree, given enough time. I'm not so sure that's true. I was a pretty good programmer before college, but the styles I had "worked out" on my own, although good enough for the personal projects I worked on, were pretty bad for working in any sort of professional environment. I know that my programming methods became much more rigorous over the course of college. How much of that would I have gotten from on-the-job training? I don't really know. But I do know that an employer would've had to put up with me for several years before I had enough exposure to be equivalent to the degree. Most LV users are not programmers by education, and, honestly, the VIs that I see reflect that. I'll grant that most of the user VIs that I see are in bug reports, and I rarely see entire systems, so I may not have a good view, but some of the programming choices that I see are clearly "something that works" and not "the right way to do it." I can see this being true of many fields -- the self-taught person is sharp, clearly able to produce, but perhaps has never seen some of the standard ways of doing things, and thus ends up producing systems that are hard for others to use/modify. In this respect, I don't think it is merely a convenient way of filtering a large stack of resumes. A degree proves that at some point, for at least one semester, you were exposed to a particular idea and that you've been properly biased toward a central model of doing some job. If you're hiring an artist, maybe you do want to go for avant garde. But if you're hiring an engineer, especially an engineer who is going to be part of a larger team, you want that standardization. You might be able to prove the same standardization exposure with certification exams. But you've got to have something like it because otherwise no matter how impressive the previous work history, there's little on a resume that will show that the work done at those previous jobs will be useful at the new location.

Yeah... sounds like a bug. It's late tonight... if you don't see me post a CAR number here tomorrow, remind me later in the week. Later edit: This was reported to R&D (# 436FPTJ1) for further investigation.

Ug. Sounds horribly complex. What in the world are you architecting where it matters whether or not the two input terminals have matching runtime types???

When you say "not functional" -- what exactly do you expect them to do? I've querried several folks, none of whom have ever even thought of putting a .vit extension on a polyVI. What would be the purpose? The fact that you can do it is just an artifact of being able to put any file extension on any VI.

"polymorphic VI template" -- you mean you created a PolyVI (File>>New...>>Polymorphic VI) and saved it as a .vit? Why do you even create such a thing?

A browser is not a tool. It is a pet, not unlike a dog, that fetches data for you on command, but occassionally pisses all over your harddrive or chews a hole in your network security. Ones that are well bred tend to respect your position as pack alpha. Others think they are in charge and decide that "you want to go here today" whether that's what you wanted or not.

It seems unlikely that your UNICODE-->ASCII works given all the possible UNICODE encodings. I say this, not because I'm an expert in Unicode, but because I know how much I don't know. For example, http://billposer.org/Software/uni2ascii.html This is an open source ASCII-->UNICODE-->ASCII tool. Notice the revision history? This simple tool has a change log that goes for pages and talks about support for multiple encodings, etc. Further, the standards document for unicode has *chapters*. Compare that with your standard listing of the ASCII standard, which is just a table of 256 characters. Here's the motherload of information about unicode: http://www.unicode.org/unicode/faq/

Although I am fixing MANY icon issues with classes in the next revision, that's not one I'm touching ... adding the number is a long-standing LV feature to provide uniqueness of icons for lax users who don't generally edit their icons. If you want a workaround, go create 9 new VIs. The numbers only run 1 through 9. All VIs that you create thereafter will not have a number added in the corner. But otherwise just assume that the lower right is going to get hit. ... I think you might find this less of a pain in the next version. As I say, I'm adjusting several aspects of icons for LVClasses to try to eliminate the pain. In all these years, I think this is the first time I've ever explicitly promised a feature to be in a future version. Must be getting weak.

It should help if you have multiple coercion dots on the same wire. This answer is not definative... I know that the above is one situation where explicit coercion helps. There may be others.

Didn't we just announce that at NI Week 2006??? http://www.ni.com/niweek/keynote_videos.htm Take a look at Noel Adorno's presentation. She introduced the DLL Wrapper in the keynote. You can download it from ni.com somewhere... (I don't have that link).

Yes. I strongly recommend never using the FP.Open property. It is "old style" and the FP.State was added to supplant it. Passing "false" to FP.Open is an ambiguous situation. If the window is already hidden and you pass false, did you intend for us to close the window entirely? This is just one of many ambiguous situations. The behavior in all these cases is well defined, but in all of these cases you have to figure out what decision LV R&D made. The old style still exists because of the huge number of toolkits that use it.

If you're advanced enough to figure out what the Show Buffer Allocations tool does in the first place, then your name is probably CRelf or equivalent and appear to have no problem magically figuring stuff out.

Instead of "assumed to be positive I32", why not use an unsigned 32-bit? Then you don't have to worry about someone passing a negative.

I do the same thing frequently, but I tend to use the Queue primtives... enqueue the first element, loop while the queue is not empty. On each iteration, dequeue one, then Enqueue the next level. If I need it to be depth-first (stack) then I use the "Enqueue at Other End" prim. I don't know which solution offers better performance.

Boredom. To prove to myself that it could be done. And to give me a way to code LV programs while on plane flights without a laptop. Nothing that I've ever turned into functional code. Just a math proof of concept.

Jacedom: Were any of the other situations that I posted "interesting cases" for you? I want to keep pushing this discussion because your position is somewhat unique. 99% of the time, the question asked of LV R&D is not "Should LV have recursion?" The question usually asked is "why doesn't LV have recursion?" It gets asked with high frequency, and attempted by some developer on the team about once every two to three years as far as I can tell. This keeps the research focus on the question of how to do it. The LV R&D team has been pounding on the recursion problem for *years* (bordering on *decades*) and we've recently started making some headway for dataflow-safe recursion. This is definitely the time to be asking the "should" question. Statistical outlier opinions are always worth at least a glance -- the definition of genius is the guy who saw something obvious that everyone else missed. Your basic position, as I understand it, is two-fold: 1) The overhead of recursion outweighs the ease of its coding. 2) The iterative solutions are possible (that's provable) and they're sufficiently easy to implement in LV as compared to other languages that they should be preferred. Is that somewhat correct? On the topic of overhead, the current "recursive" solution is VI Server with reentrant VIs. That's not recursion IMHO and of course its performance sucks. Recursion works, and works well, when it has what LabVIEW doesn't have: a call stack. The $64000 question is "can you build a dataflow safe call stack" or something that performs as well. If we (R&D) can do so, should we? That brings us to the preference for iterative solutions. I want to debunk one comment about other languages not having shift registers... in this loop: int i = 1; while (true) { ++i; } 'i' has the same functionality as a shift register. I've done a bit of work on a text-based version of LV using C syntax, and a shift register is nothing more than a variable you declare outside the loop and promise to only assign once at some point during the loop. Is there some aspect of LV that you think dramatically improves a programmer's chances of correctly coding the iterative solution to most recursion functions as compared to the recursive solution? I don't know of anything myself, but I'm open to argument. > I never heard of the Fibonnacci numbers before this > topic...i am more interested at the recursion and > stacked iterative implementation concepts regarding > specifically LV. I think the point is made that you tried to convert the formulas as written into an iterative solution and got it wrong. I'm not trying to rub this in, just pointing out that I myself find converting a recursive problem into an iterative solution VERY HARD. I think that most software engineers would botch conversion of all but the most trivial problems. As far as the comment about an iterative solution making you think about other use cases, I don't get that point at all. When I conceive the use cases for any function -- XML parser or whatever -- I do it independent of the implementation of the code. I don't see how looking for an iterative solution changes the functionality you're trying to provide. I know that none of my arguments speak to the efficiency of code --- code performance frequently is better with an iterative solution than with a recursive solution. I've seen that. But in my 16 years of programming, I've learned the hard way that code correctness has to be the first priority and optimizing the code comes second, if it turns out to be needed at all. LV doesn't have recursion today. But it continues to suck up R&D time because the demand for it is high. It turns out to be a hard problem to solve, but I assume that some decade it will be solved. I don't think you've convinced me yet that I ought to encourage my co-workers to turn their attention to something else.

I know why you're having the problem, and you're not going to solve it easily. 1) A class stays in memory as long as there are any instances of the class in memory. Get rid of all instances of the data and the class will be able to leave memory. This means any control or indicator whose current operating value is the class value would need to be reset, and all the little copies hiding on terminals across the block diagram. About the only ways to clean it out are a) run the VI again with a different class that overwrites the previous execution (tricky since you have to hit all the same code paths) or b) unload the VI from memory. Why does it stay in memory? Because all those instances of the data need the class definition to be able to be copied, modified and even deallocated correctly. 2) A class stays in memory if there is a dynamic dispatch call to its parent class if those VIs are running. Remove from memory any VI that is calling the parent class methods. Why does it stay in memory in this case? Because we don't know what sort of flattened strings might represent your class data that you might be about to unflatten. The only solution is to make your system really dynamic so that you dynamically load the parts relevant to classes and when you want to unload you unload all those VIs, then load again with the new set of classes.

This was reported to R&D (#42IHGKJ1) for further investigation.

Any time two subVIs are in parellel with each other (meaning no wires output from one are needed as inputs to the other) then they will run in parallel. If you put those two subVIs into two subpanels, they'll run independently without any intervention from you.