A scathing review based on my experience upgrading from labview 7.1 to 8.2.

[Ben]

---

Jeff wrote;

A VI needs to be compiled to show the dots.  Saving a VI causes it to be compiled.  CTRL-Run also causes a VI to get compiled, but without saving it.

---

Thank you for the correction. I did not knw that!

Ben

[Ben]

Correction to my previous.

I knew it had to be compiled, I did not known the ctrl-run to recompile was enough for the dots.

Again thanks!

That is why I hang out here.

Ben

Message Edited by Ben on 06-14-2007 11:45 AM

[billings11]

Yeah the vi is compiled.  I'm just seeing dots only in a very few places on the inputs of the vi I am working in.  If these dots are right it looks like classes do not always duplicate memory inputs and outputs of subvis like normal data types.  But its tough to tell from the LVOOP whitepaper where are the actual places one could expect a duplication of memory space.  Previously I implemented polymorphism in a very class-like way by using clusters of enums and variants.  The enum would classify the type of data in the variant, so it acted very class-ish.  Method subvi's would figure out which type of data it was from the enum and execute the approriate method.  But of course memory was duplicated everywhere.  LVOOP is practically a drop-in replacement for me in some pretty big applications that I'm hoping won't use so much memory.  But there are so few dots I'm not even sure I trust it!  I'll take this to another thread.

[Ben]

I'll watch for the other thread.

Make sure you include "LVOOP" in the subject line and hopefully Aristos Queue or Tomi will reply.

But from what I understand of the new implementation of LVOOP, it is capable of doing a lot of work "in-place".

Ben

[P. Jack]

I will, thanks.

[Jarrod_S.]

Just jumping in at the end of this thread, so sorry if this is repeat.

Note that classes show up as Scalars in the Dots dialog, not clusters. This was not what I expected when I first used the tool, because I associated them with clusters naturally. But classes are scalars of their new datatype.

Just make sure you have Scalars checked to view class allocations.

[Roy_F]

---

@Travis M. wrote:

In order to be as productive as possible, please post any new issues unrelated to the ones discussed here in new threads, and be sure to link them to the monthly bug threads which can be found in the Breakpoint special interest board. 

---

For those not familiar with the monthly bug threads, here is a link to the "Monthly Bugs, April 2007" thread:

http://forums.ni.com/ni/board/message?board.id=BreakPoint&message.id=3656

