Val Brown

This will be my third -- or fourth? -- NI Week and I've enjoyed the prior ones immensely. Yes, choose the events you want to attend and plan to get there early if they are advanced LV topics, given by "name" presenters. Last year there were overflow rooms for some very important and highly useful presentations. A number of complaints were lodged about that and, hopefully, NI has taken the hint and will schedule those presentations in far, far larger rooms.

Personally I wouldn't take the certification exams during NI Week -- except perhaps CLA which may only be given there(???). Why take the exams there and miss out on important information you can't easily get elsewhere? You can always schedule to take exams with your sales engineer (except perhaps CLA, but idk that for sure). Yes, you may pay some more money to do so but why pay for NI Week and miss the presentations?

From what I've been reading it sounds like this could be a scripting issue, perhaps even a right-click add-on: viz, to search the entire project for items beyond the boundaries of a structure and report that location, along with the number of items that are "hidden".

I also use the Windows included defrag routines, both in XP and Vista and have no complaints about them.

Yes it does suck, definitely. But I suspect this is also going to be the trend this year: ie an overall smaller number of attendees due to budgeting decisions.

Yes, all of those resources are really great. I'm thinking about the OO course myself but there is a real opportunity here for NI and I for one think it would be a real shame for them to miss it.

Congrats on the CLD and I want to underscore the book idea. This is something that NI should consider to be a priority IMO. After all the biggest criticism of LV is that it's a "toy" and that's largely because it isn't seen as a real support of OO. The status of LVOOP is now directly challenging that belief and writing the book on it would be a good opportunity for NI to communicate clearly just how capable LV really is.

It would also give me a really nice running start at getting on board with it....

Seriously you code develop the code (as you've done) and someone on NI's staff to ghost the text and/or you could team up with someone (like Jim Kring) and do "LVOOP for Everyone".

And NI can retire that particular question on the CLD exam. Other questions/examples/problems can always be derived.

Absolutely outstanding work! Well done and thanks for providing such an invaluable resource.

QUOTE (Omar Mussa @ Jun 5 2009, 06:02 PM)

We don't use locking at JKI and we haven't had any issues - whenever there is a conflict (which is fairly rare), we manually resolve the conflict. Generally, the best way to avoid conflicts is to be careful about doing mass compile save all type of operations that result in a ton of VIs that have *changed* because it may interfere with other developers when you commit.

Also, in case you haven't noticed, we just released a new http://www.jkisoft.com/tortoisesvn-tool/' rel='nofollow' target="_blank">TortoiseSVN tool for LabVIEW. It provides really tight integration of TSVN with LabVIEW and is really well suited for the update/commit SVN model.

Is this tool separate from OpenG or does it require OpenG?

QUOTE (ShaunR @ May 31 2009, 02:57 AM)

Because it is the programmers that argue in budget meetings to maintain the SSP's. Programmers that buy the latest versions to take advantage of new technologies (do you really think non-programmers would write OOP labview?). And it is programmers that non-programmers rely on to help them understand Labview (like this board). It is also programmers that NI rely on to beta test, so they can take advantage of a "Free" resource" and to be considered a second priority I (quite frankly) find insulting. This is typical "Microsoft Mentality". Most non-programmers only use Labview if it is already there and rarely get past modifying an example to achieve a specific result. That sentiment belongs 10 years in the past and QA should know better than to state it even if he thinks it.

I kind of agree. Scripting only has value within the tool chain. You can't use it for in your distributions so there is no commercial value added other than tools for programmers (and I've been using Labview so long now, I don't really need anything that Labview doesn't provide). I don't see much benefit for anything I do, that a VI in the pallet set to "Place Vi Contents" can do more easily and in less time. Admittedly there are "cool" things like the voice control etc. But I view those as "finding a purpose to fit the feature" . If we could create our own controls at run time using scripting, then this would be a boon. But as it stands, no commercial value, no interest.

I don't want to start a flame war here, not do I want to hijack this thread, but IMO you are completely offbase with this comment and thinking. I have NO degree in CS. I have no "official" programming/programmer's background. I have been on SSP since 98 -- for several years for both Mac and Windows versions. And I only program for my own project even though I have been asked repeatedly to program for others. And I KNOW I'm not the only "non-programmer" in the NI world but I also know that I've put NI through its paces in terms of number of CARs issued, etc over the years.

In contrast to your comment about "typical Microsoft..." I would say that you perspective is "typical OOPs: meaning Object Oriented Programmers 'stuff'". Let it go man. Look at the BIG picture -- which is the basis on which NI has not only survived but thrived by NOT primarily catering to nor orienting itself to "Programmers".

OK end of rant and end of comments on this perspective.

QUOTE (ShaunR @ May 30 2009, 01:50 PM)

This in an horrific statement.

