Aristos Queue

I don't see the difference. a scoundrel programmer could drop the the class and not use this method. One way you insist the programmer drops a vi to construct a class, the other you insist the programmer drop a method everytime he construsts a class. I don't care either way but I do not see any improvement. Either way you have to do extra and define rules as a work around for this limitation. Programmers choice.

Suppose I drop a block diagram constant of Car. That Car will have whatever the default values is, since no method has ever modified it. If I wire it to "Get Speed." Jimi would like the value of zero to come out. If I drop a block diagram constant of Ferrari, it will also have default values for all of its private data, including the default value of zero for speed, and if I wire it to "Get Speed", I will get the value of zero. But Jimi wants a way such that a virgin instance of Ferrari will give a value of 200 when passed to Get Speed.

We could require that any time you drop a BDConst of Ferrari, you must wire it to an initialization method that sets 200 into the speed field. But that puts the burden on the user of the class to remember to initialize. That's problematic.

Ideally the language would have support for letting a child class set the initial values for its parent fields. I know a way to make LV robust in this manner, but it is non trivial to implement correctly, and there are other higher priorities. So as a workaround, I'm suggesting that we add a boolean, "Virgin speed?" that defaults to TRUE. Then when Get Speed is called, it can output 200 for Ferrari if and only if that boolean is set. If the boolean is not set, then output whatever the current value for speed happens to be. The work around makes it so that virgin instances of child classes behave as if they have different default values than the parent class.

A slight simplification would be to have the default value of speed be something special, say NAN (not a number). "Get Speed" would detect NAN and output the correct constant value for the class if NAN was detected, and otherwise output whatever value had been set into speed. This eliminates the need for a separate boolean field. If you have many fields that need to differentiate, then this would be a better way than having a different boolean for each field.

The problem with just letting the child class fill in values for its parent fields to be used in all default instances is that those values might not be legal values, as defined by the parent's API. We're going to have to work into LV a way to initialize those fields through calling a VI that can call parent API functions, instead of just setting the fields directly. That's a more challenging integration into the language, especially since, as Jimi points out, such initializations would want to be able to be constant folded. Doable, but not immediately.

Background: I wanted to write a VI which stores all control values of its calling VI to an XML file, and reads them back.

There's a weird piece of LV functionality that might help with this. Drop an subVI onto any block diagram, then popup on it and choose "Enable Database Access". This puts a funky yellow halo around the subVI with extra terminals. This lets you do FP querrying for historical values of the FP of the chosen subVI. Details are here:

http://zone.ni.com/reference/en-XX/help/lv...Logged_FP_Data/

This is a feature that doesn't get used often, but I've always thought it was an interesting idea. It seems like there ought to be more you could do with this "halo" concept, but it's never really been expanded on, and most LV developers think its kinda lame. Still, it might be interesting for you in this case.

Is this the first ever appearance of actual LabVIEW "source code"???

No. Acutal LV source code is in <labview>\resource\...

Just look for any file with a .vi file extension. ;-)

Great quote Ben, although I know Aristos has a sense of humour: how could anyone on LAVA survive without one?

Merely because I have a sense of humor doesn't mean you're safe. I might be the kind of sick bastard who thinks

if (wireType == kInt)		  return (0==StrCmp(username, "crelf")) ? kOrange : kBlue;	 else if (wireType == kDouble)		  return (0==StrCmp(username, "crelf")) ? kBlue : kOrange;

is hysterical... :ninja:

p.s. I really want NI to add animated as well as noisy icons. Imagine a VI which would make sounds as you debug, wouldn't it make life so much more exciting... (do we have a life?)

I have this horrible vision of high pitched noises leading to bug reports about "I was debugging my diagram and I kept getting attacked by my dog when the Divide primitive had a zero wired to the bottom. I have attached the VI in question and my dog." I think my response would have to be "LTTFM" -- "Listen To The Freaking Manual."

dont be too harsh

Actually... EXCELLENT job. You've got the right general direction. There were changes to your inheritance hierarchy that I made -- not fine grain enough. Keep each class focused on a particular aspect of the system. Detailed comments are included in the refactored project (see attachment) both in comments on the VIs and the HTML file that I've added to the Project tree.

Download File:post-5877-1163786011.zip

NI: Is it at all possible to get a copy of it back in its origianl position under numeric>contants? After all, all it really is is a numeric constant...