The first entry of each month has a link to the previous month's thread (April's first entry points to March) and the last entry links to the next months thread (April's last entry points to May). It also has the "rules", which really just say "don't discuss the bugs in the monthly bug threads, just point to them. That makes the bug thread itself a digest of sorts, which makes traversing it very easy.

The monthly bug threads were created by users for users. The threads are effective and useful, so please take advantage of them.

Enjoy,
Roy

[Roy_F]

---

@billings11 wrote:

I also think that even though you are fixing the specific problem of Resample Waveform (single shot).vi, you should also do some sort of corrective action internally to make sure this type of thing doesn't happen again. 

---

We have numerous processes in place which are intended to avoid the problems you mention. These processes work as intended the vast majority of the time. They did not work in this instance.

We train developers that it is really bad to break existing code. A change which causes a VI to be broken is bad. A change which causes a VI to function improperly, but still run, is worse. We teach this to developers. We have things in place to ensure this is considered during specification and design. We have procedures in place to ensure this is considered when reviewing code prior to submission. The Resample change, changing the default for Open Interval, may or may not have been the right thing to do (changes like that are, in general, debatable), but when done, it should have had "mutation code" written for the change (not debatable). The mutation code should have implemented the logic "If the Open Interval terminal is not wired, drop and wire a True constant to the terminal". For more complex changes, where we can't maintain backward compatibility via dropping constants and/or nodes and wiring, we sometimes create a "Compatibility VI", which is usually just the old VI with a glyph to indicate which version it is from and that it is not the "current" form of that node.

In this particular case, mutation of the node was considered (that's good) and mutation code was written (that's good). The developer who made this specific change is a seasoned G developer. He is one of our most experienced and perhaps one of our best at properly handling mutation. He simply missed the default change for Open Interval when writing the mutation code (he was focused on the data type mutations). The really really strange thing that is haunting him as we speak is how he came to document this in the Upgrade Notes. Did he discover his mistake just prior to release, when it was too late to make code changes? He does not recall. And, once it was put in the Upgrade Notes, how did it make it past the technical reviewers of that document? Pilot Error (with multiple pilots) is all that I can conclude from this.

We will emphasize the importance of maintaining backward compatibility at a meeting with all LabVIEW developers on Tuesday. We will reiterate for developers and reviewers that breaking backward compatibility is significantly important and painful to our users. This discussion will be somewhat akin to attending a defensive driving class. You can be an experienced driver, a good driver, but there is value in attending a defensive driving class every so often to "raise awareness".

I realize this does not alleviate the pain you have experienced, but I hope it does reassure you that we take these issues very seriously and we do have processes in place to avoid these problems.

Sincerely,

Roy Faltesek
Senior Group Manager
LabVIEW R&D

[billings11]

Roy,

Thank you for the thorough response.  I understand that mistakes can happen, and I've found small bugs from time to time over the years.  Its just that this time when I went from 7.1 to 8.2 so many bugs and problems hit me at the same time that almost none of my code was executable and I spent about a month just troubleshooting figuring out workarounds.  I would submit that its not entirely the G developer's fault, but also the process itself.  When problems slip through the cracks it also means that cracks exist in your process.  It can't hurt to take a close look at them.

With respect to the installer bugs (not the network deployment issue but the problems with 7.1 runtime overwriting 7.1.1, 8.2.1 over 8.2, etc):  An installation bug can be just as painful as broken labview code for people that have to handle installs on a lot of computers.  The 7.1 installer over 7.1.1 means we have to keep track of what labview version each of my installs was created in and what programs can be installed before or after each other.  It gets very complicated and it puts huge pressure on me to convert every application I've ever written up to 8.2 so we can do away with the 7.1 installers entirely.  So even though it seems sort of minor, it really isn't.

But thank you very much for the correspondence.  I have never been able to get this kind of communication with anyone at NI other than in these message boards.  I am happy to know that these issues are being taken seriously.

I look forward to resolving the remaining issues.

[Travis_M.]

Hello Billings11 et. al. and happy Friday!

I have a question about your software installation issues.  You mentioned in an earlier post that you were getting resource file conflicts with 7.1.x, and had some concerns about the difficulty of standardizing on a 7.1.x platform.  Was the information in the earlier KB (http://digital.ni.com/public.nsf/allkb/680E61A4D02158A186256F7A0073C228?OpenDocument) helpful?  Does it resemble your problem?  I see that the KB has a really low rating, and I am going to try to add some detail to it next week, but basically the problem was with the way that the 7.1.0 application builder creates an installer for your application.  If you are building an application in 7.1.0 and you choose to build and installer, then include the runtime engine in that installer, LabVIEW automatically includes components to install the runtime engine on whichever computers you distribute your application to.  The problem (and it is a bug that is fixed in 8.x) is that the 7.1.0 runtime engine installer that is built with application builder will break the runtime engine of LabVIEW 7.1.1 on any machine by replacing the resource file with an older version leading to this error.  The fix is to repair the runtime engine, but the whole problem can be avoided if you build your applications in 7.1.1 or avoid installing software built in 7.1.0 (if you have 7.1.1 installed already).  I realize that the second option isn’t always an option since people can send you software that you don’t have version control over.  Is switching your development machine over to 7.1.1 an option?  

The fix for the problem if you ever encounter it is to repair your 7.1.1 runtime engine (there are a couple of other hints in the KB).  We fixed this problem in 8.x by changing the version of the runtime engine that ships with app builder created installers to correctly install.

Anyway, if this is the problem you are encountering please let me know if you have any questions.  The other installer issue about maintaining versioning and using administrative tools on Win Server will be addressed next week.

Thanks for everyone’s continued interest and feedback.  Have a great weekend-