Why do you think it's so horrific? It makes a great deal of sense to me -- for what THAT's worth -- and it is an honest reflection of the nature of NIs products and orientation.

QUOTE (Aristos Queue @ May 30 2009, 09:28 AM)

That is correct. Scripting requires recompilation, and there is no compiler in the runtime engine.

Your best option is an array of controls... you can resize the array at runtime to display more or fewer controls.

And you COULD even wrap that functionality into a VI that was called "Create..." and feed in which control to expose....

Kind of make an object out of if desired.

QUOTE (Aristos Queue @ May 29 2009, 09:50 AM)

http://decibel.ni.com/content/docs/DOC-4973#cf

After years of lobbying, National Instruments has now released scripting as a tool that our users are allowed to use. The Windows license and support files are now available for download from the above link. Mac and Linux download will be posted next week.

For those who are wondering, "What do we need to download on Mac/Linux since there's no licensing required?" ... there's a .zip file of useful information and instructions that will be posted.

Nicely done AQ et al to have gotten this released. Perhaps an event/presentation at NI Week on how to use scripting would be a good idea?

I do hope it doesn't create too many support headaches for NI. That will make it more likely that NI would decide to release other "features" on a "need to know" and "at your own risk" basis.

QUOTE (jdunham @ Apr 27 2009, 08:09 AM)

Queues are cool that they can even the load if your data is bursty, but queue or no queue, if you're not processing fast enough, you have a problem that queues couldn't fix.

I would never send data through a queue that wasn't meant for the queue listener. I would just use separate queues to send data to separate loops that were 100% devoted to handling that data.

OK, I give up trying to convince you. We obviously use queues in very different ways. I find them useful, even indispensable. My team's code doesn't suffer from any of those things you say queues suffer from, and we're doing things that you say are nearly impossible in LabVIEW, and they were pretty easy to code up and have great performance and scalability.

It's fine if you don't want to use more queues, but I don't think you'll manage to dissuade the rest of us.

Maybe it's time to put this into a queue that has no dequeue or maybe a global variable that is never read.....

Zhuang-zi (Chuang-Tzu) because most of his "text" was in pictures (pictograms) that carried additional "cartoon" messages, beyond the literal text/transcript.

QUOTE (ned @ Apr 17 2009, 05:44 AM)

Yup, that's exactly what his problem is. If you check off the "Send me email confirmation of this activation" box when you install/activate your NI software, you'll get an email back with a bunch of long, unique codes, one for each product you've activated. So he's not getting different treatment than the rest of us with an SSP, he's just unfortunate to be working on a machine that's not on the internet.

EDIT: oops, somehow that comment was the last one on the page and I missed that the comments had spilled onto the next page where everyone else had commented on the same thing before I replied.

Shane et al: Yes that's what I thought but I guess the background implication in asking it that way is: Why isn't it internet enabled and/or why can't that be done just for this one operation?

CRELF: Yes, I'm sure you're right because the only possible timeline I've heard discussed is that scripting will be released AFTER all the toolkits are implemented for Linus and Mac and the timeline for THAT to happen was something like "...when Bush gets elected for the third time."

QUOTE (Jim Kring @ Apr 16 2009, 05:14 PM)

To get this back on topic, I think that we should all wear tie-die shirts to NIWeek that say, "Legalize Scripting".

How about "Release Scripting!"?

QUOTE (Val Brown @ Apr 16 2009, 07:42 PM)

...or "Liberatus Scriptus"

QUOTE (ShaunR @ Apr 16 2009, 01:11 PM)

Hmm. Not sure about getting screwed (it's not that expensive) but I have complained many times - every time I upgrade in fact.

That said, I'm not talking about the Serial Key (I've got one of those that covers everything) I'm talking about the activation codes since the development PC isn't connected to the internet

I have to phone up NI and (always seems to be a girl called Sam.....lol) they look my details up and maybe a day later 25 e-mails come through with the activation codes which I then have to get to the other machine. Real pain in the proverbial 2-3 times a year especially if they miss hear the computer ID or I haven't upgraded all the items!

I do all of that online in one operation so I'm not sure what's happening on your system except, perhaps, it's not online?

QUOTE (TobyD @ Apr 15 2009, 11:28 AM)

You're getting screwed. I am not on a volume license and I have a single key that works for everything that comes with the LabVIEW Developer Suite + Automated Test Option + Machine Vision Option.

Ditto for me.

QUOTE (bsvingen @ Apr 13 2009, 01:43 AM)

AQ:>In other words, that which you use, you use, and is documented, and your final application has no reliance on unrevealed things. Does that lessen your objections?

Yes it does.

And this COULD be made clear through thorough "unit testing" throughout the development cycle.

QUOTE (bsvingen @ Apr 11 2009, 02:08 AM)

