Jim Kring

Version Update: Version 1.0.5 - Sunday, March 12, 2006 at 21:14:08 (UTC) [FIX] Ignores any VI in memory with a Path property value of Not a Path, such as Express VI instances (facade VIs). [NEW] Records the file path of any VI, CTL, etc. that causes an error. Thank you to PJM_labview for making these modifications.

Yes, you could say that NI's Trim Whitespace VI represents the most sincere form of flattery However, my statement about NI copying LAVA (or OpenG for that matter) is not to poke fun at NI. If NI is smart, they should copy (or support) things that work. No sense re-inventing the wheel. However, I wish sometimes that NI would give more support to community efforts outside of ni.com, but that is their prerogative. I should state that NI has been very supportive of local user group meetings in the San Francisco Bay Area for many many years and that is one of the reasons that the LabVIEW community is so strong in this region.

I agree, it is not a good idea to edit the XML. I believe that these files are signed (similar to a checksum), so that LabVIEW knows whether they have edited outside of LabVIEW. If the signature is not valid, then LabVIEW will probably refuse to load the file. However, I have not tested this theory yet.

Version Update: Version 1.0.4 - Saturday, March 11, 2006 at 00:19:19 (UTC) [NEW] Additionally, mass compiles *.vit (VI Template), *.ctt (Control Template), and *.flx (FlexMotion VIs) files.

Thanks for answering my follow-up question(s). > The built-in mass compile doesn't keep track of what it has previously saved or what it has previously loaded as top-level. I'm not sure where you're going with this, do you have a follow-up question regarding this? My point about keeping track of work already done, is that there are several ways in which the built-in mass compiler can be improved, dramatically. I'm not trying to get into a pissing contest with anyone over which mass compiler is best -- I just want to work towards a mass compiling solution that is fully optomized and doesn't have any succeptibility to VI cross-linkeages. Currently the built-in mass compiler needs to be refactored and optomized -- maybe re-written in G. It sound like you have an interest in this too, so maybe you could champion that cause, from within NI. > Yes, the fact that the sum of time spent compiling & saving a VI is more than that of just loading it once its already been saved in the current version is a general statement, but one that is true for just about any VI. I suppose there may be cases in which this is not true. When the mass compiler is redundantly reloading large hierarchy into memory several times it wastes a huge amount of time, unnecessarily. I'm not arguing over whether compiling and saving takes more time than loading into memory, just communicating a major source of performance problems so that it can be noted and possibly improved. Cheers, -Jim

Ben: You probably already know this, but it is worth highlighting: The LAVA Bug Lists are searchable, and you can scope your search to specific forums and subforums. Just use the forum Search page.

I have been doing that -- putting links to the LAVA bug postings in the NI forums bug list. In fact, I also point the NI support engineers to my LAVA bug postings when I use NI's email support system.

Jeff, > The built-in mass compile does load VIs on a VI-by-VI basis. Each time a VI is loaded, all of its subVIs are brought into memory as a result. For all VIs we just loaded, we see if they have a docmod (typically as a result of a recompile after version bump) and if so, we save them. We then close them all. Wash rinse and repeat on the next VI, etc. Does the built-in mass compiler keep track of which VIs it has already saved (not just those that it has loaded, as top-level)? > The longest parts of this process are the compile and save, which do not happen for VIs that have already been saved. That is a very broad statement. It's probably true for vi.lib VIs that have shallow hierarchies, but probably less so for ./resource and ./project VI hierarchies. -Jim PS - Talk is cheap, show us the code.