Sure.

Tools>>Advanced>>Edit Palette Set...

Oh, you mean permanently, as in, move it in the next version of LV? Probably not. We don't like to move the palettes around. It makes existing users cranky. We only do it when we have a good reason.

And, like an oncoming train, I can hear the question coming, "So what was NI's good reason for moving it in the first place [or any of the rest of the palette reorg]?" Today, I'm tired. I don't feel like trying to explain the reorg, its reasons or its final benefits. So I'll leave this question hanging and let you contemplate hypotheses. FYI, the hypothesis that "NI likes causing users pain" is probably wrong. A lot of VI developers who've been using LV since LV N where N is a very small number helped with this reorg, so it can't be all caprice.

You're right - I could have used the search function (if I had a spare half an hour to wait for the results )

Unfair.

This one I do feel like defending.

Hit Search button first time in LV8.2 right after launch on fresh reboot of LV: 13 seconds while full palette set parses.

Exit LV and restart LV8.2, and immediately hit Search button: 1 second (files are in OS cache)

Successive hits of Search button without restarting LV: instantaneous

If you launch LV and don't use the search in your first couple minutes of programming, the palettes quietly load in the background, in the spaces between mouse clicks, and you'll get pretty close to instantaneous time on first use.

Similar times for LV8.0, though the background loading isn't as smooth.

The only way you'll get a spare "half hour" is if you keep your palettes and vi.lib on a remote network drive somewhere off-continent.

Write a constructor. It will contain the class object and set data for the class. Instead of putting the reference on the diagram you put this vi.

That doesn't provide the initialization guarantee that Jimi is hoping for -- a scoundrel programmer on your team could still drop the class directly instead of dropping the initializing VI.

Jimi: I did think of one workaround.

Parent has member data "speed" which is a double.

Parent also has member data "default speed" which is a boolean.

Parent has a protected dynamic member VI "GetDefaultSpeed" which returns a double.

Parent has a public static member VI "SetSpeed" which sets the value of "speed" AND clears the "default speed" boolean.

Parent has a public dynamic member VI "GetSpeed" which checks the boolean. If the bool is true, it calls GetDefaultSpeed, which dynamically dispatches out to children. If the bool is false, it returns the current value of "speed"

Each child then overrides GetDefaultSpeed with their desired value.

I know -- a lot of overhead for the programmer. I have a solution in mind, but it's going to be a while (almost certainly not the next release) before I can get to this.