You are missing the point (at least half of it). The behavior is not the issue, the quality is. More presisely you want to get rid of all possibilities for unexpected things to happen, at least as much as you can. It is about failure modes, not validation of operational modes.

Testing of a system and documenting (defining) its subsystem are two different things. Testing a system consisting of undocumented sub systems will still leave you with an experimental system. This is a simple fact.

Something tells me some of you just don't get it (no offence ) Without stretching the similarity too far, minimizing failure modes is somewhat similar to minimizing the possibility of bugs entering the code. In this respect LV already is way beyond most other compilers. It is also somewhat similar to the reasons for encapsulation (and OOP). You simply cannot expect the unexpected, but you can minimize the possibility of unexpected things to happen by assuring everything is well defined, minimizing side effects and by reusing things you know have no failure modes. Is it possible to be (reasonably) sure that things are well defined without documenting it so other people can look at it, or at least leave the source open? I doubt it.

I think YOU "just don't get it". NOT using undocumented features means, among other things, "assuring everything is well defined, minimizing side effects and by reusing things you know have no failure modes". In other words, do use/reuse undocumented features UNLESS you are clear in what they will and won't do and you have validated all of that with specific unit testing, etc procedures.

Your last point really says it all IMO: "Is it possible to be (reasonably) sure that things are well defined without documenting it so other people can look at it, or at least leave the source open?" The answer is: Yes and, if not, then don't use it; and validate that by your own systematic testing program regardless. It also sounds like this is another plea for LV to be open source based on the belief that open source is inherently "better" than code that is not open source (such as LV). If that is what you truly believe, then why are you using LV? How do you rationalize that your behavior -- in using LV -- contradicts what you're posting here?

QUOTE (jdunham @ Apr 10 2009, 08:27 AM)

I totally agree with Justin. What if the compiler used by NI to build LabVIEW itself contained an undocumented feature? What if the operating system contained an undocumented feature, or else the OS used to run the compiler that built LabVIEW? The compiler is just a set of bits which generates another set of bits (LabVIEW.exe) which generates another set of bits (your app) which is controlling the action. Just because their creation is separated in time doesn't mean it's not just one system. Testing is the only way to validate behavior, not any proof about a closed set of features.

You ask interesting questions to which I would reply:

I'm certain that the compiler DOES contain undocumented features. I'm also certain the the OS does as well. And neither of those conditions means that it is unpredictable -- UNLESS (perhaps) one uses those undocumented features.

For years Ken Thompson used to deny that there were ANY "back doors" into the Unix kernel. We all KNEW that there were. Ultimately he did confirm that they were there. I've never seen an OS nor a compiler that doesn't have undocumented features but, then again, I'm pretty much a realist and, if the unit testing process works so outcomes can be validated, that works for me. So who knows? There may well be an OS and/or compiler that has absolutely NO undocumented features whatsoever. I don't really care because I gave up on idealizations a couple of decades ago.

QUOTE (bsvingen @ Apr 10 2009, 12:37 AM)

...There is no way anyone can convince me that including undocumented and experimental code that potentially can lower this reliability, is ethical.

OK, you believe it's unethical. None the less, it happens and varieties of it happen all the time by design and that is sometimes not documented BECAUSE it's "experimental". Calling it unethical to do that really doesn't change much in what happens in the real world nor does it alter the fact that this happens for many good reasons not the least of which is that it really is impossible to anticipate all possible failure modes of a real-time, physically implemented system.

So, if you are going to be consistent with your beliefs -- and also not be unethical yourself -- I would guess that means that you can no longer use LabVIEW.

I'll see you in Portland.

QUOTE (bsvingen @ Apr 8 2009, 09:26 PM)

I have never claimed that, you are reading too much into it. What I said was that the same quality and reliability is expected of the software as is expected of every other critical component or subsystem, and that modern systems are increasingly becoming more and more all digital (no old fashioned mechamical operational mode exists). Then, this leads to my main point that including half-finished code in the finished product is not the way to assure the quality and reliability needed for mission critical tasks. There are way to many things that can go wrong as it is, you simply do not add more. In the same way that you would not expect critical mechanical components to fail, you would not expect critical software to fail. Then it is the job for the engineers to do everything they can to prevent critical components/software to fail. This means, among other things, to remove unessesary failure modes.

The Airbus is all digital, and the same is B-777 (you should read that article about ADA). What this mean is that there is no other way to control the airplane without going through at least one computer. The Airbus A-320 actually has 5 parallel lines, 5 times redundancy, but it is still all digital, there is no manual/mechanical mode except possibly manual elevator trim.

Maybe, I am afterall a confusing person But there is a third alternative; undocumented and experimental :ninja:

I think if you speak to those who have flown those aircraft you will find that there are actually experimental "options" in them. AFAIK there has never been an operational aircraft, let alone other complex system, that is completely closed and "insulated" in the way you suggest.