LAVA already has a bug list. Look at the LabVIEW 8.0 Buglist forum -- my bug postings have a topic description that gives the status (e.g. "Status: Fixed in 8.0.1") that is easily seen from the main topics listing. If you are a Premium LAVA Member, you can edit your postings. This allows you to edit the posting content (and description) to reflect bug status and CAR information, when it becomes available. Michael Aivaliotis (or benevolent LAVA Champion) has gone through a lot of effort to set up some great tools for us and he is very responsive to requests for features and improvements. Basically, in my opinion, it is a lot easier to get things done here at LAVA than on the NI forums. And, the signal to noise is a lot better too. Personally, my interest is in getting things done that are important to me, not necessarily in helping NI provide better support for its customers. I find that the LAVA forums are a better environment, to that end, and that is where I would rather focus my time and energy. Bottom line, the NI forums bug list is a great idea, but I would rather spend my time championing the LAVA bugs forums (or other tracking tools). And, in the end, this might actually motivate NI more to implement better tools for thier customers. If we do it at LAVA, NI will be forced to copy us (and probably do it better than us). But, if we do it on the NI forums, then I feel that NI will be happy to let us do thier job for them. :2cents:

The built-in mass compiler is probably reading the binary to see if it is a known LabVIEW file type. Since the .svn files are VIs, the mass compiler is loading them.

Jeff: Thanks for info. Regarding this tool's limitations: Caching: The caching that I do is a sort of smart caching -- it assumes that it is safe to load all VIs that are located in the same folder, into memory at the same time. While this is not fool-proof (as there are some clever fools out there), it is a very safe assumption, IMO. Obviously, you can't have two files of the same name in the same folder, and while they might link to different files of the same name it is really unlikely and is a result of more serious problems. File types: Yes, this tool only handles VI's and CTL's. What other file types (extensions) do you recommend? I guess we could safely add VIT and CTT. And, maybe we want to to .flx (is that right?) for the FlexMotion mutants

Version Update: Version 1.0.3 - Thursday, March 9, 2006 at 20:56:32 (UTC) [NEW] Continues through any mass compile errors and writes them to file (and opens it) after completion.

Version Update: Version 1.0.2 - Thursday, March 9, 2006 at 17:14:08 (UTC) [NEW] Performance improvements of up to 50%, due to optimizations of code.

Version Update: Version 1.0.1 - Thursday, March 9, 2006 at 06:36:34 (UTC) [FIX] Open VI Reference was not being called with option 0x01 to record modifications. This was causing the modifications bitset of all VIs to be 0 and the mass compile was not saving any VIs. You MUST rerun the Mass Compile utility if you were using version 1.0

FYI - I have just posted a faster mass compile tool for LabVIEW 8.0.1 installation.

FYI - I have just posted a faster mass compile tool for LabVIEW 8.0.1 installation.

I have just posted a faster mass compile tool for LabVIEW 8.0.1 installation. Now, get back to work

Take the day off and go have some fun. :thumbup:

This mass compile issue makes me think of another issue that has been on my mind for a long time. The built-in Mass Compile is a real pig. I believe that it loads each VI into memory, saves it, and unloads it -- one at a time. I can think of serveral ways to optomize this process. For example, after loading a VI into memory, save all of its subVIs, too. Keep track of which VIs that you've already saved, and do not load and save them again. I wonder how much this would speed up the process. For OpenG Commander, we built our own mass compiler that just loads the whole app into memory and saves all VIs in the hierarchy -- this saved loads of time.

You probably noticed, but I have started another poll: Should NI release a full 8.0.1 installer?

In my opinion 8.0.0 is not useable, due to the bugs -- the 8.0.1 patch is absolutely necessary. However, after 1 hour to install LabVIEW 8.0, it is not reasonable to spend 2 to 4 (or more) hours mass compiling. Please cast your vote.

Aitor: I've used this technique on several occasions -- it works very well.

Don't forget about Mac: ftp://ftp.ni.com/support/labview/updates/...0.1_Updater.dmg ftp://ftp.ni.com/support/labview/updates/...adme_8_0_1.html And Linux: ftp://ftp.ni.com/support/labview/updates/...lv801-linux.tar ftp://ftp.ni.com/support/labview/updates/...adme_8_0_1.html

Status Update: Fixed in 8.0.1

Status Update: Fixed in 8.0.1