This was reported to R&D (# 43EEI1J1) for further investigation.

Hi,

I have a class hierarchy of multiple classes in LVOOP. Let's call my top most parent class "Car". I define it a private data member which I'll call "top-speed". I set default value to 0 as my general car doesn't have top speed. The I create a child class called "Ferrari". As I know that my Ferrari top speed is 200MPH, I'd like my Ferrari class constant to really represent this value. So the question is, is there a way to define different default value for the parent private data in a decendent class so that when I drop Ferrari constant to the block diagram, it would at least have correct properties for Ferrari.

There are no constructors in LVOOP so I cannot use constructors to take care of the task as in other OOP languages. I can write an initialization function, but I wonder if it could be avoided. I guess not... (perhaps this post should be in the wish list section and not here).

No method exists. This is noted in the design documents white paper as a limitation that needs to be addressed in future versions.

I would rather see the option of creating enums where the values of the strings do not have to be sequential. Is this not why ring constants are used instead of enums?

Within NI, I have to use rings instead of enums because rings can be localized into various languages without recompiling the diagrams (the data types don't change).

THX Stephen your reply does justify our green light for LV8.20 development without OOP. I was getting worried because we have a least 10 Lv8.20 projects going on (one will run in a nuclear power plant!).

You're welcome.

I do want to stress that the runtime functionality of LVClasses seems to be clean, and the problems only arise while developing. In a 1.0 release, I'd be uncomfortable with LabVOOP running the control rods at the nuclear power plant, but perfectly happy if it was controlling the lawn sprinkler systems. After the bug fix release, then I'd be ok if you go create "Nuclear Power Plant.lvclass".

And, before anyone else asks, no I can't supply a date for the bug fix release.

Jimi:

I have appreciated your adoption of LabVIEW Object-Oriented Programming (LabVOOP). Both your bug feedback and your feature feedback have been valuable. LV8.2 includes the first release of LabVOOP, and, yes, LV classes do tend to make projects unstable. This is due to, by my count, seven significant bugs that have been found since the release that will be patched in the next bug fix release. FYI, three of those bugs have been found through your testing.

I can offer you a workaround for the majority of the problems. To begin with, make sure all VIs for your application are in memory when editing the class' private data control, and always do Save All after editing the PDC. This is not necessary for most edits to the PDC, but it prevents corruptions from developing in some edge cases. If you do begin experiencing problems where the VIs become corrupt (and crash as soon as you hit the run button), then load your project and open the top-level VI and then hit ctrl+shift+run arrow on the top-level VI. This forces a recompile of every VI in memory. That rebuilds various tables from scratch completely. On a large project of 585 VIs being developed inside NI, this process takes about a full minute. After it completes, save *everything.*

The runtime system of LabVOOP appears to be stable. It's the editor environment where bugs are appearing. Within NI, I am aware of three major projects that are using LabVIEW classes (there are likely others, but these are the ones I've watched closely to get a feel for problems developers are finding). These have been able to replicate the large-project bugs to which you refer. My team has been tackling them as fast as possible. These three have hit problems, yes, but development has proceeded and seem likely to be successful.

You said you were moving away from LabVIEW for development. LabVIEW 8.2 is very stable, as measured against various prior LabVIEW releases. The next bug fix release should bring the LabVOOP components up to the quality of the rest of LabVIEW. I would be very sorry to lose you as a developer. I understand your frustrations, but I ask your indulgence. It took C++ multiple years to get compiler stabilization, and I think we're well ahead of that standard. The power of classes to the end programmer comes because the language tracks so much information on the programmer's behalf, and getting that tracking right is tricky.

The core of LabVIEW is stable. LabVOOP is not core. It is a recent extension that is being stabilized. I understand if in the short term you move away from LabVOOP. But moving away from LabVIEW as a whole would be overkill, in my opinion. You have a house with a good foundation. I'm sorry the toilet in the new bathroom keeps backing up; we'll have it fixed in short order, but in the meantime, you can live in the rest of the house, which has stood for 20 years. You don't have to move out. Our commune would miss you. And I can guarantee your new place would have poorer wiring.

-- Stephen R. Mercer

-= LabVIEW R&D =-

Lead developer for LabVOOP team

No offense but in the world of LabVIEW applications/systems, my opinion is that NI has a limited view of what real LabVIEW applications look like. I realize that you qualified your statement but I was also offended. There are many reason why you or other NI staff will never see good code. One of them is that a lot of developers including myself simply don't trust NI. You only see what we let you see. :ninja: .

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.

One thing I would like to see is when you right click a class New -> VI that the vi would have the class controls and error clusters already on the FP.

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.

Perhaps I can fix it if NI hires me with good enough salary

Have you submitted a resume?

http://ni.com/jobs

It still bugs me that when I open the Parent Do cmd vi it shows me a vi that does nothing and LabVIEW gives me no option to see the child vi's block diagrams.

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?

For OOP newcomers certain patterns should be discouraged so that these people really learn how to use OOP correctly.

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.

Generally I am interested in working in USA for one or two years. In my first approach I would not like to stay longer, because your speed limit really hurts me - or I'd have to take my car along and need a race track near to the place where I would live

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 sure if a potential employer were to take the time and sit down with me to discuss my experience and relative work-history and set degree aside, I'd be able to prove myself competent. Sadly though, you have to impress them enough on paper to even get to that point (interview). Without the often sought after line items (degree, GPA), it's tough to get.

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???

I'm mysterious in the ways I use LabVIEW Well, I think this bug was project specific as I've not seen it any more. The class doesn't in general break even though the polymorphic templates are not functional.

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.

This has occurred to me a few times. If I add an empty polymorphic VI template (.vit) to a class that belongs to a library, everything seems to be fine at first glance. Later on it may occur, that LabVIEW spontanously decides that the class is broken, because it includes a polymorphic VI (the .vit template) that is not executable due to the fact that it contains no VIs (it's empty). LabVIEW behaviour is not consistent here, since it allows adding the template without breaking the class.

"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?

Firefox is better than IE, IE is better than Firefox - I don't care - I'll just use whichever one lets me browse more pages. It's a tool people.

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.